Universidade Federal do Rio de Janeiro

Escola Politécnica

Departamento de Eletrônica e de Computação

Implementação de um simulador de tráfego urbano simples

para estudo da coordenação semafórica

Autor:

_________________________________________________

Vitor dos Santos Sousa

Orientador:

_________________________________________________

Aloysio de Castro Pinto Pedroza, Dr.

Examinador:

_________________________________________________

Claudio Esperança, Ph. D.

Examinador:

_________________________________________________

Sergio Barbosa Villas-Boas, Ph. D.

DEL

Fevereiro de 2014

ii

UNIVERSIDADE FEDERAL DO RIO DE JANEIRO

Escola Politécnica – Departamento de Eletrônica e de Computação

Centro de Tecnologia, bloco H, sala H-217, Cidade Universitária

Rio de Janeiro – RJ CEP 21949-900

Este exemplar é de propriedade da Universidade Federal do Rio de Janeiro, que

poderá incluí-lo em base de dados, armazenar em computador, microfilmar ou adotar

qualquer forma de arquivamento.

É permitida a menção, reprodução parcial ou integral e a transmissão entre

bibliotecas deste trabalho, sem modificação de seu texto, em qualquer meio que esteja ou

venha a ser fixado, para pesquisa acadêmica, comentários e citações, desde que sem

finalidade comercial e que seja feita a referência bibliográfica completa.

Os conceitos expressos neste trabalho são de responsabilidade do(s) autor(es).

iii

DEDICATÓRIA

Dedico este trabalho ao meu esforço vontade de grandeza e a Deus

iv

AGRADECIMENTO

Primeiramente gostaria de agradecer a Deus , fonte de todas as realizações e feitos,

depois gostaria de agradecer aos meus pais Débora Marques e Lícinio Carvalhais de Souza

pelo apoio absoluto e pelas palavras amigas de motivação nos momentos difíceis. Em

seguida gostaria de agradecer ao professor Claudio Esperança por toda a paciência e

dedicação que teve ao me apresentar os atributos do processing e como explora-lo de uma

forma melhor para o trabalho a que me propus, pelas horas de ajuda e orientação que

obtive dentro do LCG (laboratório de computação gráfica). Também gostaria de agradecer

ao meu orientador Aloysio Castro Pinto Pedroza por ter acreditado nesta proposta de

projeto final e por toda paciência e cuidados dedicados a mim como orientador, por suas

grandes ideias, este trabalho não poderia ser feito com qualidade sem sua ajuda. Gostaria

de agradecer ao professor Humberto Hryniewicz de cálculo diferencial III, aos meus

amigos Felipe de Menezes por ter me relatado o problema do sinal de trânsito do Jóquei

Clube e ter me dado as primeiras motivações para desenvolver um trabalho nesta àrea. Ao

Henrique Duarte por seus sábios conselhos e palavras de consolo, ao Vitor Antunes

Tavares. Ao Luiz Gômes Ribeiro, Andrei Lenine, ao professor e amigo Fernando Baruqui

pela motivação inicial para trabalhar nesse projeto (o mesmo disse-me que achava o

trabalho interessante) e por último ao professor Sergio Barbosa Villas-boas, pelos bons

conselhos dados.

v

RESUMO

Este trabalho tem como objetivo compreender como o correto sincronismo de

sinais de trânsito em uma grande cidade pode produzir um impacto positivo no parâmetro

de Engenharia de Tráfego denominado Fluidez. Além de descrever o funcionamento e

implementação de um simulador simples que testa as vantagens dessa otimização.

Palavras-Chave: Engenharia de Tráfego, Fluidez de Tráfego, Semáforos Adaptativos,

Processing , Java , Engenharia de Software , Grafos , Árvores, Computação Gráfica,

Otimização Semafórica

vi

ABSTRACT

This study aims to understand how the correct timing of traffic signals in a large

city can have a positive impact on Traffic Engineering parameter called Fluidity. In

addition to describing the operation and implementation of a simple simulator, that tests

the benefits of this optimization.

Key-words: Traffic Engineering, traffic flow, traffic lights Adaptive, Processing, Java,

Software Engineering, Graphs, Trees, Computer Graphics, Traffic Lights Optimization.

vii

SIGLAS

UFRJ – Universidade Federal do Rio de Janeiro

LCG – Laboratório de Computação Gráfica

DEL – Departamento de Eletrônica e de Computação

VISSIM – Verkehr in Stadt Simulationsmodell

viii

Sumário

1 Introdução

1.1 - Descrição do Problema . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 - Delimitação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.3 - Justificativa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 - Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.5 - Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.6 - Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Conceitos

2.1 - Simuladores, o que são, por que fazer simulações ? . . 3

2.2 - Simuladores Existentes . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3 - Modelos de Tráfego . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.4 - Proposta de Simulador . . . . . . . . . . . . . . . . . . . . . . . . 9

2.5 - Teorias de Perseguição de Veículos . . . . . . . . . . . . . . . 10

2.6 - Tratamento Matemático . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.7 - Otimização Semafórica . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.8 - Exemplo Prático . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.9 - A Ferramenta Processing . . . . . . . . . . . . . . . . . . . . . . . . 22 22

.

ix

3 Descrição geral do sistema

3.1 - Descrição Geral do Sistema . . . . . . . . . . . . . . . . . . . . . . . 29

3.2 - Implementação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4 Arquitetura do Sistema

4.1 - Descrição Aprofundada de Classes . . . . . . . . . . . . . . . . . 41

4.2 - Casos de Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.3 - Diagramas de Eventos . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4.4 - Diagramas de Estado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

5 Conclusões

5.1 – Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

x

Lista de Figuras

2.1 – Lista dos métodos de coordenação semafórica

2.2 – Diagrama ilustrativo da maximização da banda verde

2.3 – Tempos de sinal calculados de forma intuitiva

2.4 – Tempos de sinais calculados de forma projetada

2.6 – Vasos remodelados por computador e impressos por impressora 3D

2.7 – Mapa do tráfego de informação da empresa de telecomunicações alemã

2.8 – Projeto de Mark McKeague (sinfonias urbanas)

3.1 – Diagramação geral para o sistema

3.2 – Arquivo de Entrada do programa com a descrição das pistas

3.3 – Arquivo com a descrição das rotas usado para inserção do número de

veículos requisitantes de cada uma delas

3.4 – Interface principal do programa

3.5 – Uma seção hipotética de uma cidade, que se deseja simular

3.6 – Uma seção hipotética de uma cidade que poderia travar o algoritmo de

geração de rotas

3.7 – Descrição de algumas rotas geradas pelo algoritmo de geração de rotas

xi

Lista de Tabelas

2.5 – Tabela com os Resultados da Simulação

1

Capítulo 1

Introdução

1.1 – Tema

O movimento das pessoas e mercadorias é o reflexo das diferentes atividades

existentes numa sociedade, sendo um fator determinante para a qualidade de vida das

pessoas. O ramo da engenharia que se ocupa do movimento eficiente e seguro de pessoas

e bens na rede viária é a engenharia de tráfego que deste modo tem como objeto o estudo

da mobilidade (facilidade de deslocamento) e como objetivo a otimização do sistema

viário, garantindo o acesso das pessoas e bens aos locais. Sistemas de simulação de

tráfego urbano têm sido adotados crescentemente para o suporte a grandes obras de

infraestrutura, análise do impacto real de operações e decisões de tráfego sobre a logística

de transportes das cidades e no planejamento de transportes há mais de 40 anos. Além de

tudo isto as simulações cumprem um importante papel nas disciplinas de planejamento

de transportes e engenharia de tráfego ministradas nas universidades aqui e mundo afora.

1.2 – Delimitação

O simulador que será descrito ao longo deste trabalho apresenta uma série de

limitações, pois se trata de um simulador simples que foi escrito “do zero”. Vamos

enumerar algumas coisas que ele não faz: Não simula comportamentos de pedestres, nem

de ciclistas, nem de veículos de transporte público, nem dá aos veículos integrantes da

simulação a chance de possuir um comportamento randômico, pois os veículos agem de

forma bastante regular nunca possuindo comportamento imprevisto, sempre seguindo

uma regra para uma determinada situação. Além disso o modelo adotado para simular o

comportamento de seguir um veículo a frente é extremamente simples, também é valido

citar que não existem ultrapassagens e nem mudanças de faixa, o problema é tratado como

um número finito de rotas.

2

1.3 – Justificativa

A justificativa para o trabalho poderia ser encarada como a experiência pessoal

do autor do trabalho, suas observações sobre mobilidade urbana na sua cidade e

convivência com gravíssimos problemas de mobilidade urbana. A cidade do autor do

trabalho não possui sinais de trânsito adaptativos (embora possua uma infinidade de

mecanismos eletrônicos para aplicação de multas nas vias de trânsito). Qualquer pessoa

que precise se deslocar constantemente dentro da cidade repara que o mal sincronismo

dos sinais prejudica em muito o trânsito em inúmeros locais. O autor do trabalho

pesquisou como poderia ser construído um mecanismo para detecção do tamanho de uma

fila diante de um sinal e constatou que tal mecanismo não apresentaria grande ônus, teria

uma fração do valor de instalação de um poste de iluminação pública, então se perguntou

constantemente por que motivo nada era feito a respeito. Com o objetivo de obter uma

certeza maior sobre as vantagens de se construir tais mecanismos ele resolveu trabalhar e

medir, ter mais certeza ainda das vantagens.

1.4 – Objetivos

Obter uma ideia de quanto se pode ganhar em fluidez de tráfego ao se otimizar

sinais de trânsito. Entender como funciona um simulador de tráfego urbano simples

contínuo e programar um simulador simples.

1.5 – Metodologia

O assunto é abordado de forma fictícia, porém com alguma verossimilhança. A

pesquisa foi feita com suporte do portal da CAPES e seus artigos, com ajuda de

professores do departamento de transportes, com estudo da bibliografia de engenharia de

tráfego mais usada nas universidades mundo afora, com a ajuda de professores do

departamento de eletrônica e computação (DEL) nos assuntos referentes à engenharia de

software, com o auxílio de professores que trabalham com computação gráfica (atuantes

3

no LCG). O trabalho será documentado neste trabalho utilizando-se notação UML para

descrever as características do sistema como software.

1.6 – Descrição

No capítulo 2 será apresentado ao leitor algumas noções de simulações de tráfego

urbano, descrevendo de forma objetiva e abrangente os diversos sistemas de simulação

existentes para dar uma visão ao leitor sobre as diversas técnicas empregadas para

simulação de trafego.

O capítulo 2 trata de um tópico extremamente importante para o sucesso de

qualquer simulador de tráfego urbano como ferramenta de auxilio nas decisões de

engenharia de transportes e em engenharia de tráfego que são as teorias de perseguição

de veículo (Car Following Theories) que possuem como objetivo maior a correta

modelagem do comportamento presente em todo condutor quando está perseguindo um

outro veículo em uma dada faixa de rolamento de uma via.

O capitulo 2 trata também do estudo da coordenação semafórica de forma a dar a

base para o entendimento de como se pode programar corretamente os tempos dos sinais

de forma a permitir que no mapa passe o maior número possível de bolinhas. Todo o

embasamento teórico usado para otimizar este fluxo será dado em um tópico deste

capítulo, e em um outro tópico do capítulo será relatada uma experiência realizada com

este simulador desenvolvido para comprovar a eficiência do método de otimização

semafórica utilizado, que neste caso será o de maximização da banda verde.

No capítulo 2 existe um tópico especial dedicado somente ao agradecimento do

grupo que desenvolveu o Processing , o objetivo deste tópico é disseminar o trabalho

destes dedicados programadores que construíram está ótima ferramenta de computação

gráfica , mostrar ao leitor como o projeto foi desenvolvido e executado , o Processing é

um framework de computação gráfica com uma história bem peculiar e interessante.

Desta forma este citado tópico tem como objetivo ser um capitulo informativo e de

reconhecimento à equipe que criou e tem ajudado a desenvolver o Processing durante

todos esses anos e falar de algumas funções que foram usadas durante o trabalho.

4

O capitulo 3 é o capítulo que descreve a implementação do sistema desenvolvido,

como ele funciona, de que forma e para que cada um dos módulos funcionais foi

implementado.

O capitulo 4 é o capitulo mais importante deste trabalho, pois ele aborda, explica

e exemplifica todo o funcionamento do programa de uma forma clara e concisa de forma

que uma pessoa que eventualmente estiver interessada em continuar desenvolvendo este

simulador poderá, por intermédio da leitura deste capitulo, encontrar uma base sólida para

firmar seu trabalho. Desta forma o capitulo tem como objetivo fornecer uma visão geral

do trabalho desenvolvido de uma forma precisa, isenta de ambiguidades, para que um

programador não encontre dificuldades se possuir motivação para desenvolver mais ainda

o simulador. Além disto este capitulo também possui como objetivo descrever ao leitor

do artigo informações importantes relacionadas ao baixo nível de um simulador de tráfego

urbano, coisas que ele precisa fazer para garantir o comportamento adequado dos

condutores dos veículos diante das situações adversas da via

Capítulo 2

Conceitos

2.1 – Simulações de tráfego, o que são, por que fazer simulações

Trata-se da modelagem matemática dos sistemas de transporte (por exemplo,

auto-estradas, cruzamentos, vias arteriais, rotundas, sistemas de rede do centro, etc)

5

através da aplicação de sistemas de software de computador para ajudar engenheiros de

sistemas de transporte a planejar, projetar e operar. Simulações de sistemas de transporte

já são feitas há mais de quarenta anos, se trata de uma importante área da disciplina de

engenharia de tráfego e planejamento de transportes de hoje. Várias agencias de

transportes nacionais e locais fazem simulações para auxiliar na gestão das redes de

transportes existentes no mundo atual.

Simulações de transportes são importantes porque podem estudar modelos muito

complicados para o tratamento analítico e numérico, bem como para serem utilizadas para

estudos experimentais, também podem descrever as relações detalhadas que poderiam ser

perdidas em tratamento analítico e podem produzir demonstrações visuais atraentes de

cenários atuais e futuros.

Para compreender uma simulação de tráfego é importante entender o conceito de

estado do sistema que é um conjunto de variáveis de estado que possuem informação

suficiente para descrever a evolução do sistema ao longo do tempo. O estado do sistema

pode ser discreto ou contínuo. Modelos de simulação de tráfego são classificados de

acordo com o tempo discreto ou contínuo.

2.2 – Simuladores Existentes

Técnicas de simulação de tráfego tem sido aplicadas desde os primeiros dias de

formulação das teorias de tráfego. Existe um grande potencial para aplicações uteis em

análise de problemas complexos em áreas urbanas, ao lado das técnicas analíticas que já

estão sendo usadas. Segue abaixo uma enumeração de alguns sistemas de simulação de

tráfego urbanos comerciais ou de código aberto conhecidos

Smartest

Transyt

SIDRA intersection

Transmodeler

CORSIM

PTV - VISSIM

6

2.3 – Modelos de Tráfego

Métodos de simulação de transportes podem envolver uma série de teorias, dentre

elas podemos citar a axiomas e teoremas de probabilidade e de estatística, equações

diferenciais e métodos numéricos. Em cada parágrafo que irá seguir agora será descrito

por alto do que se trata cada um dos métodos empregados e também sem muitos detalhes

como funciona cada um desses métodos. Porém antes de avançarmos é útil citar que existe

uma classificação geral para os modelos de tráfego, podendo tais modelos serem discretos

ou contínuos, microscópicos, mesoscópicos ou macroscópicos. Modelos microscópicos

procuram descrever o sistema como o resultado da soma de um enorme número de

agentes, enquanto modelos macroscópicos descrevem o comportamento geral do sistema

como a soma de ações idênticas das partes microscópicas que estão condicionadas à

variáveis macroscópicas, um exemplo perfeito deste tipo de sistema é o fluxo de um gás

por uma tubulação, possuindo suas partículas maior velocidade onde existe uma menor

área. Modelos mesoscópicos procuram obter “o melhor dos dois mundos”.

Método de Monte Carlo

O método de monte-carlo, quando empregado nas simulações, constrói os

resultados e conclusões com uma abordagem probabilística, assume que um determinado

evento possui uma determinada probabilidade de acontecer e caso ele aconteça aplica as

regras cabíveis para a ocorrência daquele evento aleatório. Pode-se fornecer como

exemplo a seguinte situação em um cruzamento simples: Define-se um cruzamento

simples com 3 ruas convergindo para um único ponto e uma única rua saindo deste ponto.

Afirma-se que inicialmente não existem veículos presentes no mapa que representa os

três cruzamentos. Afirma-se também que as três ruas possuem probabilidades P1, P2 e

P3 de possuírem um veículo solicitando a passagem por aquela rua (indo em direção ao

ponto de convergência, a cada intervalo de tempo T). Define-se também um conjunto de

7

regras afirmando que se caso existam n veículos naquela rua então durante o tempo em

que um sinal está verde, ou mesmo que um sinal não exista, durante um intervalo de

tempo T, existe a certeza de que vão passar m carros durante aquele intervalo de tempo

para aquela quantidade de carros na via e para aquela via. Como o número de veículos

presente na via, pelas suposições feitas, é constante dentro deste intervalo T, pois

necessita-se de um intervalo de T segundos para que exista a probabilidade de entrar um

novo carro na via, então pode-se estimar para este perfil de demanda de veículos naquele

cruzamento informações relevantes sobre o tráfego naquele trecho da via. Variantes desta

abordagem poderiam ser feitas supondo-se que o número de veículos que possuem

condições de atravessar a via no intervalo de tempo T para uma dada quantidade n de

veículos naquela via seja na verdade uma variável aleatória de comportamento gaussiano

com uma média e variância dada. A abordagem de Monte Carlo se vale então basicamente

de um “approach” estatístico e probabilístico.

Método do Autômato Celular

Este método é um dos mais famosos e consagrados métodos para realização de

simulações de tráfego urbano, idealizado por John V. Neumann e Stanislaw Ulam, que

desenvolveram as primeiras noções do que seriam os autômatos celulares. Os autômatos

celulares são estruturas simples com muitas unidades semelhantes chamadas células e

regras de atualização dos estados das células. Os AC são modelos matemáticos

dinâmicos, onde as dimensões de tempo e espaço são discretas e as atualizações dos

estados das células se dão através de interações entre regras locais e relações de

vizinhança entre as células (Leonardo D. Tavares apud Wolfram). A estrutura que

descreve um AC é a seguinte:

Um vetor de tamanho n que representa as células V = {a1, a2, a3, a4, .... ,na}

Um vetor com o conjunto de k estados possíveis para cada célula “a” de índice i

do vetor V: E = {s1,s2,s3,s4, .... , sk}

Um conjunto R = {R1,R2,R3, .... , Rm} de regras locais

8

Sabe-se que tais estados devem ser atualizados com base nos estados das células,

segundo as regras locais para cada célula. A forma como tais estados são atualizados pode

ser de duas maneiras: A forma síncrona, onde todas as células do mapa são atualizadas

de uma só vez e a assíncrona onde uma célula é atualizada de cada vez e uma após a outra.

Ainda podem ser classificados como homogêneos ou heterogêneos, sendo homogêneos

os ACs onde as regras locais para uma dada célula não dependem da localização espacial

daquela célula, já no caso heterogêneo as regras locais disponíveis para uma dada célula

dependem da localização espacial daquela célula, ou seja, variam de um ponto pra outro.

Além disso, é importante citar que o conjunto de regras locais para uma dada célula, no

caso heterogêneo, também pode apresentar variação ao longo do tempo e não somente ao

longo do espaço (Leonardo D. Tavares). Pode-se ainda classificar um AC na categoria de

determinístico ou probabilístico. ACs determinísticos são aqueles onde as células do

mapa possuem somente regras locais determinísticas, e ACs probabilísticos, ou não

determinísticos, são aqueles onde se pode encontrar pelo menos uma célula no mapa com

pelo menos uma regra local não determinística. Regras locais determinísticas são aquelas

que possuem sempre a mesma saída pra uma dada entrada (para um dado estímulo).

Regras locais não determinísticas, ou probabilísticas, são aquelas que podem fornecer

diferentes saídas para uma mesma entrada. Como exemplo de um AC podemos citar o

autômato celular elementar (ACE) que é síncrono, unidimensional (o mapa possui

somente uma dimensão), homogêneo e determinístico. Para dar um exemplo de ACE

pensemos num AC onde os únicos estados possíveis para as células que estão dispostas

em uma dimensão são 0 e 1. Suponhamos também que os dados que alimentam as regras

locais disponíveis para cada célula são os estados encontrados nas células da direita e da

esquerda e da célula central, caso a célula analisada não seja uma célula de alguma

extremidade e somente seu estado no instante “t” e o da célula a esquerda, caso ela esteja

na extremidade direita e analogamente para o caso da extremidade esquerda. O conjunto

de regras locais que irá determinar o comportamento das células deste AC pode ser

deterministicamente descrito pelos valores de entrada da linha superior da tabela abaixo

e os valores de saída correspondentes na linha inferior da mesma tabela, podendo estar

α(i) sempre em 0 ou 1.

Ai-(t)Ai(t)Ai+(t) 000 001 010 011 100 101 110 111

9

Ai(t+1) α1 α2 α3 α4 α5 α6 α7 α8

Modelos Contínuos no Espaço X Tempo

Os métodos microscópicos contínuos no espaço e no tempo são modelos que

procuram descrever a realidade exatamente como ela é na forma de representar os

fenômenos e interações entre os elementos de tráfego, possuem suporte ou apoio de um

ramo da teoria de controle chamado teoria de perseguição de veículos (car following

theory) para ajudar a descrever o complexo comportamento que os agentes de um sistema

de tráfego urbano, rodoviário , tomam( as não regulares atitudes que estes agentes tomam

) quando se encontram diante de diversos outros agentes. Tais modelos de tráfego, ao

descrever para cada instante de tempo (considerado agora pra todos os propósitos práticos

como infinitesimal) a forma como um veículo reage a outro acaba se valendo de teorias

mais verossímeis para o comportamento dos agentes de trânsito rodoviários. Tal

abordagem para o problema da simulação de tráfego usa frequentemente equações

diferenciais para modelar os problemas, pois agora os fenômenos são descritos (para

todos os propósitos práticos) de forma analógica, porém tais modelos possuem a

desvantagem de serem computacionalmente mais custosos.

2.4 – Proposta de Simulador

O simulador de tráfego desenvolvido neste trabalho apresentada uma série de

restrições, pois diferentemente dos simuladores comerciais (VISSIM por exemplo) foi

construído por uma pessoa que não detinha profundamente o conhecimento necessário

para a implementação de um, pois ao construir um sistema e colocá-lo em código o

importante, no caso de um simulador de tráfego, é equacionar e documentar todas as

funcionalidades do sistema. Existe o jargão “dirigir é uma atividade complexa”, o que se

quer é que existe um enorme número de possibilidades e estados de tráfego possíveis, daí

as dificuldades de implementação. Então, antes que se discuta a descrição geral do

10

problema pensemos no valor do trabalho desenvolvido para alguém que não possuía

noções muito fortes de programação de computadores, desenvolvimento de sistemas e

nem pode ser classificado como um “programador talentoso”. O trabalho testou os limites

do autor no sentido de que tudo o que foi feito foi obra de pura criatividade e pesquisa. A

criatividade que emergiu desta atividade foi uma criatividade descobridora de soluções já

existentes certas vezes e em outras vezes ela foi suprimida pela pesquisa intensa e busca

às soluções existentes mas em seguida surgia novamente como um fator suplementar para

a criação de algo novo ou pouco explorado no conjunto de soluções passíveis de serem

construídas com a ferramenta de computação gráfica processing. É sem dúvidas digno de

atenção o ato de compartilhar os enormes problemas que o autor do trabalho enfrentou ao

ter que depurar o código diante de todo comportamento distinto que aparecia resultante

da entrada aleatória dos agentes no mapa, pois sabe-se que os padrões e caminhos

distintos para a simulação são inúmeros. Então o trabalho central e certamente uma das

coisas que mais aconteceram durante o desenvolvimento deste trabalho foi o ataque aos

diversos problemas que existiam no comportamento de alguma entidade na simulação

(bolinhas ou veículos) para diferentes valores de entrada no programa. Sempre que se

acreditava que a simulação estava correndo bem alguma coisa totalmente esdruxula

acontecia, que jogava a “crença” de que se havia construído um algoritmo que simulasse

a atividade de dirigir, mesmo que basicamente, abaixo. A verdade é que toda a

programação foi realizada por tentativa e erro, e uma solução foi encontrada, em cima de

muitas hipóteses simplificadoras, porém ainda sim uma solução que possui condições de

simular minimamente, por exemplo, o comportamento dos condutores de veículos diante

de cruzamentos, que são os pontos da via onde existe o maior risco de acidentes e onde

as interações entre os motoristas são maiores.

2.5 – Teorias de Perseguição de Veículos

Teorias de perseguição de veículo descrevem basicamente todo o comportamento

psicológico existente quando um motorista se encontra atrás de outro indo na mesma

direção e sentido do seu líder e sem realizar ultrapassagem. Tais teorias possuem forte

embasamento psicológico e fisiológico, além de possuírem, obviamente, forte tratamento

matemático.

11

Esta teoria, como já dito, é essencial para os modelos de tráfego microscópicos,

e, geralmente, costumam tratar o motorista e o veículo como uma coisa só. Como a teoria

de perseguição de veículo utilizada neste simulador foi extremamente simplória, será

comentado pouco a respeito deste ramo da teoria de tráfego.

Existe uma infinidade de modelos para a descrição do comportamento de veículos

seguidores de veículos em uma pista de rolamento, o que será feito aqui será discutir

somente aqueles modelos mais famosos. O que se tem percebido é que, desde 1950, com

as mais diversas abordagens ao problema, inúmeras teorias de perseguição de veículos

foram criadas, mas a teoria perfeita ainda não foi encontrada, pois um determinado

modelo apresenta vantagens e desvantagens, isso explica a intensa pesquisa ainda na área.

Então é razoável de se imaginar que uma teoria perfeita ainda não foi encontrada ou talvez

não exista (Johan Janson Olstam e Andreas Tapani). Abaixo enumeramos alguns dos

modelos mais famosos na teoria de perseguição de veículos:

Modelo de Pipe

Modelo de Forbes

Modelo de Gipps

Familia de Modelos GHR

Modelo General Motors

2.6 – Tratamento Matemático

O modelo de Pipe é o mais simples dentro os modelos existentes para descrever o

comportamento dos condutores quando estão seguindo outros condutores. É empregado

na descrição do estado estacionário de um fluxo de veículos nos softwares de simulação

comerciais CORSIM e VISSIM, o modelo assume que a velocidade dos veículos é

insensível à sua densidade linear, o que somente é verdade se a via possuir altíssimo nível

de perfeição geométrica (estiver em ótimo estado) e a velocidade de cada veículo for

12

definida por uma restrição regulamentadora, ao invés de tal restrição ser o próprio estado

tráfego (Hesham Hakha e Brent Crowther). O que este modelo afirma é que “uma boa

regra para seguir um veículo é aumentar o espaço de seguimento em um comprimento

de veículo para cada 5 milhas/h de velocidade adicionais.” Este modelo pertence à classe

de modelos denominada modelos de distância de segurança e evitamento de colisão.

Abaixo está exibido um código fonte que implementa o controle tal qual ele deve ser feito

com o modelo de pipe, em seguida uma enumeração do significado de cada variável no

código.

FOR i = 1:I

s(j,i) = x(j-1,i-1) - x(j-1,i);

s_min(j,i) = l(i) * (v(j-1,i)/(0.447 * 10) + 1);

IF s(j,i) < s_min(j,i)

v(j,i) = MAX([0, v(j-1,i) - dB_i]);

ELSE

v(j,i) = MIN([v_i, v(j-1,i) + dA_i]);

END

x(j,i) = x(j-1,i) + v(j,i) * dt;

END

j -> índice temporal

i -> índice de veiculo

s -> distância

l(i) -> comprimento do veículo com índice i

x(j,i) -> posição do veículo i no instante de tempo de simulação j

s_min(j,i) -> distância mínima que o veículo de índice i deveria

possuir no instante

v_i -> velocidade que o veículo deseja ter no instante atual de iteração

13

dA_i -> fragmento da aceleração máxima do veículo usada naquela

iteração ( uma constante real )

dB_i -> fragmento da desaceleração máxima do veículo usada naquela

iteração ( uma constante real )

O modelo de forbes é quase idêntico ao de pipe, sua única diferença consiste em

que o modelo de forbes utiliza o headway temporal com o valor do tempo de reação do

motorista como o medidor da proximidade de segurança que um veículo tem que ter em

relação ao outro veículo que está na frente.

O modelo de Gipps foi publicado em 1981 e se trata de um modelo que se

enquadra nas teorias de segmento de veículo baseadas na distância de segurança. O

modelo de Gipps assume que a velocidade num momento τ segundos (tempo de reação)

após um determinado instante deve ser a menor dentre duas velocidades possíveis. Uma

destas velocidades é estimada com base na condição limite de segurança que se tem para

um veículo perseguindo o outro em condições de tráfego muito intenso. A outra equação

é para condições de fluxo livre. Em poucas palavras:

Equação que descreve o comportamento do veículo no fluxo livre

Equação que descreve o comportamento do veículo no fluxo intenso

Significado de cada um dos parâmetros

𝑎𝑛 -> Aceleração do veículo perseguidor

τ -> Atraso de percepção

Sn-1 -> Comprimento do veículo líder

14

X(n-1) -> Posição do veículo líder

X(n) -> Posição do veículo perseguidor

B(n) -> Freada mais vigorosa que o veículo líder pretende dar

(B(n)<0)

Parâmetro que estipula a distância adicional entre os carros quando estão

parados além da distância de um comprimento do carro da frente

Esta segunda equação acima foi encontrada estipulando-se que o “θ” valia τ/2 o

que permitiu que a desigualdade que inicialmente descrevia as condições para o fluxo

intenso de veículos pudesse ser analisada de forma mais simples, graças à eliminação de

um termo não linear da velocidade do carro seguidor, após um período de tempo τ (aquilo

que está multiplicando o “θ” na terceira equação), que existia na desigualdade.

Então, resumindo, o que se faz no modelo de Gipps é escolher a menor dentre as

duas velocidades possíveis no lado esquerdo das desigualdades acima sempre para o carro

seguidor.

A família de modelos de Gazis-Herman-Rothery (GHR) é provavelmente o objeto

de mais intenso estudo dentro de todas as teorias de perseguição de veículo. Esta família

de modelos é geralmente citada como o modelo geral de perseguição de veículo. A

primeira versão foi concebida em 1958 e algumas outras versões melhoradas surgiram.

Estes modelos apresentam-se fundamentalmente diferentes dos anteriores porque eles

15

expressam a reação do veículo seguidor por uma espécie de função de estímulo ao invés

de simplesmente dizer qual é a velocidade que o veículo deve possuir num instante de

tempo posterior. Eles são representados pela família de funções de estímulo mostradas na

figura abaixo.

Alfa, beta e gama na equação acima são constantes, “n-1” representa o carro líder

e “n” representa o carro seguidor , “v” significa velocidade , “x” significa posição e “a”

significa aceleração.

2.7 – Otimização Semafórica

As estratégias de otimização (coordenação) semafóricas são uma das formas mais

eficientes de garantir a fluidez da corrente de tráfego e a manutenção da qualidade

operacional do sistema viário, reduzindo atrasos e paradas em redes compostas por

diversas interseções metaforizadas próximas umas das outras excessivas (Cristiane

Biazzono Dutra apud Wallace e Courage, 1982). No brasil em 1984 o foi feita uma

estimativa pelo DENATRAN que constatou que 50% dos tempos de viagem e 30% do

consumo de combustível são efetivamente gastos em paradas nos cruzamentos

metaforizados e afirma que se algo fosse feito para obter uma correta sincronização dos

sinais seria possível obter uma redução nos atrasos da ordem de 10 a 30% em redes menos

densas e até 50 a 80% em redes mais densas, que são aquelas para as quais os semáforos

se encontram mais próximos uns dos outros. Com o surgimento dos computadores

softwares foram criadas metodologias mais práticas para se testar o efeito da otimização

semafórica e verificar se os muitos algoritmos analíticos que já existiam desde a década

de 20 eram tão bons quanto se pensava. No entanto não se sabe se prefeituras realizam

algum tipo de método para conseguir uma razoável otimização semafórica, a prática faz

pensar que não.

16

Na verdade o que se sabe é que a maioria dos sinais de trânsito utilizados no brasil

são de tempo fixo, ou seja, possuem fases verde e vermelha constantes para cada ciclo.

Embora esta operação seja simples sua performance é geralmente precária principalmente

diante de situações de tráfego intenso

Um dos métodos mais conhecidos para coordenar semáforos é a elaboração

manual de um diagrama espaço-tempo, em que as defasagens são definidas graficamente

através de tentativa e erro, a vantagem deste método é a possibilidade de visualizar

graficamente o esquema de otimização (Cristiane Biazzono Dutra apud Webster e Cobbe,

1966).

Com a disseminação do uso de computadores nas décadas de 1960 e 1970, os

pesquisadores concentraram-se no desenvolvimento de técnicas computacionais de

coordenação semafórica que podem ser divididas em três categorias: maximização da

banda verde, minimização do atraso e paradas e a combinação das vantagens dos dois

métodos anteriores (Cristiane Biazzono Dutra)

O método de maximização da banda verde Este método consiste em defasar os

instantes de abertura de semáforos consecutivos de forma que a maioria dos motoristas

que percorrem a via encontrem sempre os semáforos abertos, criando assim um efeito de

“onda verde”.

A figura 2.1 abaixo cita, cronologicamente, alguns dos métodos já desenvolvidos

para a otimização semafórica desde a década de 20.

17

Figura 2.1 – Métodos de otimização semafórica (Cristiane Biazzono Dutra - 2005)

O método a ser utilizado na presente simulação é o método da maximização da

banda verde, será feita uma comparação entre a fluidez de tráfego que se consegue

aplicando-se valores intuitivos para os tempos dos sinais de trânsito que compõem a

malha rodoviária e o tempo projetado (entenda-se o tempo projetado como aquele em que

se aplicam as regras de otimização semafórica para a malha rodoviária). Ao final das

simulações serão entregues dois números, um deles é o número para a simulação com o

tempo pensado segundo a noção de maximização da banda verde e o número de veículos

requisitantes das ruas e o outro para o caso intuitivo, porém ainda levando em conta a

maximização da banda verde.

Mas o que é especificamente este método da maximização da banda verde? A

maximização da banda verde é um método que procurar medir em quanto tempo existem

carros cruzando a linha do sinal analisado. Se pudéssemos descreve-la segundo gráficos

poderíamos explicar da seguinte maneira. Imagine um via que possua dois sinais de

trânsito em cascata, neste caso a maximização da banda verde é aquela que provoca nos

sinais uma espécie de onda verde, tal técnica faz com que um determinado sinal (assim

18

que abra) dispare um contador para o outro sinal que ao extinguir seu valor (torna-lo zero)

fará com que o outro sinal abra. A ideia pode ser melhor visualizada com o auxílio da

figura 2.2

Figura 2.2 – Maximização da banda verde em dois sinais (Cristiane Biazzono Dutra -

2005)

Nesta figura pode ser observada a estratégia utilizada para a otimização

semafórica de maximização da banda verde. As linhas escuras representam tempos de

vermelho dos sinais, nesta representação os sinais apresentam somente duas fases (verde

e vermelho). O que se espera fazer no método é aumentar ao máximo os espaços Bij e

Bji, de forma a tornar possível o maior transito de veículos possível na direção “y”. Porém

perceba também que existe a restrição do tempo em que cada um desses sinais devem

ficar verdes, a demanda de veículos na rua transversal de baixo é maior do que a demanda

de veículos na rua transversal de cima, o que faz com que o tempo de verde da rua de

cima seja maior do que o tempo de verde da rua de baixo. Daí dentro dessas restrições se

faz a adaptação de onde colocar o tempo de verde do sinal de baixo e onde colocar o

tempo de verde do sinal de cima. Se a configuração exibida acima fosse diferente, o fluxo

de veículos nessa via seria menor. O que será feito no caso deste trabalho é se utilizar de

tais estratégias para definir os instantes onde os sinais devem abrir, mas também será

definido o tempo de verde em função do número de veículos que se espera atravessar

cada um dos semáforos, a inserção dos tempos de verde será manual e será melhor

detalhada no capitulo de conclusão.

19

O algoritmo usado não é precisamente um algoritmo, mas sim uma forma de

proceder aplicando-se as regras introduzidas no tópico anterior. Imagine que o mapa da

figura 3.4 esteja sendo usado para verificar a vantagem de se utilizar noções de engenharia

de trafego. O que será feito (e isto é o que compreende o algoritmo) é analisar quantos

veículos irão passar pelo mapa, ou quantos ficarão em fila, em média, após os ciclos de

sinais, ao longo de todo o tempo de simulação, por uma determinada mão e desta forma

programar o tempo daquele semáforo de forma mais inteligente. O semáforo da rua

apresentará um tempo de verde compatível com sua demanda de veículos e além disso o

início do tempo de verde será disposto em um local que permita a máxima banda verde,

estas duas estratégias combinadas compreendem aquilo que entende-se como o algoritmo

utilizado. Durante a apresentação do exemplo prático será ilustrada com maior

propriedade aquilo que se pretende dizer. Na próxima seção serão comparados os

resultados entre uma simulação baseada numa entrada de senso comum e na solução que

leva em conta o volume esperado de veículos.

2.8 – Exemplo Prático

Na figura 3.4 está ilustrado o mapa das ruas onde será realizada a simulação. Neste

mapa os sinais de trânsito indicam o sentido do fluxo de veículos naquela pista de

rolamento da rua, sendo que cada mão é representada por uma linha simples. No caso

intuitivo se usou a noção de que as três vias de acesso ao próximo sinal possuem a mesma

vazão de veículos em cada rua, o que não é verdade. Para o caso da situação em que se

aplicaram noções de engenharia de tráfego os tempos de sinal verde foram compatíveis

com o número de veículos requisitantes daquelas vias e a forma como foram dispostos

estes tempos de verde refletem a vontade que se tem de aumentar a banda verde, que é a

mesma coisa que aumentar o tempo em que veículos estão cruzando sinais.

Na figura 2.3 estão exibidos os diagramas de tempo para uma programação

semafórica baseada no senso comum de que irão passar o mesmo número de veículos por

cada uma das mãos de entrada de ruas do mapa, quando na verdade o que será simulado

é um número diferente de veículos pelas diversas pistas de rolamento de entrada,

possuindo as três pistas de rolamento de entrada superiores, que convergem para a outra

20

rua intermediaria com sinal, um número de veículos de entrada , cada uma , de 160 e as

duas pistas de rolamento inferiores possuindo um número de veículos de entrada, cada

uma , de 160 e as outras três ruas que se encontram no extremo direito do mapa , cada

uma , 160 veículos de entrada, as pistas de rolamento da rua da extremidade esquerda do

mapa possuem, cada uma, 20 veículos de entrada e as pistas de rolamento das ruas na

parte superior esquerda do mapa possuem, cada uma, 20 veículos de entrada . Como pode

ser analisado, a atribuição de tempos iguais aos 3 semáforos principais é uma estratégia

totalmente insensata, pois embora venha a mesma quantidade de veículos das vias

superior esquerda e extrema esquerda não virá esta mesma quantidade da via

intermediária. Além disso, o instante quando os sinais abrem também é importante para

a maximização da banda verde. Mas para a comparação de casos não será levada em

consideração o fato de um aplicar o conceito de maximização de banda verde e o outro

não, pois em ambas as simulações esta técnica será utilizada. O que será levado em conta

será realmente a demanda de veículos por cada rua quando de uma simulação, na primeira

será imaginado que a rua que possui 3 pistas de entrada possui a necessidade do triplo de

tempo de verde em relação ás outras ruas que entram diretamente no mapa. E num

segundo caso os tempos de verde levarão em conta a real demanda de veículos por aquelas

ruas. Na figura 2.3 é possível ver que a rua intermediária possui o triplo de necessidade

de veículos expressa pelo triplo do tempo de verde desta rua (aqui o tempo de verde é

representado pelos espaços vazios, “gaps”). Na figura 2.4 é representado o tempo de verde

das ruas baseado na real necessidade dessas ruas. A real necessidade é aquela cujo tempo

de verde é baseado na necessidade real de veículos (estatisticamente falando) que

cruzarão aquela rua durante os tempos de simulação. Na tabela 2.5 temos os tempos de

simulação e a quantidade de veículos que atravessou o mapa para o caso intuitivo e

projetado durante cada intervalo de simulação. Lembrando que o caso intuitivo aqui

referido não é o caso da estratégia totalmente insensata (comentada outrora), onde os

tempos de verde das pistas de rolamento da rua intermediária e os tempos de verde das

ruas esquerda e esquerda superior são iguais, neste caso intuitivo citado se assume pelo

menos que a rua intermediária terá o triplo de demanda de veículos das outras duas ruas,

o que já é alguma coisa.

Para o cálculo do ciclo total dos semáforos para o caso projetado deve ser feita a

análise do número de veículos que utilizam cada semáforo, para simplificar a análise, será

feita a suposição de que semáforos de uma mesma rua (cada faixa de rolamento pode

21

possuir um semáforo abrindo no tempo em que se desejar) abrem e fecham ao mesmo

tempo. Se de desejasse escolher um tempo adequado para os semáforos citados, poder-

se-ia começar analisando-se a seguinte enumeração referente ao número de veículos para

cada sinal

Faixas da rua superior de acesso - 160 veículos cada

Faixas da rua inferior de acesso – 160 veículos cada

Faixas da rua extrema direita de acesso – 160 veículos cada

Faixas da rua extrema esquerda do mapa – 20 veículos cada

Faixas da rua superior esquerda do mapa – 20 veículos cada

2.3 – Figura que representa os tempos de sinais calculados de forma intuitiva

22

2.4 – Figura que representa os tempos de sinais projetados

TS NTVAMP NTVAM NMVF

Intuitivo 360 s 254 257 103

Projetado 360 s 315 331 50

Intuitivo 240 s 163 160 98

Projetado 240 s 203 209 65

Intuitivo 480 s 343 355 125

Projetado 480 s 424 448 55

2.5 – Tabela com os resultados da simulação

TS -> Tempo de Simulação

NTVAMP -> Número Total de Veículos que Atravessou o Mapa com Peso

NTVAM -> Número Total de Veículos que Atravessou o Mapa sem Peso

NMVF -> Número Médio de Veículos em Fila

Repare a forte redução no número de veículos em fila

23

Agora será exibida uma outra tabela esclarecedora do ganho obtido ao se

programar corretamente os sinais. Esta outra tabela é uma tabela obtida ao se simular três

vezes os sinais otimizados e três vezes os sinais com configuração intuitiva

NTVAMP NTVAM NMVF

Intuitivo 252 256 109

Projetado 317 329 57

Intuitivo 246 250 110

Projetado 385 318 66

Intuitivo 256 264 109

Projetado 314 328 68

Ganho médio 35% 26,4% 70%

O ganho médio referido foi calculado com base em uma média dos três ganhos

intuitivos e projetados. E daí foi tirada a diferença percentual entre tais médias. Pode-se

visualizar um fortíssimo aumento do número de veículos em fila ao final de cada ciclo

bem como as fortíssimas variações percentuais dos números totais de veículos que

atravessaram o mapa com peso e sem peso

2.9 – A Ferramenta Processing

Processing é uma linguagem de programação, um ambiente de desenvolvimento

e uma comunidade online. Inicialmente desenvolvido para ser um software “livro de

desenho” e posteriormente usado para o ensino das bases da programação de

computadores dentro de um contexto visual, evoluiu para uma ferramenta de

desenvolvimento para profissionais. Hoje em dia existem milhares de estudantes artistas

designers pesquisadores e hobbystas que usam processing para aprendizagem,

24

prototipação e produção. A ferramenta é composta por duas unidades: Core application

program interface (API) e PDE (program development environment). Para ter sucesso a

fundação necessita obter dinheiro para proporcionar (criar) versões futuras do processing.

O time do processing, um pequeno grupo de voluntários, já lançou duzentas versões desde

2001. Lançando a versão 2.0 na primavera de 2013, com quase nenhum dinheiro

arrecadado entre as versões 1.0 e 2.0. O software foi escrito lentamente enquanto os

voluntários gerenciavam suas questões profissionais e pessoais e muitas outras

responsabilidades. A versão 2.0 do processing foi desenvolvida e emergiu de uma forma

insustentável, com um tremendo gasto pessoal para os líderes de desenvolvimento. O

programa interativo de telecomunicações em nova iorque promoveu um workshop de

processing 2.0 no verão de 2011. O instituto armstrong de estudo de mídias interativas

fundou o projeto oxford, que consistiu em uma série de workshops de desenvolvimento

em processinho durante o ano acadêmico de 2008-2009. Esse encontro de quatro dias em

oxford, ohio, possibilitou o lançamento do processing 1.0 em novembro de 2008 e

estimulou desenvolvimentos futuros. Desta forma, o processing possui suas origens como

uma ferramenta para tornar possível a expressão de ideias por intermédio de

implementação de códigos fonte.

Desenvolvedores Líderes:

Bem Fry e Casey Reas iniciaram o processing na primavera de 2001 e

continuaram obsessivamente a trabalhar nele. Até que o projeto cresceu bem além da

capacidade de duas pessoas. Os colaboradores listados abaixo permitiram que o projeto

se tornasse o que ele é hoje.

Desenvolvedores Senior:

Andres Colubri (Boston), Integrador OpenGL / Video

Dan Shiffman (New York), Exemplos / Tutorial

Floarian Jenett (Frankfurt), Net / Modo Javascript

Desenvolvedores:

Elie Zananirie (Montreal), Bibliotecas de Contribuição / Ferramentas

25

Manindra Moharana (Délhi), Modulos Experimentais / Core

David Wicks ( Bloomington ) , Engenheiro de Referência

Scott Murray (São Francisco), Referência

Jon Gacnik (Los Angeles), Web

Parceiros:

Lauren McCarthy (Nova Iorque), Primavera / Verão 2013

Greg Borenstein (Nova Iorque), Primavera / Verão 2013

Comunidade:

Philipe Lhoste ( Sevran ) , Administrador do Fórum

Cedric Kiefer (Berlim), Administrador do Fórum

Filip Visnjic (Londres)

Jer Thorp (Nova Iorque), Lobista

Bibliotecas e Ferramentas:

O núcleo do software é expandido por bibliotecas e ferramentas fornecidas por

pessoas da comunidade. Estas extensões inventivas representam um futuro brilhante para

o projeto. Existe uma lista de bibliotecas e ferramentas de contribuintes postada online.

Esses contribuintes não podem e nem são subestimados. Como exemplo pode-se citar o

belo trabalho que Karsten Schmidt (Londres) realizou transformando o processing com a

biblioteca “toxiclibs” e como Damien Di Fede (Austin) estendeu o projeto para

programação sonora através de sua biblioteca “minim”

Abaixo serão exibidos alguns projetos de programação visual já realizados com o

processing. Em particular, será exibido o projeto que motivou a construção deste (um

projeto envolvendo carros elétricos, o barulho emitido por eles e a possibilidade de se

criar musica a partir disto). Na figura 2.6 estão ilustradas duas esculturas que foram

concebidas com o processing ao se utilizar algoritmos programados pelo autor do projeto

26

e algumas bibliotecas da comunidade processing para modificar a forma de vasos com

formas conhecidas e criar estruturas antes não imaginadas. Todos os dias itens como

brinquedos e garrafas de agua são escaneados usando câmeras digitais e são submetidos

a algoritmos que distorcem, abstraem e os colorem em novas formas primordiais de vaso.

Em muitos destes casos, somente a inspeção cuidadosa revela traços herdados dos seus

predecessores físicos. Estas peças são então imprimidas por uma impressora 3-D, para

ficarem com a aparência da referida figura. O objeto original do vaso da esquerda era um

vaso de rosas e o objeto da direita veio de uma garrafa d’agua.

Figura 2.6 – Vasos remodelados por computador

A figura 2.7 exibe mais um uso do processing, desta vez aplicado para a

visualização de dados de uma grande empresa de telecomunicações alemã ( deutsche

Telekom ). A quantidade e o padrão das trocas internacionais de dados que são

transmitidos pela empresa são capturados e exibidos por um aplicativo gráfico

desenvolvido para plotar gráficos informativos sobre a natureza dos dados transmitidos.

Tal aplicativo gráfico foi desenvolvido sobre o processing.

27

Figura 2.7 – Dados trocados internacionalmente

Na figura 2.8 tem-se a imagem do trabalho desenvolvido no processing por Mark

McKeague denominado sinfonias urbanas. O projeto todo gira em torno da ideia de se

produzir música com os barulhos sintéticos produzidos pelos carros elétricos, que

geralmente imitam o som de motores de combustão interna. O autor do trabalho teve a

ideia de representar cada carro como uma semibreve, e as posições relativas entre os

carros produzem partituras, sendo cada uma das linhas musicais uma faixa (uma pista de

rolamento) de uma determinada rua. As regras de trânsito ainda são todas validas, porém

algumas simplificações foram adotadas pelo autor do trabalho que não programou a lei

física de tais carros entrarem nas curvas com uma velocidade apropriada. O autor de

sinfonias urbanas conseguiu fazer o que o autor deste trabalho não conseguiu, que é

compreender e programar uma lei apropriada para o comportamento de perseguição de

um veículo a outro veículo em uma determinada faixa de rolamento. Abaixo está uma

figura a fim de que o leitor deste trabalho tenha uma noção da analogia feita entre as

partituras musicais e o trânsito de veículos nas cidades.

28

Figura 2.8 – Projeto sinfonia urbanas de Mark McKeague

Segue abaixo uma lista de funções que foram usadas durante o trabalho e que

apresentaram grande importância, são funções importantes para o desenho dos objetos

do mapa (ruas, carros, sinais de trânsito)

Stroke()

Função que define a cor das linhas, usando RGB ou HSB

Fill()

Função que define a cor que preenche formas, usando RGB ou HSB

Pow()

Função usada para obter o valor de uma função exponencial

Random()

Função usada para sortear números aleatórios, um valor inteiro é inserido na

função e ela retorna um valor dentre zero e o valor passado

Println()

Função usada para escrever coisas no console

Millis()

29

Função que retorna o tempo decorrido em mili segundos desde o inicio do

programa

mousepressed()

Função que retorna um valor booleano verdadeiro caso o mouse tenha sido

pressionado

ellipse()

Função que printa uma elipse na tela

arc()

Função que desenha um arco na tela

line()

Função que desenha uma linha na tela

framerate()

Função que define a taxa de atualização das imagens

abs()

Função que retorna o módulo de um número real

background ()

Função que desenha somente o plano de fundo com a cor passada a esta função

em RGB ou HSB

randomSeed()

Função que faz a função random segundo uma semente que é seu parâmetro

Além das funções apresentadas o processing ainda dispõe de interessantes

bibliotecas. Abaixo são citadas algumas

Serial

Enviar dados do processing para hardware externos através da interface USB

Network

Enviar e receber dados pela internet usando o modelo cliente servidor

Minim

Bibliteca de áudio usada adaptada da biblioteca JavaSound para usuários leigos

Physics

Biblioteca para modelagem de sistemas físicos

Gráfica

30

Biblioteca para desenho de gráficos em duas dimensões

OpenCV

Biblioteca que possui funções de visão computacional

Open Kinect

Biblioteca para uso junto do sensor de profundidade Kinect

Rekognition Processing

Outra biblioteca para reconhecimento facial e visão computacional

Capítulo 3

Implementação

3.1 – Descrição Geral Do Sistema

O sistema construído utilizou a linguagem Java e, portanto, a metodologia de

programação denominada programação com orientação a objetos. A programação com

orientação a objetos é extremamente conveniente neste caso, pois o programa tem o

intuito de representar o mundo real. O mundo real é composto por inúmeras entidades, ao

olhar para fora de sua janela você enxerga objetos em todas as direções para onde olha.

No caso do tráfego urbano não é diferente, pois o tráfego (trânsito de veículos, pessoas e

bens) de uma grande cidade está repleto de entidades. Como exemplo de algumas dessas

entidades podemos citar os veículos, pessoas, motocicletas, semáforos, bicicletas, ruas,

avenidas, agentes de trânsito e muitas outras, porém apenas restringimo-nos àquilo que é

importante para uma simulação de tráfego urbano. O foco em orientação a objetos é tão

importante que, inicialmente, o autor do trabalho imaginava como seria possível construir

algo abordando o problema de uma maneira diferente. Desta forma, como o autor sempre

teve interesse em desenvolver um simulador, mesmo que simplório, como experiência de

vida, para o tráfego nas grandes cidades, ele enxergou no paradigma de programação

31

orientada a objetos uma grande oportunidade facilitadora para a construção do sistema.

Os objetos integrantes do sistema de tráfego podem possuir, com o paradigma de

orientação a objetos, “vida própria”. Então o grande desafio para este sistema era construir

um algoritmo (um sistema) que pudesse governar a enorme quantidade de objetos

presentes na simulação impedindo a todo custo que alguma atividade caótica viesse

acontecer e que violasse alguma lei de boa conduta no trânsito das grandes cidades. O

trânsito das grandes cidades está repleto de irregularidades e de arbitrariedades, porém,

ainda que o foco inicial para a construção do sistema, em virtude da falta de planejamento

do programador que trabalhou no projeto, fosse construir algo que simulasse

minimamente, também, as ações arbitrarias e aleatórias das pessoas no trânsito com o

intuito de tornar o sistema mais verossímil ao tráfego urbano de uma grande cidade mal

planejada por exemplo, essa abordagem foi abandonada e algo mais simples e regular

teve de ser pensado, pois os próprios problemas que emergiram como necessários para

garantir o funcionamento básico do sistema já foram grandes e despenderam tempo

suficiente para abandonar qualquer tentativa de construir algo mais realista. Sabe-se que

os grandes simuladores comerciais como o CORSIM e o PTV-VISSIM possuem uma

grande equipe de suporte e de talentosos desenvolvedores trabalhando exclusivamente

para a construção de algo que descreva bem a realidade e muitas vezes descobre-se, pelo

relato de pessoas que trabalham com esses softwares, que tais simuladores precisam de

uma delicada calibração para simular de forma relativamente verossímil a realidade como

ela é nos grandes centros. Ao ouvir um relato de um especialista que trabalha com o

simulador na UFRJ foi constatado que a calibração padrão para o VISSIM não representa

a realidade do centro da cidade do Rio de Janeiro, por exemplo, pois o sistema apresenta

parâmetros corretos para o comportamento dos condutores alemães e para as

características das vias na alemanha, que é o país de origem do simulador VISSIM. Por

tudo o que foi dito aqui, o autor apenas tem como objetivo afirmar que a construção e

calibração de um simulador de tráfego urbano rodoviário é algo extremamente complexo

e que por isso a adoção de algumas hipóteses simplificadoras foi realmente necessária

para tornar o trabalho exequível dentro de um prazo de seis meses.

32

Para a descrição geral do sistema será feito um relato da abordagem utilizada para

a medição de fluxo e a forma como os elementos integrantes do sistema emergem e

somem e o que governa o movimento de tais elementos ao longo de todo o percurso dentro

do mapa. Também será exemplificada e documentada cada ação possível de uma entidade

do sistema dentro do sistema e todos os elementos sensores que foram implementados, a

nível de código, (entenda como elemento sensor aquilo que possibilita a medição do fluxo

a fim de medir o efeito de otimização). O sistema implementa a simulação do tráfego em

um mapa de duas dimensões, mas o que se deseja atingir é a medida da melhoria obtida

ao se utilizar um determinado algoritmo de otimização semafórica em relação ao que se

tinha sem usá-lo e com um determinado valor fixo estipulado. Para atingir este objetivo

de medição a abordagem utilizada foi imaginar que o mapa em simulação pudesse ser

encarado como uma superfície fechada por um contorno extremo ( as linhas paralelas e

transversais que rodeiam o mapa ) e que fossem construídos meios para medir quantos

objetos cruzariam o mapa em um determinado tempo de simulação também estipulado

pelo usuário, além disso também foi construído um monitor, que descreve o número total

de veículos em fila ao final de cada ciclo de semáforos. Mas certamente ao final do tempo

de simulação estipulado pelo usuário haveriam muitos veículos que entrariam no mapa e

que não estariam aptos a concluir a passagem pelo mapa, pois ainda se encontrariam no

início na metade ou no fim de seus percursos. Soluções foram encontradas para este

problema e a simulação pode medir corretamente a quantidade fracionárias de veículos

que foi capaz de concluir suas rotas (cruzar o mapa completamente) ao longo de um tempo

de simulação definido. De agora em diante será discutida toda a base de estruturas de

dados e toda a base matemática onde o sistema se apoiou para realizar as simulações e ao

final desta introdução o leitor será capaz de entender de forma geral como o sistema

realiza as simulações.

3.2 – Implementação do Sistema

Como já havia sido comentado em um momento anterior, as entidades do sistema

são objetos de classes bem definidas e com funções bem definidas. Abaixo faz-se uma

33

enumeração de todas as classes existentes no sistema e em seguida é discutido e ilustrado

como cada uma destas classes é representada no mapa de simulação. Tal descrição

também encontrará explicações ao leitor para a pergunta sobre o porquê de as soluções

terem sido escolhidas desta maneira e implementadas desta maneira.

Classe Carro

Classe Semáforo

Classe Rua

Classe Malha

Classe Pontos de Caminho

Classe Rota

Classe Botão

A classe carro é a mais extensa e complexa de todas as classes, pois representa e

descreve em toda a sua totalidade o complexo comportamento de veículos no simulador.

Sua função principal é comandar o movimento dos veículos em função dos eventos que

ocorrem no mapa e também em função de outros veículos. Ela possui ao todo cinquenta

e um atributos e quinze métodos, sendo o seu maior método o método “updatePosition”,

que é o método responsável por desenhar a cada frame o veículo, que neste simulador é

representado por uma bolinha, em um ponto distinto do mapa. Abaixo mostramos o bloco

de UML (Unified Modelling Language) que descreve os nomes dos atributos e métodos

dessa classe.

A classe semáforo é a classe que descreve o comportamento dos semáforos (sinais

de trânsito) existentes no simulador, ela possui sete atributos e dois métodos. O diagrama

UML que representa esta classe está ilustrada no início do capítulo 4.

A classe rua possui informações sobre as ruas que são extremamente importantes

para a correto funcionamento do simulador. Ela possui cinco atributos e três métodos.

Sua descrição detalhada está ilustrada no início do capítulo 4.

34

A classe pontos de caminho também é importante porque a trajetória que os

veículos descrevem no mapa precisa passar por tais pontos. Ela é composta por sete

atributos e um método. Sua descrição está explicitada no inicio do capítulo 4.

A classe rota é uma classe que possui informações relevantes para que um veículo

descreva uma trajetória no mapa. Cada objeto veículo possui uma rota, cada objeto rota

possui um array de objetos da classe ponto de caminho. Esta classe, a classe rota, possui

dois atributos e cinco métodos que estão ilustrados também no capítulo 4.

A classe botão serve unicamente para implementar um botão de disparo da

simulação quando os dados de entrada do programa já foram imputados. Ela possui seis

atributos e quatro métodos que estão listados no capítulo 4.

O programa como um todo está centrado em duas etapas principais. O usuário

escreve um arquivo de ruas que então é lido pelo programa que devolve uma arquivo de

rotas. Então o usuário abre o arquivo de rotas e escreve manualmente quantos veículos

demandam a passagem por aquela rota específica da malha durante a simulação. Então o

programa lê agora o arquivo de rotas que então serve como “mola mestra” para realização

de toda a simulação de tráfego. E ao final do tempo de simulação, também estipulado

pelo usuário, o programa informa o número de veículos que cruzaram o mapa durante a

simulação. Este número geralmente é fracionário.

35

Figura 3.1 – Funcionamento geral do sistema

O arquivo de rua é um arquivo que possui em sua primeira linha uma série de

comentários sobre o que são especificamente cada um dos números que existentes nas

linhas de baixo do programa. Após essa primeira linha de descrição e comentários surge

uma linha abaixo que informa o número de linhas que existem no arquivo e que estão

abaixo dela. Abaixo desta linha que informa o número de linhas de arquivo que existem

abaixo dela, estão os dados de entrada para a malha de tráfego urbano sobre onde irá rodar

a simulação. Então o objetivo deste arquivo de ruas é descrever a topografia da cidade a

fim de que o usuário do sistema possa ter total liberdade para simular qualquer tipo de

topologia de uma cidade, mas o programa não fornece suporte para simulação de

topologias de cidade onde não existam exclusivamente retas paralelas e transversais

horizontais e verticais, o que torna o simulador limitado neste ponto, mas como o objetivo

do trabalho é medir experimentalmente os efeitos conseguidos em relação à melhoria de

fluidez que se consegue ao se realizar otimização semafórica, o simulador não peca em

generalidade. Abaixo é dado um exemplo, na figura 3.2, de como seria um arquivo deste

tipo.

36

Figura 3.2 – Formato do arquivo que descreve as ruas da malha

A primeira linha procura descrever todas as informações que estão abaixo da linha

que informa o número de linhas que existem abaixo dela (linha com a string “21”), x e y

indicam a posição do início da rua, extension e direction referenciam o comprimento da

rua e se ela é horizontal ou vertical. Sentido e name afirmam qual é o sentido de circulação

de veículos naquela rua e qual é o nome daquela rua (o nome é uma string). A variável

“signalOrNot” é uma variável do tipo string que diz se a rua em questão possui um sinal

de trânsito (semáforo) ou não. greenTimeBegin indica o tempo do início do sinal verde

para o semáforo daquela rua quando ele existe, greenTime indica o tempo de verde para

o sinal da rua quando ele existe, cicleTime indica qual é o tempo total do ciclo para todos

os semáforos envolvidos. No caso, o primeiro sinal a abrir é aquele que abre em dois

segundos e o ultimo sinal a abrir é aquele que abre aos cinquenta e oito segundos.

O arquivo de rotas, também já referenciado pela figura 3.1 como o arquivo de

saída da primeira computação do programa, é um arquivo que possui em sua primeira

linha somente comentários sobre a natureza dos dados que estão abaixo. Abaixo desta

primeira linha existe uma linha que informa quantas linhas existem abaixo desta linha

(desta segunda linha). Então após esta segunda linha existem uma série de outras linhas

que guardam informações sobre os pontos de caminho de existentes nas diferentes rotas.

O que existe na realidade é uma linha para cada ponto de caminho, porém a rota a qual

aquele ponto de caminho pertence não necessariamente é a mesma quando se vai de uma

37

linha pra outra. Cada linha contêm os valores de x e y para o ponto de caminho, o tipo da

transição o raio da transição e duas entradas booleanas que informam se aquele ponto de

caminho é um ponto de início de rota, fim de rota ou nenhum dos dois casos. A primeira

variável booleana da esquerda pra direita, quando verdadeira, afirma que aquele ponto de

caminho é um ponto de início de rota. A segunda variável booleana da esquerda pra

direita, quando verdadeira, afirma que aquele ponto de caminho é um ponto de fim de

rota. A figura 3.3 ilustra o formato do arquivo de rotas.

Figura 3.3 – Formato do arquivo de rotas

A primeira coluna à esquerda diz o índice da rota a qual aqueles pontos de

caminho pertencem, o que um usuário faz tipicamente no passo dois do uso deste

programa é inserir a quantidade de carros que vão demandar aquela rota ao longo da

simulação aplicando-se um tab após a última coluna à direita e após este tab fazendo-se

a inserção manual deste número para cada rota. É valido dizer que nesta figura acima não

estão sendo representadas as 54 linhas de pontos de caminho que este arquivo possui.

Muitas linhas foram ceifadas com o objetivo de proporcionar ao leitor uma melhor visão

38

do que é o arquivo de rotas. Então após inserir o número de veículos que estarão

demandando aquela rota durante a simulação o usuário salva o arquivo e aperta o botão

de simulação. O botão de simulação é o botão branco da figura 3.4, é valido dizer que

esta figura representa já a interface que o usuário possui com o simulador quando deseja

iniciar a simulação.

Figura 3.4 – Botão de inicio da simulação

Após apertar este botão a simulação inicia, um array de objetos da classe carro é

criado e inicializado. E então o que se faz é um sorteio para saber qual carro deste array

entrará no mapa primeiro. O sorteio pode ser imaginado como a experiência de retirar

39

uma bola de uma urna com zero uma ou mais bolas com um determinado índice de rota,

a ao retirar não se repõe a bola buscando de tempo em tempos retirar mais uma e mais

uma e mais uma. O sorteio de veículos para entrar no mapa possui uma analogia perfeita

com esta analogia de se retirar bolas de uma urna. Como cada uma destas etapas se

processa no programa será ilustrado melhor na seção seguinte quando começarem a ser

descritos os diagramas de classes, casos de uso e atividade.

Algo digno de menção aqui é a forma como o método que calcula as rotas

funciona. Este método precisa necessariamente de que todas as rotas que podem ser

obtidas a partir de uma rua de entrada do mapa não possuam uma forma de voltar para

alguma rua por onde ela passou. Ou seja, não devem existir ciclos no grafo que representa

todas as rotas passíveis de serem computadas a partir de uma rua de entrada. O que se

está querendo dizer em outras palavras é que as rotas passíveis de serem computadas a

partir de uma dada pista de entrada (pista que acede ao mapa da simulação, a cidade que

deseja-se simular) devem sempre formar estruturas de árvore, e nunca estruturas de grafos

cíclicos. A figura 5.5 abaixo mostra um exemplo de uma dada cidade encerrada pelo mapa

de simulação com suas pistas de entrada e de saída, que possui, para cada pista de acesso

(entrada) ao mapa, um grafo do tipo árvore. Para este tipo de mapa de cidade, neste caso

uma cidade muito pequena, onde não existem ciclos para o grafo, o algoritmo de obtenção

de rotas construído funciona perfeitamente

Figura 3.5 – Uma cidade hipotética

40

Repare que no mapa da cidade fornecida as linhas são as pistas de rolamento e

existem três tipos de raio para as curvas. As curvas de raio zero, as curvas com raio igual

a uma unidade de distância entre duas faixas de rolamento e as curvas com raio de duas

unidades de distância entre as faixas de rolamento. Agora observe na figura 5.6 um

exemplo de caso onde o algoritmo de obtenção de rotas entraria em um loop infinito em

virtude da existência de um grafo para uma das pistas de acesso do mapa que não é

efetivamente uma árvore e sim um grafo que apresenta ciclos.

Figura 3.6 – Uma cidade hipotética que poderia travar o algoritmo

Outro ponto interessante de ser citado é o fato de a árvore que representa todas as

possíveis rotas originárias de um determinado ponto de entrada no mapa (que tem um

determinado ponto de entrada no mapa, proveniente de uma pista que é de acesso ao

mapa) como sua raiz ter sempre no máximo 3 filhos para este simulador. A figura 5.7

novamente mostra o desenho da figura 5.5 porém desta vez tenta ilustrar quem são as

folhas de duas árvore de rotas para duas entradas, quem são suas raízes e quem são seus

nós internos. As raízes destas árvores, que são geradas pelo algoritmo, estão desenhadas

41

como círculos pretos. Os nós internos são círculos amarelos e as folhas estão

representadas por círculos verdes.

Figura 3.7 – Os pontos de caminho são os nós das árvores

Será comentada agora uma solução que foi empregada para resolver os problemas

que existiam em virtude de um veículo de uma determinada rota não reconhecer um outro

veículo de outra rota. Existem basicamente três formas de um veículo andar por uma rua.

Essas três formas estão explicitadas na enumeração abaixo.

Para um determinado veículo em um determinado passo de sua rota o ponto de

caminho que o permite concluir o próximo passo de sua rota (o de uma unidade

maior que o atual passo de rota que está desempenhando) é o mesmo que o ponto

de caminho de um veículo que já está no passo da rota que possui aquele mesmo

ponto de caminho como o de conclusão

Para um determinado veículo em um determinado passo de sua rota o ponto de

caminho que permite ao veículo concluir aquele passo da rota é o mesmo que o

ponto de caminho de outro veículo, com rota diferente da sua, porém os pontos de

42

caminho de conclusão dos próximos passos das rotas destes veículos são

diferentes

Para um determinado veículo em um determinado passo de sua rota o ponto de

caminho que o permite concluir aquele passo da rota e o ponto de caminho que o

permite concluir o próximo passo de sua rota é igual ao ponto de caminho que

permite a um outro veículo concluir o atual passo de sua rota e o próximo passo

de sua rota respectivamente ( lembrando que, exceto no primeiro caso, ambos os

veículos estão na mesma rua ), este caso que estamos descrevendo é o que

compreende veículos pertencentes a rotas de mesmo índice

Existem três contadores medidores de distância em relação a específicos pontos

de referência. O primeiro deles mede a distância total percorrida pelo veículo em relação

ao início de sua rota, que é um ponto extremo do mapa. Este primeiro contador é utilizado

sempre que se deseja saber a distância relativa entre veículos de mesma rota. Mas se os

veículos não pertencem a uma mesma rota e possuem posições que fazem valer alguma

das situações (condições) descritas acima, então são atribuídos ao segundo contador do

veículo perseguidor e ao terceiro contador do veículo perseguido valores de posição

relativas a uma dada referência do mapa (geralmente algum ponto de caminho comum de

suas rotas) para que o cálculo de suas posições possa ser feito e os mesmos não colidam

nem desprezem um a existência do outro. Para a implementação desta solução foi

necessária a criação de uma estrutura de dados denominada “ArrayList”, que é algo como

o container “Vector” no C++, que armazena de forma dinâmica objetos. A distância

percorrida absoluta, ao se atingir um dado ponto de caminho, dentro de sua rota, foi a

informação mais relevante criada dentro do objeto que foi armazenado no “ArrayList”.

43

Capítulo 4

Arquitetura do Sistema

4.1 – Descrição Aprofundada de Classes

Abaixo temos a descrição precisa dos métodos e atributos que existem dentro de

cada classe do sistema implementado.

Car

Float x , y // abscissa e ordenada do veículo

Float xMoveOrientation, yMoveOrientation // sentido da movimentação nas direções

Int routeindex // indice da rota que o veículo está descrevendo

Int carIndex // indice do veículo, número que fornece sua identificacao

Int xNxt, yNxt, newTransitionKind, newTransitionRadius // abscissa do proximo ponto

de caminho, ordenada, número que identifica o tipo de transição que será feita, raio

dessa nova transição

Int newTransitionSpace // espaço que o veículo atravessa em linha reta num novo

cruzamento

Float xC , yC // xC e yC , sao abscissa e ordenada dos centros das curvas, quando

a curva nao possui raio zero

Int counterOfDotTransition // Contador que impementa uma parada do veículo quando

esta no vertice de uma curva de raio zero

Route route[] //ponteiro para array de um elemento do objeto rota

Boolean ontrack // variavel que diz que o veículo está na pista (em simulação)

Boolean insideTheCurve // variavel que diz que o veículo está dentro de uma curva

Boolean endOfRoute // variavel que diz que o veículo atingiu o final da rota

Int currentStepOfRoute // variavel que diz qual é o passo atual da rota descrita pelo

veiculo

Float speed // velocidade do veiculo

Float acel // aceleracao do veiculo

Float goalSpeed // variavel usada a fim

Float goalSpace // variavel usada a fim de controlar os espacos de aceleracao e

frenagem do veiculo

Boolean brake // flag que indica que o veículo está frenando

Boolean Aceleration // flag que indica que o veículo está acelerando

Boolean hereWeHaveSemaphor // flag que indica que na rua atual existe um semaforo

Boolean cameFromCurve // flag que indica que o veículo acabou de descrever uma

curva

Boolean signalAlreadySeen // flag que indica que o veículo viu o sinal a frente

Boolean crossedSignal // flag que indica que o veículo cruzou a linha do semaforo

44

Boolean ifRoadHasSignalAlreadyVerified // flag que indica que a existencia de sinal

na rua ja foi verificada

Boolean firstEntrance // flag de controle usado pra resolver problemas de achar o

veiculo mais proximo quando um veículo entra em simulacao

Boolean persecute // flag usado pra resolver problemas de controle quando o veículo

ainda reconhece um veículo a sua frente porem nao deseja perseguilo

Boolean haveConditionToCrossSignalAlreadyVerified // verifica se já foi verificada

a possibilidade de cruzar o proximo sinal verde em verde

Boolean haveConditionToCrossSignal // valida se o veículo vai cruzar o proximo sinal

ainda em verde ou não

Boolean willCloseCrossingVerified // verifica se a análise sobre a possibilidade do

veiculo fechar o sinal já foi verificada

Boolean iWillCloseCrossing // diz se o veículo vai fechar o cruzamento ou nao

Int advanceSignal // flag de controle que assume um dentre tres estados

Int ancientStepOfRoute // flag que indica quale o passo antigo da rota

Int currentRoad // flag que indica quale a rua atual em que o veículo esta

Int carAhead // extremamente importante, flag que indica qual é o carro que está a

frente do atual

Float speedAtLargeCurves // velocidade nas grandes curvas

Float speedAtShortCurves // velocidade nas pequnas curvas

Float spaceBefore // espaco entre um veículo e o início da curva

Float speedAtActualCurve // espaco na curva atual

Float totalRouteSpaceTraversed // espaco total transladado pelo veículo em sua rota

Float totalRouteSpaceTraversed2 // segundo contador, usado para perseguicao de

veiculo de rota distinta

Float totalRouteSpaceOfTheRoute // espaco total de translado para aquela rota

Float distanceBetween // distância entre o veículo e o proximo semaforo

Float

Car(int , int ,int , Route, boolean, int, int, int)

Float getTotalRouteSpaceOfTheRoute()

Float setNewPositionAndTheAmountToAdd()

Void display()

Void onTrack()

Boolean carEntersNormally()

Void setPosition()

Void slowSpeedInFrontOfSemaphor(float, float)

Float verifyIfRoadHasSignal()

Void slowSpeedNearCurvesAcelerateFrenate()

Void getDecelerationInFrontOfCurves(float , float)

Void updatePosition()

Void doCurveRadiusNotZero(float)

Void doCurve(float)

Boolean inWhichOrientationWrite( Waypoint )

45

Semáforo

Int precedence // precedencia

Int timeToStayGreen

Int x

Int y

Int greenTime // tempo de verde

Int greenTimeBegin // início do tempo de verde

Int cicleTime // tempo total do ciclo

Int numberOfCicle // variavel que indica o indice do ciclo para o semaforo em

simulação

Boolean greenSignal // flag que serve para “pintar” o semaforo de verde ou vermelho

String nameOfStreet //nome da rua a qual o semaforo pertence

Semaphore (int , int ,int ,int, boolean, boolean, String)

Void timeToGoGreen()

Rua

Int x // posicao x inicial da rua

Int y // posicao y inicial da rua

Int extension // extensão da rua

Int sentidoOf // sentido da rua

String direction // posicionamento da rua se ( se é horizontal ou vertical )

String nameOfStreet // nome da rua

Boolean haveSemaphor // se a rua tem semáforo ou não

String semaphor // string com valor Y ou N que diz se existe um semáforo na rua

Semaphore semaphore // objeto semáforo daquela rua

Track (int , int , int , String , int , String , String , int , int , String)

Track (int , int , int , String , int , String , String)

Void display()

Malha

Int numberOfTracks // número de ruas que compõem a malha

Route route [ ] // array de objetos da classe rota que indica todas as rotas que a

malha possui

Track t [ ] // array de objetos da classe track que indica quais ruas compõem

a malha

Tracks (int)

46

Void displayTracks()

Void generateRoutes()

Int generateRoute ( int , Route [] )

Int getValidIntersections(int , Route [])

Void copyCommonWaypointsTo(Route [] , int , int)

Ponto de Caminho

Int x // abscissa do ponto de caminho

Int y // ordenada do ponto de caminho

Int kindOfTransition // tipo de transição

Int radiusOfTransition // raio da transição

Int associatedRoadIndex // índice associado da rua

Boolean endOfRoute // flag que indica se aquele ponto de caminho é de fim de

rota

Boolean beginOfRoute // flag que indica se aquele ponto de caminho é de início de

r

Waypoint(int, int, int, int, boolean, boolean, int)

Rota

Waypoint waypoint [] // array pontos de caminho

Int waypointsEdge // número de pontos de caminho

Route ()

Void insertNewWaypoint(int, int, int, int, boolean, boolean, int)

Void insertNewWaypoints(int, int, int,int,int)

Void insertNewWaypointss(int, int, int, int, int)

Void insertNewWaypointsss(int, int, int, int, bool, bool, int)

Botão Float x // abscissa de início da caixa que define o botão

Float y // ordenada de início da caixa que define o botão

Float w // largura da caixa

Float h // altura da caixa

String s

47

Button (float , float , float , float , String )

Boolean inside ( float , float )

Int getNumberOfBoxPerColumn ( float , float )

Void draw()

Nesta seção do trabalho será dada uma explicação mais aprofundada a respeito

dos atributos e métodos de cada classe a fim de “preparar o terreno” para futuras

discussões mais detalhadas sobre o comportamento do sistema que empregarão diagramas

de atividade e diagramas de fluxo e documentos de casos de uso. Tal introdução aos

métodos e atributos das classes é importante para que o leitor possa ter o embasamento

necessário à compreensão dos casos de uso e diagramas de fluxo que estarão sendo

representados a posteriori. Na figura 3.9 estão representadas as relações existentes entre

as classes com a notação relacional para dar uma ideia de qual é o tipo de relacionamento

existente entre as classes. Para gerar as relações exibidas no diagrama abaixo o que se fez

foi criar atributos que representam arrays dos objetos das relações dentro dos objetos com

índice um quando esta relação é de um para “n”. E quando esta relação é exprimida como

de um para um foi criado dentro do objeto um atributo que representa um array ponteiro

de somente um elemento para o o objeto relacionado (na prática um único ponteiro).

Figura 3.9 – Relacionamento existente entre as classes

48

4.2 – Casos de Uso

Nesta seção do trabalho será representada uma série de casos de uso que

descreverão de uma maneira alternativa as características do simulador com ênfase em

sua funcionalidade. Mas especificamente abaixo estão apenas descritos os casos de uso

que dizem respeito ao comportamento dos veículos na tela de simulação. Em outras

palavras nada é dito aqui sobre os casos de uso e funcionalidades que precisam ser

executadas quando da inicialização do ambiente de simulação (ou seja, criação de rotas,

criação de mapas, criação de sinais de trânsito), mas somente do comportamento dos

agentes mais diretos do sistema de trânsito (os veículos).

UC01 - Sortear um veículo para entrada no mapa

Objetivo Sortear um veículo do array de veículos

Atores Sistema

Pré - Condições Possuir o array de inteiros que representa veículos em

rotas com espaço adequado alocado e inicializado

Frequência de Uso Sempre de tempos em tempos com o tempo estipulado

pelo usuário

Trigger Uma determinada quantidade de tempo desde o último

sorteio se passa e surge a necessidade de sortear denovo

Fluxo Principal 1. Um array que relaciona cada rota com o número de

veículos que não iniciaram o percurso e que são

daquela rota é lido, seus elementos são somados.

[A1]

2. Um outro array é inicializado com tamanho igual

ao número de veículos que ainda nem entraram no

mapa e cada elemento deste array possui o valor da

rota ao qual tal elemento pertence.

3. Uma função randômica é chamada, sorteia um

elemento dentre 0 e comprimento_array-1 para

decidir qual carro de qual rota vai entrar.

4. Uma unidade é decrementada na entrada

correspondente à rota sorteada no array que

49

exprime quantos carros existem, para cada rota,

que ainda nem entraram no mapa.

Fluxo Alternativo [A1] A soma dos elementos dá zero:

1. O array de sorteio é alocado com zero entradas (não

é alocado) e a função termina sem a realização de

sorteio.

Pós - Condições 1. Um carro de uma dada rota é sorteado para entrar

no mapa

2. Uma unidade do array de rotas e veículos para

entrar naquela rota, do índice que representa a rota

especificamente, é decrementada.

Regras de Negócio Não há

UC02 – Atualização da posição de veículos no mapa

Objetivo Atualizar a posição dos veículos a cada novo frame

Atores Sistema

Pré - Condições Possuir o array de objetos da classe veículos alocado e

corretamente inicializado

Frequência de Uso A cada frame da animação

Trigger Mais um intervalo de tempo entre frames se passou e

existe a necessidade de gerar um novo frame

Fluxo Principal Inicializa-se um contador com o valor zero:

1. Verifica-se se o valor do contador é menor do que o

tamanho do array de objetos da classe veículo

2. Atualiza-se as posições de todos os veículos que

estão no mapa por intermédio de uma chamada ao

método da classe veículo chamado updatePosition

[A1]

3. Incrementa-se o contador e volta-se ao número 1

Fluxo Alternativo [A1] Constate-se que o referido objeto do array não foi

para o mapa ainda:

1. O método da classe veículo “onTrack()” é chamado

e a tarja que classifica o veículo como existente no

mapa é tornada verdadeira

2. O veículo é posicionado em algum lugar adequado

no mapa (este lugar pode ser inclusive fora do mapa

e ainda sim o veículo estará sendo simulado)

50

3. Incrementa-se o contador e volta-se ao número 1 do

fluxo principal

Pós - Condições Todos os veículos que já estavam no mapa possuem uma

posição atualizada e eventualmente um novo veículo terá

sido inserido com uma posição adequada

Regras de Negócio Não há

UC03 – Verificação da existência de um sinal de trânsito na via

Objetivo Localizar em qual via o veículo se encontra e entender se a

via possui um sinal de trânsito ou não

Atores Sistema

Pré - Condições O veículo precisa estar na simulação

Frequência de Uso Toda vez em que o veículo adentrar uma pista diferente do

array de pistas

Trigger O veículo conclui mais um passo da rota e entra numa

pista com índice diferente da pista em que estava

anteriormente

Fluxo Principal 1. O método verifica em que direção o veículo se move

(horizontal? vertical? direta para esquerda?

esquerda pra direita?)

2. O método busca iterativamente, em todas as ruas,

qual é aquela onde o veículo está inserido

3. O método encontra o índice da rua em questão e

inicializa corretamente o atributo “currentRoad

Index” adequadamente para aquele objeto veíc-

ulo

4. O método seta a variável o atributo que indica q

ue o veículo está em uma rua que possui sinal de

trânsito como verdadeiro[A1]

Fluxo Alternativo [A1]

1. O método seta a variavel, o atributo que indica q

ue o veículo está em uma rua onde existe sinal de

trânsito como falso

Pós - Condições O método seta os flags seta a variável com o índice da rua

em que o veículo se encontra e a variável booleana que

indica se a rua possui sinal ou não

Regras de Negócio Não há

51

UC04 – Obtenção da distância que separa o veículo do próximo sinal de trânsito

Objetivo Obter a distância que separa o veículo do sinal daquela

rua

Atores Sistema

Pré - Condições A rua deve possuir um sinal de trânsito

O veículo ainda não cruzou o sinal

Frequência de Uso A todo frame

Trigger É averiguado que a rua possui um sinal de trânsito

Fluxo Principal 1. Verifica-se em que direção e sentido o veículo está se

movimentando

2. Utilizando a variável “currentRoad” calcula-se a

distância entre o veículo e a linha do próximo sinal

[A1]

3. O método retorna esta distância

Fluxo Alternativo [A1] O veículo ultrapassou a linha do sinal de trânsito:

1. O método atribui ao atributo “crossedSignal” o

valor true e retorna a distância 9999

Pos - Condições O método retorna a distância ao sinal e diz se o veículo já

cruzou o sinal ou não

Regras de Negócio Não há

UC05 – Acelerar ou freiar como reação ao estado do sinal

Objetivo Obter a aceleração que deve ser aplicada ao veículo para

que ele possa parar exatamente atrás da linha do semáforo

Atores Sistema

Pré - Condições A rua possui sinal, a distância ao sinal foi calculada

Frequência de Uso O tempo todo, porém só faz algo em transições de sinal

Trigger O sinal muda de vermelho para verde ou de verde para

vermelho

Fluxo Principal Sinal a frente está vermelho:

1. Verifica se o sinal está vermelho e se ainda não foi

cruzado

52

2. Calcula-se uma desaceleração com base na equação

de torricelli

3. Seta-se os flags de aceleração e freio em falso e

verdadeiro respectivamente e atribui-se ao atri

buto aceleração a aceleração de torricelli [A1]

Sinal a frente está verde:

1. Verifica-se se por um acaso o flag que diz se o

veículo irá fechar o cruzamento está em falso

2. O flag que define a questão do veículo fechar o

cruzamento está em falso e daí o veículo

acelera[A2]

3. Os flags de aceleração e freio são setados como ver-

dadeiro e falso respectivamente e a aceleração pad

rão é atribuída ao atributo aceleração

Fluxo Alternativo [A1] A aceleração necessária é elevada demais:

1. O flag de avanço de sinal é setado e o veículo age c

omo se o sinal não existisse

[A2] O flag está em verdadeiro:

1. O veículo desacelera e vai parar atrás do sinal,

mesmo o sinal estando verde

Pós - Condições Alguma atitude é tomada em resposta ao estado do sinal a

frente

Regras de Negócio Não há

UC06 - Encontrar um líder mais proximo para seguir

Objetivo Encontrar um líder mais próximo e não colidir ou passar

por cima dele ignorando sua existência

Atores Sistema

Pré - Condições Os veículos envolvidos precisam estar no mapa de

simulação

O veículo líder e o seguidor precisam possuir um

ponto de caminho em comum em suas rotas

Frequência de Uso O tempo todo (a cada frame)

53

Trigger O método updatePosition do objeto veículo é chamado

para um dado veículo

Fluxo Principal

1. O contador i é setado com zero

2. Veículo pergunta para um dado veículo de índice i

se ele está na mesma rua que a sua e se as suas

próximas ruas são iguais[A1][A2][A3]

3. Veículo imputa a distância entre eles na variável

“menor” que quando do inicio do método apres-

entava o valor 9999

4. É verificado se o valor da menor distância encon-

trada é menor do que um limiar para que se pos

sa considerar o veículo como realmente um líder d

e menor distância para aquele veículo[A4]

Fluxo Alternativo [A1] Os veículos estão em uma mesma rua, porém as

próximas ruas são distintas:

1. Veículo imputa a distância entre eles na variável

“menor”, que quando do início do caso de uso

apresentava valor 9999

2. É verificado se o valor da menor distância encon-

trada é menor do que um limiar para que se pos

sa considerar o veículo como realmente um líder d

e menor distância para aquele veículo[A4]

[A2] Os veículos estão em ruas distintas porém a próxima

rua do veículo que chamou o método é igual à rua atual do

outro veículo:

1. Veículo imputa a distância entre eles na variável

“menor”, que quando do início do caso de uso

apresentava valor 9999

2. É verificado se o valor da menor distância encon-

trada é menor do que um limiar para que se pos

sa considerar o veículo como realmente um líder d

e menor distância para aquele veículo[A4]

[A4] O líder em questão está mais distante que o máximo

permitido:

54

1. O índice que havia sido imputado para o atributo ca

rAhead do objeto seguidor, que identificava o seu lí

der, agora fica com o valor -1, pois ele está muito di

stante

Pós - Condições O veículo em questão se vincula ou não a um outro veículo

a sua frente

O método toma a atitude necessária para evitar que o

veículo da frente tenha sua existência desprezada

Regras de Negócio Não há

Após esta primeira etapa em que foram tratados casos de uso exclusivos da classe

dos veículos, que tratavam das funções de controle dos veículos, serão mostrados os casos

de uso referentes à classe “malha” que trata da correta geração dos pontos de caminho,

da correta exibição das pistas, dos sinais de trânsito, assim como a correta geração de

rotas possíveis para os veículos. Mais adiante um curioso fenômeno passível de acontecer

quando da execução do algoritmo de geração de rotas será mostrado, porém neste

momento o mais importante é mostrar todos os casos de uso possíveis dentro do escopo

desta classe. Será dada maior ênfase nas questões referentes aos seus métodos, que não

são tantos quanto os da classe carro, mas que ainda sim são numerosos. O papel de cada

atributo já foi explicado detalhadamente na seção anterior.

UC 07 – Exibição das ruas

Objetivo Exibir todas as ruas que foram escritas pelo usuário no

arquivo de ruas

Atores Sistema

Pré - Condições O objeto da classe malha precisa possuir seu array de ruas

devidamente alocado e inicializado

Frequência de Uso A todo tempo (a cada frame)

Trigger O usuário aperta o botão que inicia a simulação.

Quando do “setup” do programa

Fluxo Principal 1. A função seta a grossura das linhas e a cor das linhas

usando as duas macros apropriadas usando funções

da biblioteca processing

55

2. O método “display” para cada objeto do array de

objetos track que é atributo da classe “malha” é

chamado

Fluxo Alternativo Não há

Pós - Condições Uma repintura de todo o desenho das ruas bem como uma

repintura do estado atual dos sinais das ruas é conseguida

Regras de Negócio Não Há

UC08 – Geração de todas as rotas possíveis

Objetivo Sistema inicializa um array de objetos da classe rota que é

um array de escopo global

Atores Sistema

Pré - Condições O array de ruas do sistema precisa estar devidamente

alocado e inicializado

Frequência de Uso Somente quando do início do código do programa, na sua

fase de setup

Trigger Ao final da inicialização do array de objetos da classe rua

Fluxo Principal 1. Método verifica para cada rua se aquela rua possui

uma extremidade em alguma das extremidades do

mapa

2. A rua possui uma extremidade em alguma extremid

ade do mapa, então um objeto da classe rota é criad

o e atribui-se ao primeiro ponto de caminho deste

objeto criado a abscissa e ordenada daquele ponto

da rua que é extremo e que toca na extremidade do

mapa

3. A função “getValidIntersections()” é chamada e ela

inicializa todas as rotas que possuem início naquela

extremidade da rua , naquela entrada do mapa

Fluxo Alternativo Não Há

Pós - Condições Um array de objetos da classe rota é alocado e

devidamente inicializado para as condições de entrada do

arquivo de pistas.

Um arquivo de rotas é criado e devidamente inicializado

Regras de Negócio Não Há

UC09 - Verificar se veículo irá fechar cruzamento

Objetivo Sistema verifica se o avanço para a próxima rua, após um

sinal verde é possível ou não

56

Atores Sistema

Pré - Condições O veículo precisa não já possuir o flag de inspeção do

cruzamento setado, deve não já ter cruzado o sinal e o

sinal a sua frente deve estar verde

Frequência de Uso Toda vez que um sinal está verde na frente do veículo,

porém somente uma vez

Trigger O sinal muda de vermelho para verde na frente do veículo

Fluxo Principal 1. Veículo verifica se o sinal de sua rua está

verde[A1]

2. Veículo verifica se algum veículo a sua frente

(caso exista) já verificou se vai fechar o

cruzamento ou não[A2]

3. Veículo verifica se existem espaço para avançar

na próxima rua[A3]

4. Veículo avança para a próxima rua

Fluxo Alternativo [A1] O sinal a frente não está verde:

1. Veículo não faz mais nada

[A2] O veículo da frente ainda não verificou cruzamento:

1. Veículo não faz mais nada

[A3] Não existe espaço para avançar:

1. Veículo não faz mais nada

Pós - Condições Veículo analisa se na rua a frente existe espaço para entrar

Regras de Negócio Não Há

UC10 – Verificar se veículo possui condições de sair da rua durante o verde

Objetivo Verificar se o veículo vai ocupar espaço da via

Atores Sistema

Pré - Condições O veículo ter entrado na rua, o sinal da rua estar verde

Frequência de Uso Assim que o veículo entrar na rua e o sinal estiver verde e

somente uma vez

Trigger O veículo entra na rua e o sinal está verde

Fluxo Principal 1. Veículo entra na rua

2. Veículo observa que o sinal está verde

3. Veículo estima se vai conseguir atravessar o sinal

antes dele entrar em vermelho

57

4. Veículo retira seu espaço da pista afirmando aos

que chegam que seu espaço não estará mais sendo

ocupado quando o sinal fechar[A1]

Fluxo Alternativo [A1] Veículo verifica que não conseguirá cruzar sinal

verde:

1. Veículo mantém sua posição alocada quando alocou

da pergunta sobre o número de vagas que fez

quando da rua anterior

Pós - Condições O veículo possui condições de informar aos veículo que

estão tentando aceder à pista se sua vaga será ocupada

Regras de Negócio Não Há

UC11 – Verificar novamente se o veículo irá fechar o cruzamento

Objetivo Verificar novamente se o veículo irá fechar o cruzamento

Atores Sistema

Pré - Condições O veículo já ter verificado antes se vai fechar o

cruzamento e receber a resposta de que sim

Frequência de Uso Toda vez que um veículo pergunta se vai fechar um

cruzamento e recebe uma resposta positiva

Trigger Um veículo ter recebido a notícia de que vai fechar um

cruzamento

Fluxo Principal 1. O veículo recebe a notícia de que irá fechar o

cruzamento

2. O veículo seta um timer que diz que dentro de um

determinado intervalo de tempo ele vai fazer a

pergunta sobre fechar o cruzamento denovo

3. O tempo se esvai e então, com o sinal a sua frente

verde, ele pergunta se vai fechar o cruzamento

denovo

4. O veículo verifica que não irá fechar o cruzamento e

avança sobre o sinal verde[A1]

Fluxo Alternativo [A1] O caso de uso recomeça:

Pós - Condições O veículo possui total consciência sobre a possibilidade de

avançar ou não o cruzamento

Regras de Negócio Não há

UC12 – Desacelerar veículo para entrar em uma curva com velocidade compatível

58

Objetivo Fazer veículo entrar em curva adequadamente

Atores Sistema

Pré - Condições Veículo não estar perseguindo outro

Frequência de Uso A cada frame

Trigger Condicionais de controle de veículo e desligamento são

analisadas

Fluxo Principal 1. Verifica-se se o veículo acabou de realizar uma

curva[A1]

2. Verifica-se se o veículo não persegue ninguem, já

verificou a possibilidade de fechar o cruzamento e

não vai fechar o cruzamento[A2]

3. Veículo verifica se já se encontra a uma distância

igual ou menor à distância necessária para

desacelerar com velocidade constante e entrar na

curva com a velocidade adequada ao raio da curva

Fluxo Alternativo [A1] A condição é satisfeita:

1. Veículo acelera [Fluxo Principal]

[A2] A condição é satisfeita:

2. Veículo acelera [Fluxo Principal]

Pós - Condições Veículo é devidamente controlado para não entrar na

curva com velocidade inadequada

Regras de Negócio Não Há

4.3 – Diagramas de Estado

Nesta seção será exibida uma série de diagramas de estado. Tal forma de

representação é perfeita para designar todos os comportamentos que a classe carro e suas

funções adjuntas assumem quando da representação (emulação) da direção automática

dentro das restritas regras lógicas e limitações da programação. O autor considera o

trabalho de desenvolvimento de um simulador de tráfego urbano como a oportunidade

perfeita para se familiarizar com os diagramas de estado precisamente porque quando um

veículo é dirigido em uma cidade por alguém ele é a analogia perfeita de algo que assume

uma sequência de estados. Sabe-se que a direção de um veículo, apesar de complexa,

possui uma finita gama de opções e de estados possíveis em cada instante de tempo, desta

forma a descrição por diagrama de estados é perfeita para sistematizar todo o

59

comportamento da direção. Tal descrição, como ensinada pela literatura, apresenta um

conjunto de estados interligados por setas de transição e com uma descrição de um estado

para a classe desempenhando um dado caso de uso dentro de um balão, e um nome para

cada estado que enfatize de uma forma bastante precisa o que cada estado representa. A

série de diagramas de estado que será exibida abaixo representa os casos de uso cinco,

seis, oito, nove, dez.

UC – 05 ( Acelerar ou Freiar como Reação ao Estado do Sinal )

1

Veículo desacelera

segundo toriccelli

Veículo fura o sinal

acelerando ou

frenando

Veículo acelera em

virtude do sinal estar

verde

Veículo acelera para

se aproximar de um

sinal vermelho

Veículo não acelera

em virtude do sinal

estar verde

60

UC – 06 ( Encontrar um líder mais próximo para seguir )

UC – 08 ( criador de rotas na fase de setup )

Veículo está vinculado a

outro que possui

próximo ponto de

caminho igual a seu

próximo próximo ponto

de caminho

Veículo está vinculado a

um veículo que possui

próximo ponto de

caminho igual ao seu,

porém com próximo

próximo ponto diferente

Veículo está vinculado a

um veículo que possui

próximo ponto de caminho

igual ao seu e próximo

próximo ponto de caminho

também igual

61

2

UC – 09 ( Verificar se veículo irá fechar cruzamento )

UC – 10 ( Verificar se veículo possui condições de cruzar o próximo sinal ainda em

verde )

4.4 – Diagramas de Fluxo

Diagramas de fluxo são diagramas que representam os diversos fluxos de

execução dos programas de computador em cada um de seus casos de uso. Nesta seção

serão descritos os mesmos casos de uso da seção anterior (naquela seção foram diagramas

de estado), porém agora dando ênfase às variáveis e suas variações de valor ao longo de

diversos fluxos de execução para cada caso de uso. Os casos de uso representados pelos

diagramas de fluxo serão UC-05, UC-06, UC-08, UC-09, UC-10, UC-11 e UC-12.

Rua com

extremidade na

borda do mapa

de entrada

obtida

Interseções da

rua com outras

ruas verificadas

Rua com

extremidade na

borda do mapa

de saída

Outra rua

selecionada e

ponto de

caminho

salvo

Situação de sinal

verde verificada

Existência de veículo

a frente que ainda não

perguntou se vai

fechar cruzamento

verificada e permissao

para alocar espaco na

pista obtida

Conhecimento

sobre situação

do cruzamento

obtido

Estimativa sobre

possibilidade de

cruzamento do

próximo sinal obtida

Sinal verde

observado

Veículo retira seu

espaço reservado

na pista dando

chance para outro

ocupar

62

UC – 05 (Acelerar ou Frenar Como Reação ao Estado do Sinal)

UC – 06 (Encontrar um Líder mais Próximo para Seguir)

Sinal

Verde

?

Fechar

Cruza

Mento

?

advanceSignal = 2;

brake = false;

aceleration = true;

signalAlreadySeen =

false;

ifIWillCloseCrossin

gAgainTimer =

CICLESTOANAL

YSECROSSINGA

GAIN;

willCloseCrossing

Verified = false;

advanceSignal = 0;

Aceleração

maior que a

permitida ? advanceSignal =

1;

signalAlreadySeen

= false;

advanceSignal = 0;

signalAlreadySeen

= true;

brake = true;

aceleration = false;

Ruas

Atuais e

próximas

iguais ?

Ruas atuais

iguai e

próximas

distintas ?

Rua

próxima

igual a

rua atual

?

cb.totalRouteSpaceTravers

ed3 = aux2;

ca.totalRouteSpaceTravers

ed2 = aux;

contadores inicializados

cb.totalRouteSpaceTravers

ed3 = aux2;

ca.totalRouteSpaceTravers

ed2 = aux;

contadores inicializados

cb.totalRouteSpaceTravers

ed3 = aux2;

ca.totalRouteSpaceTravers

ed2 = aux;

contadores inicializados

63

UC – 08 (Criação de todas as rotas na fase de setup)

UC – 09 (Verificar se veículo irá fechar cruzamento)

Pista

Termina

l de

Entrada

?

Pista de

Interseç

ão ?

Pista

Termin

al de

Saida ?

O sinal

está verde

e não foi

cruzado ?

Chance de

fechar

cruzament

o

verificada

?

Fechará

Cruzamento

iWillCloseCross

ing = true;

willCloseCrossi

ngVerified =

true;

Não fechará

cruzamento

iWillCloseCrossing

= false;

willCloseCrossingV

erified = true;

64

UC – 10 (Verificação sobre a possibilidade de cruzar o próximo sinal)

UC – 11 ( Verificar novamente se o veículo irá fechar o cruzamento )

Timer sobre tempo de

cruzamento setado

ifIWillCloseCrossingAgai

nTimer =

CICLESTOANALISEIFI

WILLCLOSECROSSING

AGAIN

willCloseCrossingVerifie

d = false;

Contado

r já

extingui

u seu

valor ?

O sinal

está

verde ?

Veículo

possui

condições

de cruzar o

sinal em

verde ?

iWillCrossCrossing =

true;

willCrossCrossingVerifi

ed = true;

ts.t[currentRoad].reserve

dSpaces--;

iWillCrossCrossing =

false;

willCrossCrossingVerifie

d = true;

65

UC – 12 ( Controle do veículo diante de curvas )

Veículo

acabou de

sair de

uma

curva ?

Veículo não

irá fechar

cruzamento,

ninguem na

sua frente ?

Distância

entre pista e

veículo

propicia para

frenagem ou

menor que a

necessária ?

Brake = true;

Aceleration = false;

Acel = DECELERATION;

Veículo

possui outro

veículo a

sua frente ?

Brake = true;

Aceleration = false;

Acel = DECELERATIO;

Persecute = false;

Brake = false;

Aceleration = true;

Acel = ACELERATION;

Brake = false;

Aceleration = true;

Acel = ACELERATION;

cameFromCurve = false;

66

Capitulo 5

Conclusões

5.1 - Conclusões

O trabalho de programação realizado neste projeto final foi importante para o seu

autor, pois proporcionou um aprendizado em lógica booleana, algoritmos de inteligência

artificial para direção de veículos (assunto de pesquisa em muitas universidades mundo

afora), estruturas de dados da computação engenharia de software e lógica de

programação. Seu autor experimentou um crescimento da capacidade de pensar em

algoritmos e estruturas de dados para a solução de problemas do mundo real. O trabalho

obteve um sólido suporte de diferentes artigos científicos nos temas de otimização,

engenharia de software e engenharia de tráfego.

A vantagem sobre a utilização de algoritmos que levem em conta o número de

veículos requisitantes de cada rota e a maximização da banda verde foi mais expressiva

no monitor de desempenho chamado número de veículos em fila, este monitor media, ao

final de cada ciclo de semáforos, o número de veículos que estavam aguardando abertura

do sinal vermelho para seguirem em suas rotas. Como exibida na tabela da figura 2.4. A

computação gráfica, permitindo a visualização dos fatos que o programa aferiu ao longo

do tempo de simulação de tráfego foi uma importante aliada, pois foi possível a

visualização daquilo que se estava medindo. O que se obteve não foi somente uma

verificação numérica, mas também uma verificação visual dos fatos.

Para futuros trabalhos sobre este simulador pode-se citar a programação de um

algoritmo realmente adaptativo em tempo real que leve em conta o número de veículos

em fila antes de cada sinal vermelho ao final de cada ciclo dos semáforos. Acredita-se,

por impressão visual da simulação, que tal algoritmo poderia reduzir ainda mais

drasticamente o número de veículos em fila ao final de cada simulação. O proposito inicial

67

do trabalho era verificar como tecnicas de engenharia de tráfego e otimização poderiam

aumentar a velocidade média do tráfego como um todo e isto foi demonstrado.

Poderia ser citada também, como melhorias adicionais para este simulador, a

programação de comportamentos mais realistas de veículos seguindo outros veículos,

bem como alguns comportamentos de ultrapassagem e alguma aleatoriedade nas

frenagens e acelerações dos veículos quando da realização de suas rotas. Bem como

pontos de parada para transportes coletivos e melhor aproveitamento do espaço das pistas

de rolagem, pois da forma como está escrito o código, os veículos são obrigados a seguir

suas rotas um atrás do outro. Muitas vezes existe espaço nas pistas laterais para

aproximação imediata do sinal e o veículo deixa de fazer isso porque possui uma rota

fixa.

Outra melhoria para o programa poderia ser a introdução de uma interface mais

amigável para a inserção do número de veículos requisitantes de cada pista de entrada (

ou rotas ), bem como uma interface para a montagem do mapa de simulação e uma

interface de controle que permita parar a simulação ou inserir veículos em determinadas

pistas de entrada. Também uma interface que permita a programação dos sinais de forma

mais intuitiva, quando se deseja simular o tráfego com tempos fixos de sinal

68

Bibliografia

[1] MARCELO LACORTT, ROSANA M. L. KRIPKA, Modelos Matemáticos para a

Otimização do Tráfego Urbano Semaforizado, Instituto de Ciências Exatas e

Geociências 99001-970, Passo Fundo , Universidade de Passo Fundo.

[2] CRISTIANE B. DUTRA, SERGIO H. DEMARCHI, Métodos de Coordenação

Semafórica: Estado da arte versus estado da prática, M.C dissertação,

Universidade de São Paulo. Bookman, 2004.

[3] CRISTIANE B. DUTRA, SERGIO H. DEMARCHI, Implementação em planilha

eletrônica de um método para maximização da banda verde em vias semaforizadas,

XVIII congresso em pesquisa e ensino de transportes.

[4] CRISTIANE B. DUTRA, SERGIO H. DEMARCHI, Uma proposta de análise de

sistemas de coordenação semafórica, XIV encontro tecnológico de engenharia civil

e arquitetura.

[5] ARTHUR BESSO, estudo comparativo dos métodos e abordagens de coordenação

semafórica, projeto de graduação em engenharia de produção, universidade fede-

ral do rio de janeiro, abril de 2013

[6] CIHAN KARAKUZU, OSMAN DEMIRCI , fuzzy logic based smart traffic light

simulator design and hardware implementation, Engineering faculty, Kocaeli

university, Turkey

[7] W.WEN , a dynamic and automatic traffic light control expert system for solving the

road congestion problem, Department of information management, Lunghwa

University, Taiwan

[8] SYED MASIUR RAHMAN, NEDAL T. RATROUT, review of the fuzzy logic

based approach in traffic signal control: prospects in Saudi Arabia, Department of

Civil Engineering, King Fahd University of Petroleum & Minerals, Saudi Arabia

[9] YI SHENG HUANG & TA-HSIANG CHUNG, modeling and analysis of urban

traffic lights control systems using timed CP-Nets, departments of electrical and

electronic engineering, school of defense science, chung cheng institute of technology

[10] LEONARDO D. TAVARES, Um simulador de tráfego urbano baseado em

autômatos celulares. M Sc. dissertação, Universidade Federal de Minas Gerais, Março

de 2010

[11] Herman R., The Mathematical Theory Of Traffic Flow , Institute of Traffic

Engineers , 1960

[12] Herman R., E. Montroll R. R. Rothery , Traffic Dynamics: Analysis of Stability of

car following, Operation Research, Vol 7, 1959

69

[13] O’Flaherty, Traffic Engineering and Transport Planning , Butterworth Heineman ,

2003

[14] Wohl Martin, Traffic System Analysis for Engineers and Planners, McGraw-Hill

inc, 1967

[15] Pressman, Roger S., Engenharia de Software, Makron Books, 2010

[16] DAIHENG NI, Ph. D, “Pipes and forbes models”, people.umass.edu/ndh/TFT/Ch

17%20Pipes.pdf , ( acessado em 22 de janeiro de 2014 )

70

71

72