Suporte para Projetos de Múltiplas Redes

Construir um modelo com Aimsun Next pode ser uma tarefa significativa, pois os modelos frequentemente cobrem grandes áreas com muitos trechos de via, interseções, semáforos, paradas de transporte público, linhas de transporte público e anotações. Um grande modelo também requer um esquema de zona de demanda muitas vezes complexo e sua correspondente configuração de centróides e conexões. Construir o modelo em um prazo razoável frequentemente exigirá a contribuição de vários modeladores, e as contribuições individuais devem ser gerenciadas e fundidas de maneira eficiente.

Da mesma forma, uma vez que um modelo é construído e calibrado, provavelmente será utilizado para múltiplos conjuntos de testes de opções, onde são realizados projetos para novos layouts de vias, mudanças nos controles semafóricos, alterações na demanda da rede ou testes para avaliar estratégias de gerenciamento de tráfego. Em cada um desses casos, um desenvolvimento comprometido será acordado e precisará ser integrado ao modelo base para ser incluído em testes de opções subsequentes. Frequentemente, um modelo será utilizado 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 no final integrar o design final ao modelo base.

Gerenciar os processos de trabalho quando mais de um modelador precisa de acesso ao modelo à medida que é construído ou quando mais de uma tarefa de avaliação está em andamento usando um modelo completo é 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 vários projetos e gerenciar de maneira eficiente a tarefa de fundir mudanças em um modelo base principal.

Revisões

Uma Revisão é um link para um modelo base que armazena apenas aqueles elementos que foram alterados. Inicialmente, uma revisão é vinculada a um modelo existente e não contém objetos por si só. Quando um modelador trabalha em uma revisão, os objetos que são editados na revisão são marcados como alterados, armazenados no arquivo do modelo de revisão e são usados em preferência àqueles que permanecem inalterados e 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 na rede. Se o documento base não estiver disponível, não será possível editar a revisão até que o link seja refeito, seja restaurando a conexão da rede ou relinkando a um documento base realocado.

Em momentos apropriados, o gerente de projeto pode optar por integrar as mudanças do modelo de revisão ao modelo base, momento em que as mudanças daquela revisão estarão disponíveis em todas as outras revisões vinculadas ao modelo base.

Criar e Consolidar 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.... O seguinte diálogo será exibido:

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 do objeto inicial para a nova revisão. Por padrão, o Aimsun Next calculará o valor com base nos objetos na rede base, mas é fortemente aconselhável aumentá-lo para que modificações futuras 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, esse é o nome do arquivo base e o sufixo.

Clique no botão OK e a rede base será fechada automaticamente e a nova revisão será 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 deve estar disponível na rede.

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

Consolidando Revisões

Primeiro, é recomendado que enquanto o trabalho está sendo realizado em revisões, o modelo base permaneça inalterado até que as revisões sejam consolidadas.

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

Quando necessário 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 em Projeto/Consolidar Revisão onde:

• Consolidar Revisão na Base: Copia as revisões para a base, o que por sua vez afetará qualquer outra revisão baseada neste modelo base. Isso também atualiza os IDs dos objetos na revisão base.
• Desvincular Revisão da Base: Copia a 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, reverte quaisquer mudanças dos objetos selecionados que foram adicionados ou alterados (não os objetos afetados por uma ação de exclusão) nesta revisão.

A opção Consolidar na Base seria usada para incluir as alterações feitas em uma revisão ao modelo base para continuar o desenvolvimento da base durante a construção do modelo ou para incluir mudanças feitas em um teste de opção e torná-las disponíveis 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 antiga base é salvo em: Pasta_do_PROJETOModelResourcesBackupold_base_datetime.ang

e um backup de qualquer documento de revisão é salvo em: Pasta_do_PROJETORevisõesNomeDaRevisãoModelResourcesBackupNomeDaRevisão_datetime.ang

A opção Desvincular Revisão da Base seria usada para libertar uma revisão do modelo base, seja para ser trabalhada futuramente em isolamento ou para criar uma cópia de arquivo, por exemplo, ao final de um teste de opção.

A opção Reverter Seleção para a Base seria usada para reverter as alterações desejadas de uma revisão no caso de haver conflitos entre revisões. Um objeto que foi salvo em uma revisão pode ser revertido de volta ao mesmo estado em que se encontra na base e as mudanças da revisão descartadas. Selecione o objeto, ou múltiplos objetos na visualização 2D e selecione a opção Reverter Seleção para a Base no menu Projeto. A revisão será salva e fechada, então, ao reabri-la, aqueles objetos terão sido removidos da revisão, serão lidos a partir do documento base do Aimsun e, portanto, permanecerão inalterados na revisão. Como se trata de uma opção experimental, certifique-se de que você mantém um backup do documento antes de realizar qualquer ação.

Gerenciando Revisões

Uma rede revisada contém objetos que sobrescrevem os da rede base e apenas aqueles objetos modificados. Isso requer que a rede base esteja presente ao carregar uma rede revisada e, se 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 mudanças 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, um trecho de uma via de duas faixas é alargado para uma via de três faixas
3. A Rede Base é modificada, a faixa do lado mais próximo da via de duas faixas é restrita apenas a Veículos de Transporte Público
4. A Rede Revisada é reaberta. O trecho revisado não foi modificado, mas os trechos na Revisão que permanecem inalterados da Rede Base recebem a modificação.

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

• Um plano de controle contém os grupos semafóricos e os tempos dos semáforos para um conjunto de interseções. Se dois modeladores editarem o mesmo plano de controle para diferentes interseções, 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 da interseção e para os tempos semafóricos como parte do plano de controle. Subsequentemente, 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 serão visíveis na revisão. No entanto, as atualizações nos grupos semafóricos nas interseções alteradas que agora estão incluídas na base serão visíveis, pois essas interseções não foram alteradas na revisão.

• Considere uma linha de transporte público que cruza duas áreas geográficas sendo editada em revisões separadas e onde alguns dos trechos ou curvas na rota foram editados em uma revisão. Quando essa revisão é consolidada na base e a segunda revisão é reaberta, as atualizações dos trechos e curvas agora são visíveis nessa revisão, mas como a linha de transporte público foi atualizada em ambas as revisões e já está marcada como alterada nesta segunda revisão, as mudanças feitas na linha na primeira revisão não serã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 forem atribuídas ao mesmo cenário, então, quando um conjunto de revisões for consolidado na base, o mesmo cenário na outra revisão não será 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 expande esse ponto.

Em casos como esses, 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 forem consolidadas no modelo base. Nas figuras abaixo, assume-se que em cada revisão, um modelador foi alocado a uma área geográfica para trabalhar separadamente das áreas sendo trabalhadas 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 de forma independente. A Revisão A é primeiro consolidada na base e, neste ponto, as mudanças feitas em A agora são visíveis na revisão B. A Revisão B é então consolidada na base para atualizá-la com as mudanças de ambas as revisões. Quaisquer mudanças que acessem objetos editados em ambas as revisões A e B são feitas na base após ambas as revisões terem sido consolidadas.

No caso mais complexo, ambos os modeladores estarão trabalhando em (por exemplo) planos de controle e, neste 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 mudanças não serão consolidadas. Neste caso, o plano de controle é dividido em dois usando as mesmas áreas que foram alocadas a cada revisão usando um script e, após 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 de tal script está disponível, apropriado para planos de controle

As ações-chave para o gerente de modelo, responsável pelo controle das revisões, são primeiro identificar áreas funcional e/ou geograficamente separadas e delegar estas aos modeladores trabalhando em revisões individuais. A segunda ação é identificar aqueles objetos que serão indiretamente modificados e ou atrasar sua atualização até que todas as revisões tenham sido consolidadas, ou usar um script para dividi-los antes de alocar revisões e outro para mesclá-los após as revisões terem sido consolidadas.

Fluxo de Trabalho Sugerido

A chave para editar eficientemente grandes modelos com múltiplos modeladores realizando uma variedade de tarefas é planejar o fluxo de trabalho para fazer o melhor uso das capacidades de revisões. Os exemplos apresentados aqui cobrem padrões possíveis de fluxo de trabalho para:

• Construir um modelo.
• Desenvolver áreas dentro de um modelo.
• Usar um modelo para múltiplos testes de opções.

Nestes exemplos, (LM) é o Modelador Líder ou Gerente de Projeto, (MA), (MB), (MC)... são modeladores trabalhando em revisões.

Construindo um Modelo

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

1. Edite o modelo base para definir a infraestrutura do modelo, como tipos de via, tipos de veículos, 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 ligaçã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. Consolide todas as revisões – isso 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 público. (MB)
9. Em outra revisão, edite a demanda de tráfego. (MC)
10. etc.
11. Consolide todas as revisões. (LM)
12. Prossiga para calibrar e validar o modelo. (LM)

Note que na etapa 4, é essencial que modeladores individuais não editem os objetos comuns do template, pois isso afetará todas as revisões durante a fusão. Em geral, os objetos do template podem ser adicionados durante esta etapa de edição, mas seria necessária uma forte justificativa para ajustá-los a partir dos padrões padrão usados por essa empresa ou cliente.

Desenvolvendo Áreas Dentro de um Modelo

Neste exemplo, o modelo será refinado adicionando semáforos (ou transporte público, ou dispositivos de ITS...) e, para acelerar a entrega da atualização, múltiplos 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 em que cada revisão trabalhará desenhando polígonos. Idealmente, deve haver uma pequena sobreposição nas áreas com ligaçã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 a cada área. (MA,MB...)
4. Consolide as revisões (LM)
5. Use um script para re-mergear os objetos previamente divididos (LM)

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

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

Neste exemplo, um modelo base calibrado será usado para dois conjuntos individuais de testes de opções de melhorias na rede de vias em áreas que não se sobrepõem. As restrições de tempo significam que ambos devem ser realizados ao mesmo tempo e, no final, a opção escolhida em cada caso deve estar disponível no modelo base como um "desenvolvimento comprometido" e disponível para inclusão em subsquentes exercícios de modelagem.

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

1. Crie duas revisões e aloque um modelador a cada uma. (LM)
2. Cada modelador faz as alterações necessárias no layout de via usando configurações de geometria para gerenciar os múltiplos layouts possíveis. (MA,MB)
3. Os modelos prosseguem para avaliação e uma mudança na rede é decidida para cada teste de opção.
4. Após cópias de arquivo terem sido feitas, o modelador exclui todos os testes descartados, deixando uma única configuração de geometria representando o desenvolvimento comprometido. (MA ou MB)
5. A revisão é consolidada com o modelo base que agora tem a nova configuração de geometria incluída, a qual pode ser selecionada em cenários subsequentes. (LM)

Gerenciamento de Tráfego

Usar ações de Gerenciamento de Tráfego fornece um outro exemplo de gerenciamento de revisões. Neste 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.

Após consolidar a revisão A na base, a revisão B é reaberta. Nesta revisão, as ações criadas na revisão A agora sã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 são atribuídas na base, mas aquelas de A, enquanto existem na base recém consolidada, não sã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, evitar adicionar as ações ao cenário até que todo o conjunto de ações das revisões seja consolidado, momento em que elas podem ser vinculadas ao cenário.