Projetando um Modelo de Tráfego¶

Gerenciamento de um Modelo de Tráfego¶

Uma das tarefas que mais consomem tempo na modelagem de transportes é gerenciar variantes da rede de transporte. Diferentes opções de infraestrutura da rede viária e sistemas de controle de tráfego são testadas em conjunto com diferentes opções de demanda, como uso do solo e rotas e horários de transporte público. Há uma explosão combinatória no número de variantes do modelo de transporte e, consequentemente, um problema de gestão para manter a consistência entre elas.

O problema de gerenciamento se agrava quando a tarefa de modelagem se concentra em uma subárea de um modelo de transportes mais amplo e uma área cordonada deve ser estudada. Retornar ao modelo de área ampla, e a todas as variantes desse modelo de área ampla, as alterações feitas na subárea como resultado desse exercício de modelagem é uma tarefa demorada e potencialmente sujeita a erros.

Muitas tarefas de modelagem também são realizadas com diferentes pacotes de software usados em diferentes níveis de modelagem, com um pacote de alocação macroscópica usado em um modelo de área ampla, um pacote de alocação de transporte público para modelar o uso de trem e ônibus, e um pacote de microssimulação para modelar áreas menores ou usado quando é necessário simular as interações detalhadas entre veículos para reproduzir com precisão as condições na via. O intercâmbio de dados entre esses diferentes sistemas de modelagem complica ainda mais o problema de gestão do modelo.

Por fim, há muitas variáveis que descrevem como um modelo de transporte funciona. Elas variam desde algoritmos de car following até o método de escolha de rota e são críticas na forma como um modelo é calibrado. Alterações nessas variáveis para calibrar um modelo devem ser replicadas em todos os cenários testados pelo modelo e, novamente, com múltiplos modelos, usando múltiplos pacotes de software, alcançar consistência requer uma gestão robusta.

Entradas do Modelo de Tráfego¶

Há dois componentes de entrada obrigatórios de um modelo de tráfego. Eles são a topologia da rede base e a demanda de viagens:

A rede base é a topologia da rede de tráfego e os vários modos de transporte; o núcleo do projeto de modelagem. Ela contém as seções e nós da rede viária base e os objetos fundamentais, como Tipos de veículos, Motivos de viagem e Classes de Usuário que descrevem os veículos na rede.
A Demanda de Tráfego objeto descreve as viagens realizadas pelos veículos que trafegam na rede de tráfego. Este é um conjunto de Estados de Tráfego que movem veículos na rede para corresponder aos fluxos observados ou Matrizes OD que fornecem o número de viagens entre centroides discriminado por hora do dia e User Class. A Configuração de centroide é necessária para a demanda baseada em matriz OD, e o documento Aimsun pode conter várias Configurações de Centroides para gerenciar diferentes demandas OD. Por exemplo, uma opção de desenvolvimento a ser testada pelo modelo pode incluir novas zonas residenciais e industriais; estas, e a demanda de tráfego que elas geram, são representadas por centroides que são necessários somente quando esta opção é testada e a Demanda de Tráfego correspondente é incluída no cenário.

Os componentes de entrada opcionais que adicionam recursos importantes à rede base são:

Planos de Controle Mestres especificar os parâmetros de controle aplicados a interseções semaforizadas. Um Plano Mestre de Controle é uma coleção de múltiplos planos de controle para diferentes áreas do modelo e diferentes períodos do dia, e um projeto pode conter vários Planos Mestres de Controle. Um cenário, ou um experimento em um cenário, terá um Plano Mestre de Controle atribuído a ele para fornecer as opções de controle semafórico a serem incluídas no modelo. Estendendo o exemplo das diferentes Configurações de Geometria acima, um cenário com diferentes opções de melhorias em interseções agora pode ser testado em diferentes experimentos usando um Plano de Controle diferente em cada experimento, variando de planos de tempo fixo a planos de prioridade ao transporte público e de controle semafórico ativo.
a Plano de Transporte Público é uma coleção de rotas e horários consistentes, e um projeto pode conter vários Transit Plans. Um Plan é então selecionado para ser incluído em um cenário para incluir essa combinação de serviços de transporte público no modelo.

Os componentes opcionais que criam variações da topologia da rede ou dos parâmetros do modelo são:

um conjunto de Substituições de Atributos usados para alterar atributos do modelo e permitir que mudanças sejam feitas sem alterar o layout da rede. Isso permite que o cenário modifique parâmetros como limites de velocidade, restrições de faixa e tempos de reação nas seções; capacidade e comportamento dos ônibus em paradas de transporte público; e velocidades de conversão e comportamento de yellow box nos nós. Qualquer atributo de qualquer um dos objetos da rede pode ser sobrescrito, mas a lista de objetos permanece a mesma.
Configurações de geometria contêm as diferenças geométricas entre a rede base e a rede a ser testada em um cenário e ampliam o que pode ser ajustado usando Attribute Overrides ao alterar a lista de objetos. Por exemplo, uma rede base pode modelar uma pequena cidade; o projeto também pode incluir um conjunto de Geometry Configurations baseado nessa rede; uma delas pode adicionar uma via de contorno a esse modelo, outras podem incluir melhorias de entroncamentos em vias existentes, um entroncamento por configuração. Cenários podem então ser criados para modelar a cidade, a cidade com diferentes conjuntos de melhorias de entroncamentos, ou a cidade com uma via de contorno. Em cada caso, a rede principal permanece a mesma; apenas as diferenças ou, com múltiplas Geometry Configurations, combinações de diferenças, são aplicadas em cada cenário.

Modelagem de Sub-redes¶

O Aimsun Next possui dois mecanismos para simular subáreas em uma rede de tráfego. Uma subárea pode ser uma área pequena onde a microssimulação é usada em um modelo híbrido meso-micro para modelar as interações entre veículos enquanto o restante da simulação é executado com simulação mesoscópica, ou a mesossimulação é usada em um modelo híbrido macro–meso, ou uma subárea pode ser isolada de uma rede de tráfego maior e cenários gerados para serem executados apenas dentro dessa subárea.

A Área de simulação híbrida é criada definindo um polígono, ou selecionando seções viárias e marcando-as como uma área de simulação. Quais áreas devem então ser consideradas em uma simulação é selecionado no experimento híbrido.

Uma subárea cordonada é criada convertendo uma forma poligonal em uma subárea. Consulte o Edição de sub-rede seção. A subárea deve ter sua própria Centroid Configuration e Demand Plans, mas pode compartilhar Transit Plans, Master Control Plans, Geometry Configurations e Attribute Overrides com a rede principal. Cenários gerados dentro da subárea são executados usando apenas a rede de tráfego dentro dessa área e, portanto, executam muito mais rapidamente que o modelo maior.

A demanda de tráfego em subáreas pode ser criada automaticamente usando um Travessia estática ou travessia dinâmica método que gera uma nova configuração de centroides para a subárea e um conjunto de matrizes OD calculadas usando um experimento de alocação estática ou uma replicação de uma simulação dinâmica com base na demanda em toda a área do modelo