Suporte a Projetos Multi Network¶

Construir um modelo com Aimsun Next pode ser uma tarefa significativa, pois os modelos frequentemente cobrem áreas extensas com muitas seções viárias, interseções, semáforos, paradas de transporte coletivo, linhas de transporte coletivo e anotações. Um modelo grande também exige um esquema de zonas de demanda frequentemente complexo e sua configuração e conexões de centroides correspondentes. Construir o modelo em um prazo razoável frequentemente exigirá a contribuição de vários modeladores, e suas contribuições individuais devem ser gerenciadas e mescladas entre si de forma eficiente.

Da mesma forma, uma vez que um modelo é construído e calibrado, ele provavelmente será usado para múltiplos conjuntos de testes de opções, nos quais são realizados projetos de novos traçados viários, alterações nos controles semafóricos, alterações na demanda na rede ou testes para avaliar estratégias de gestão de tráfego. Em cada um desses casos, será acordado um desenvolvimento comprometido, e ele precisará ser mesclado ao modelo-base para ser incluído em testes de opções subsequentes. Frequentemente, um modelo será usado para realizar mais de um conjunto de testes ao mesmo tempo, exigindo uma cópia de trabalho do modelo para cada conjunto de testes, mas com a capacidade de, ao final, integrar o projeto final ao modelo-base.

Gerenciar os processos de fluxo de trabalho quando mais de um modelador precisa acessar o modelo enquanto ele está sendo construído, ou quando mais de uma tarefa de avaliação está em andamento usando um modelo concluído, é uma tarefa complexa. Essa tarefa é facilitada pelo uso de Revisões no Aimsun Next, que permitem a um gerente de projeto de modelagem empregar múltiplos modeladores em um único projeto, ou usar simultaneamente um único modelo base em múltiplos projetos, e gerenciar eficientemente a tarefa de mesclar alterações em um modelo base central.

Revisões¶

A Revisão é um vínculo para um modelo base que armazena apenas os elementos que foram alterados. Inicialmente, uma revisão é vinculada a um modelo existente e não contém objetos próprios. Quando um modelador trabalha em uma revisão, os objetos editados na revisão são marcados como alterados, armazenados no arquivo de modelo da revisão e usados em preferência àqueles que permanecem inalterados e estão armazenados no arquivo do modelo base. Esse processo é invisível para o modelador, exceto pela condição de que o arquivo do modelo base deve estar disponível para o computador do modelador pela rede. Se o documento base não estiver disponível, não será possível editar a revisão até que o vínculo seja refeito, seja restaurando a conexão de rede ou vinculando novamente a um documento base realocado.

Nos momentos apropriados, o gerente do projeto pode optar por integrar as alterações do modelo de revisão ao modelo base; nesse ponto, as alterações dessa revisão estarão disponíveis em todas as outras revisões vinculadas ao modelo base.

Criação e Consolidação de Revisões¶

Nova Revisão¶

Para criar uma revisão baseada em uma rede de tráfego atual (o documento base), selecione Projeto/Nova Revisão.... A seguinte caixa de diálogo será exibida:

onde,

• Documento base: Nome da rede base
• Nome da Revisão: O sufixo para o nome da rede de revisão
• Novo ID Inicial: O ID inicial do objeto para a nova revisão. Por padrão, o Aimsun Next calculará o valor com base nos objetos na rede base, mas é fortemente recomendável aumentá-lo para que futuras modificações no documento base não dupliquem IDs de objetos no documento revisado. Por exemplo, na figura acima, 300000 deve ser um valor razoável.
• Documento de Revisão: O nome do arquivo de revisão. Por padrão, este é o nome do arquivo base e o sufixo.

Clique na OK botão, e a rede base é fechada automaticamente e a nova revisão é aberta. Este documento de revisão pode ser editado da mesma forma que qualquer outro documento do Aimsun, com a condição de que o documento base esteja disponível para ele pela rede.

O número de ID deve ser gerenciado entre múltiplas revisões para garantir que os IDs de objetos não sejam duplicados em revisões diferentes. No exemplo acima, definir um ponto inicial para revisões diferentes em 300000, 400000 provavelmente é seguro, mas definir os pontos iniciais em 301000, 302000 permitiria apenas 1000 novos objetos por revisão antes que ocorressem conflitos, o que provavelmente não é seguro.

Consolidando revisões¶

Primeiro, recomenda-se que, enquanto o trabalho estiver sendo realizado em revisões, o modelo base seja mantido inalterado até que as revisões sejam consolidadas.

Os objetos adicionados, alterados ou excluídos em uma Revisão podem ser revisados a partir do menu de contexto Project Informações da Revisão

Quando exigido pelo fluxo de trabalho, é possível transformar uma revisão em uma rede completa unindo as informações da base e da revisão no mesmo arquivo. Isso pode ser feito a partir de Projeto/Consolidar Revisão em que:

• Consolidar Revisão na Base: Copia as revisões para a base, o que, por sua vez, afetará quaisquer outras revisões baseadas neste modelo de base. Isso também atualiza os IDs dos objetos na revisão de base.
• Desanexar Revisão da Base: Copia o modelo base para o modelo revisado e mantém a base e a revisão como dois documentos independentes.
• Reverter Seleção para a Base: Considerando o documento base, ele reverte quaisquer alterações dos objetos selecionados que foram adicionados ou alterados (não os objetos afetados por uma ação de exclusão) nesta revisão.

O Consolidar na Base opção seria usada para incluir no modelo base as alterações feitas em uma revisão, a fim de continuar o desenvolvimento da base durante a construção do modelo, ou para incluir alterações feitas em um teste de opção e disponibilizá-las para todas as outras revisões a partir da base. O documento base será então atualizado com todas as ações feitas nessa revisão.

Um documento de backup da base antiga é salvo em: PROJECT_FOLDER\Model\Resources\Backup\old_base_datetime.ang

e um backup de qualquer documento de revisão é salvo em: PROJECT_FOLDER\Revisions\RevisionName\Model\Resources\Backup\RevisionName_datetime.ang

O Desvincular revisão da base opção seria usada para tornar uma revisão independente do modelo base, seja para ser trabalhada no futuro de forma isolada, seja para criar uma cópia de arquivo, por exemplo ao final de um teste de opção.

O Reverter Seleção para a Base opção seria usada para reverter as alterações desejadas de uma revisão caso haja conflitos entre revisões. Um objeto que foi salvo em uma revisão pode ser revertido de volta ao mesmo estado em que está na base, e as alterações da revisão descartadas. Selecione o objeto, ou vários objetos na vista 2D, e selecione o Reverter Seleção para a Base opção no Projeto menu. A revisão será salva e fechada; então, ao reabri-la, esses objetos terão sido removidos da revisão, serão lidos a partir do documento Aimsun base e, portanto, permanecerão inalterados na revisão. Como esta é uma opção experimental, certifique-se de manter um backup do documento antes de executar qualquer ação.

Gerenciamento de revisões¶

Uma rede revisada contém objetos que substituem aqueles da rede base e apenas esses objetos modificados. Isso exige que a rede base esteja presente ao carregar uma rede revisada e, se ela não puder ser encontrada, sua localização será solicitada.

Como os objetos que foram alterados na rede de revisão sobrescrevem os objetos da rede base, quaisquer alterações subsequentes na rede base para esses objetos não serão incluídas na rede revisada. Por exemplo:

1. Uma Rede Base é aberta e uma Revisão é criada a partir dela
2. A Rede Revisada é editada. No exemplo aqui, uma seção de uma via de duas faixas é alargada para uma via de três faixas
3. A Rede Base é modificada; a faixa próxima ao meio-fio da via de duas faixas é restrita apenas a Veículos de Transporte Público
4. A Rede Revisada é reaberta. A seção revisada não foi modificada, mas as seções na Revisão que permanecem inalteradas em relação à Rede Base recebem a modificação.

Gerenciar revisões torna-se mais complexo quando os objetos de um modelo estão interligados. Por exemplo:

• A plano de controle contém os grupos semafóricos e os tempos semafóricos para um conjunto de cruzamentos. Se dois modeladores editarem o mesmo plano de controle para diferentes cruzamentos, cada um em uma revisão separada, então, quando as revisões forem consolidadas na base, as alterações da primeira revisão a ser consolidada serão incluídas no modelo base para os grupos semafóricos como parte do cruzamento e para os tempos semafóricos como parte do plano de controle. Posteriormente, quando a segunda revisão for reaberta, como o plano de controle está marcado como alterado na revisão, as atualizações dos tempos na base não estarão visíveis na revisão. No entanto, as atualizações dos grupos semafóricos nos cruzamentos alterados agora incluídos na base estarão visíveis, pois esses cruzamentos não terão sido alterados na revisão.

• Considere um linha de transporte público que cruza duas áreas geográficas sendo editadas em revisões separadas e onde algumas das seções ou movimentos de conversão da rota foram editados em uma revisão. Quando essa revisão é consolidada na base e a segunda revisão é reaberta, as atualizações nas seções e nos movimentos de conversão passam a ficar visíveis nessa revisão, mas, como a linha de transporte coletivo foi atualizada em ambas as revisões e já está marcada como alterada nessa segunda revisão, as alterações feitas na linha na primeira revisão não ficarão visíveis na segunda.

• Se modeladores usando revisões separadas adicionarem, editarem ou removerem ações ou estratégias de gerenciamento de tráfego e essas ações são atribuídas ao mesmo cenário, então, quando um conjunto de revisões é consolidado na base, o mesmo cenário na outra revisão não é atualizado. Isso ocorre porque, na segunda revisão, o cenário está marcado como alterado e, consequentemente, não é atualizado a partir da base. O fluxo de trabalho exemplo desenvolve este ponto.

Em casos como estes, uma solução alternativa é usar um script para dividir um objeto antes de criar as revisões e outro script para recombiná-lo quando as revisões tiverem sido consolidadas no modelo base. Nas figuras abaixo, assume-se que, em cada revisão, um modelador recebeu uma área geográfica para trabalhar separada das áreas em que se trabalha em outras revisões.

Neste exemplo, um modelo base é marcado com duas áreas distintas com uma pequena sobreposição (2 nós por seção) entre elas. No caso simples, duas revisões são criadas e dois modeladores as editam independentemente. A Revisão A é primeiro consolidada na base e, nesse ponto, as alterações feitas em A passam a estar visíveis na revisão B. A Revisão B é então consolidada na base para atualizá-la com as alterações de ambas as revisões. Quaisquer alterações que acessem objetos editados nas revisões A e B são feitas na base depois que ambas as revisões tiverem sido consolidadas.

No caso mais complexo, ambos os modeladores estarão trabalhando em (por exemplo) planos de controle e, nesse caso, os tempos semafóricos inseridos na revisão A atualizarão a base, mas, como o mesmo plano também foi atualizado na revisão B, essas alterações não serão consolidadas. Nesse caso, o plano de controle é dividido em dois usando as mesmas áreas que foram atribuídas a cada revisão por meio de um script e, depois de consolidar ambas as revisões na base, um script é usado para mesclar os dois planos de controle de volta em um único plano.

Um exemplo desse tipo de script está disponível, apropriado para planos de controle

As principais ações do gerente do modelo, responsável por controlar as revisões, são primeiro identificar áreas funcional e/ou geograficamente separadas e delegá-las aos modeladores que trabalham em revisões individuais. A segunda ação é identificar aqueles objetos que serão modificados indiretamente e adiar sua atualização até que todas as revisões tenham sido consolidadas, ou usar um script para dividi-los antes de alocar as revisões e outro para mesclá-los depois que as revisões tiverem sido consolidadas.

Fluxo de trabalho sugerido¶

A chave para editar com eficiência modelos grandes, com vários modeladores realizando uma variedade de tarefas, é planejar o fluxo de trabalho para aproveitar ao máximo o recurso de revisões. Os exemplos apresentados aqui abrangem possíveis padrões de fluxo de trabalho para:

• Construindo um modelo.
• Desenvolvimento de áreas dentro de um modelo.
• Usando um modelo para testes de múltiplas opções.

Nestes exemplos, (LM) é o Lead Modeler ou Project Manager, (MA), (MB), (MC)... são modeladores trabalhando em revisões.

Construção de um modelo¶

Neste exemplo, um novo modelo será criado a partir de uma importação do OpenStreetMap e com transporte público, semáforos etc. importados de fontes de dados externas.

1. Edite o modelo de template para definir a infraestrutura do modelo, como tipos de via, tipos de veículo etc. (LM)
2. Importe a rede base do OSM. (LM)
3. Defina as áreas da rede em que cada revisão trabalhará desenhando polígonos. Idealmente, deve haver uma pequena sobreposição nas áreas, com articulação entre os modeladores que trabalham na área sobreposta. (LM)
4. Crie um conjunto de revisões e aloque modeladores a cada área para ajustar a rede base. (MA,MB...).
5. Consolidar todas as revisões – esta pode ser uma tarefa repetida à medida que o trabalho avança. (LM)
6. Crie um novo conjunto de revisões e aloque tarefas de modelagem por função a modeladores individuais. (LM)
7. Em uma revisão, edite os controles semafóricos. (MA)
8. Em outra revisão, edite o transporte coletivo. (MB)
9. Em outra revisão, edite a demanda de tráfego. (MC)
10. etc.
11. Consolidar todas as revisões. (LM)
12. Prossiga para calibrar e validar o modelo. (LM)

Observe que, na etapa 4, é essencial que os modeladores individuais não editem os objetos de modelo comuns, pois isso terá efeito sobre todas as revisões durante a mesclagem. Em geral, os objetos de modelo podem receber acréscimos durante essa etapa de edição, mas seria necessária uma justificativa sólida para ajustá-los em relação aos padrões predefinidos usados por essa empresa ou cliente.

Desenvolvendo Áreas dentro de um Modelo¶

Neste exemplo, o modelo deve ser refinado adicionando semáforos (ou transporte público, ou dispositivos ITS ...) e, para agilizar a entrega da atualização, vários modeladores trabalharão na mesma função, mas em diferentes áreas do modelo. O ponto de partida é um modelo existente

1. Defina as áreas da rede com as quais cada revisão trabalhará desenhando polígonos. Idealmente, deve haver uma pequena sobreposição nas áreas, com articulação entre os modeladores que trabalham na área sobreposta. (LM)
2. Use um script para criar subdivisões dos objetos que serão editados por todas as revisões — ou seja, o plano de controle que é comum a todas as revisões. (LM)
3. Crie um conjunto de revisões e aloque modeladores para cada área. (MA,MB...)
4. Consolidar as revisões (LM)
5. Use um script para recombinar os objetos previamente divididos (LM)

No caso de planos de controle ou transporte público, pode haver muitos objetos compartilhados (isto é, rotas de transporte público) ou um pequeno número de objetos complexos (isto é, planos de controle semafórico), e a opção de scripting é a melhor a adotar. Em outros casos, os objetos compartilhados podem ser simples de editar e poucos em número e, nesse caso, seria mais fácil adiar essa etapa até depois que as revisões tenham sido consolidadas.

Usando um Modelo para Testes de Múltiplas Opções¶

Neste exemplo, um modelo-base calibrado deve ser usado para dois conjuntos individuais de testes de opções de melhoria da rede viária em áreas que não se sobrepõem. Restrições de prazo significam que ambos devem ser realizados ao mesmo tempo e, ao final, a opção escolhida em cada caso deve estar disponível no modelo-base como um "empreendimento confirmado" e disponível para inclusão em exercícios de modelagem subsequentes.

Este exemplo faz uso extensivo de Configurações de geometria.

1. Crie duas revisões e aloque um modelador para cada uma. (LM)
2. Cada modelador faz as alterações necessárias no traçado viário usando configurações de geometria para gerenciar os múltiplos traçados possíveis. (MA,MB)
3. Os modelos passam por avaliação e uma alteração na rede é decidida para cada teste de opção.
4. Depois que as cópias de arquivo foram feitas, o modelador exclui todos os testes descartados, deixando uma única configuração de geometria que representa o desenvolvimento confirmado. (MA ou MB)
5. A revisão é consolidada com o modelo base, que agora tem a nova configuração de geometria incluída nele, a qual pode ser selecionada em cenários subsequentes. (LM)

Gestão de Tráfego¶

O uso de ações de Traffic Management fornece mais um exemplo de gerenciamento de revisões. Nesse caso, revisões derivadas do modelo base são criadas e atribuídas a diferentes modeladores; ambos os modeladores criam um conjunto de ações de tráfego e as adicionam a um cenário, o mesmo cenário em ambas as revisões.

Depois de consolidar a revisão A na base, a revisão B é reaberta. Nesta revisão, as ações criadas na revisão A agora estão visíveis no modelo base para a revisão B, mas não estão atribuídas ao cenário, pois esse objeto também foi alterado na revisão B. Se B for então consolidada na base, as ações atribuídas ao cenário em B serão atribuídas na base, mas aquelas de A, embora existam na base recém-consolidada, não serão atribuídas ao cenário

A solução alternativa é identificar o cenário como um objeto alterado em ambos os conjuntos de revisões e, nesse caso, abster-se de adicionar as ações ao cenário até que o conjunto completo de ações das revisões seja consolidado, momento em que elas podem ser vinculadas ao cenário.