Introdução

O transporte é a espinha dorsal de nossa civilização e o motivo para nossa prosperidade econômica. Departamentos de Transporte em todo o mundo estão lutando com tecnologias e infraestruturas implementadas décadas atrás, e precisam modernizar uma mistura de recursos de tecnologia da informação e recursos existentes para atender as necessidades dos cidadãos.

Departamentos de transporte estão se concentrando em implementar tecnologias de comunicações, controle e informações de computador para melhorar o desempenho de sistemas de rodovias, trânsito (ferroviário e ônibus) e de transporte aéreo e marítimo. Consequentemente, sistemas e infraestruturas de transporte estão sendo monitorados em níveis crescentes, o que resulta em enormes conjuntos de dados capturados. Esses dados podem incluir informações como localização geográfica, velocidade, contagem e padrões de comportamento, que são combinadas para obter estimativas das condições de tráfego. Há vários desafios únicos envolvidos, como:

• Grandes volumes de dados de origens díspares devem ser coletados em tempo hábil para suportar a representação de tráfego em tempo quase real.
• Diversas estratégias de limpeza são necessárias para gerenciar as características de erro dos diferentes fluxos de dados, filtrando os dados ruins e lidando com diferenças nos dados.
• Diferentes tipos de dados devem ser combinados para representar com precisão as informações de tráfego.
• Dados devem ser convertidos a um formato padrão que possa ser interpretado por centros de informações de tráfego distribuídos.

Mais especificamente, considere as necessidades de negócios da atual coleta de dados de tráfego, na qual é preciso:

• Integrar diferentes sensores de dados de tráfego (loop, micro-ondas, sensores de vídeo e dados flutuantes de carros).
• Integrar a mesma origem de dados de tráfego de diferentes fornecedores.
• Obter coordenadas de tempo e espaço consistentes de diferentes tipos de sensores de dados de tráfego.
• Fazer ajustes para as diferentes frequências de aquisição; 2 minutos para sistema de sensor fixo, 5 minutos para dados flutuantes de carro e distribuição desigual de sensores.
• Expandir a falta de dados de tráfego. Algoritmos de expansão de dados de tráfego são necessários devido à falta de sensores e a limitações dos métodos de aquisição de dados de tráfego.
• Modificar dados de tráfego anormais, não confiáveis, falsos ou ausentes devido a falha de hardware, pane na comunicação, interferência de ruído, fatores climáticos e acidentes de tráfego.

Este artigo descreve como desenvolver um gateway de dados de tráfego que reúne dados brutos, converte-os para um formato em conformidade com a norma e carrega-os no sistema IBM Intelligent Transportation.

Nas seções a seguir, nós identificamos e damos uma breve visão geral dos desafios enfrentados na coleta e integração de dados, usando um caso de uso real. Mais além, apresentamos a arquitetura geral do IBM Intelligent Transportation com foco especial no componente de coleta de dados brutos de tráfego. Além disso, descrevemos uma implementação detalhada, usando IBM InfoSphere Information Server para extrair, limpar, transformar e carregar os dados de tráfego recebidos quase em tempo real. Esses dados são convertidos para o formato padrão Traffic Management Data Dictionary (TMDD) V3.0 e disponibilizados para engenheiros e planejadores de tráfego para que conduzam análise operacional de rodovias, identificação de gargalos e avaliação e estratégias avançadas de controle.

Voltar para parte superior

Configuração típica de sensores em estradas

A Figura 2 mostra uma configuração típica em um ambiente urbano, na qual tráfego de uma via arterial alimenta a via primária, com o tráfego sendo regulado por um sistema de semáforos. No entanto, o tráfego nesse cruzamento varia ao longo do dia, e os operadores de tráfego podem melhorar o fluxo ao controlar a duração do semáforo no cruzamento com base em dado de volume, velocidade média e tamanho da fila no cruzamento.

Dados dessa natureza são adquiridos, nesse caso, por meio de dois detectores de loop (rotulados de A e B na Figura 2), que detectam veículos passando por eles. Um detector está na via arterial, e o outro, na via primária antes do cruzamento. Um radar de micro-ondas de onda contínua na via primária após o cruzamento também monitora o fluxo de tráfego. O operador do tráfego usa essas informações para tomar decisões sobre a duração do semáforo.

Detectores de loop estão entre os detectores de tráfego estacionários mais implementados, e podem ser configurados para detectar volume de trafego, velocidade e fila de veículos em uma dada seção da via. O radar de micro-ondas de onda contínua é não invasivo e é usado quando interferência excessiva pode ser evitada.

Todo o feed de dados é contínuo (streaming) e precisa ser limpo e convertido de uma maneira lógica que seja representativa do mundo real. O uso de normas, como TMDD, ajuda a obter essa consistência.

Seções seguintes detalham como o produto IBM Intelligent Transportation, combinado com um gateway de dados de tráfego, ajuda a receber os dados dos feeds dos sensores e disponibilizá-los para uso produtivo de operadores nos centros de gerenciamento de tráfego.

Voltar para parte superior

Desafios de implementação

Atualmente, as principais origens de dados de tráfego são dados de detector de loop em estações de monitoramento de tráfego.

Dados de detector de loop requerem investimento em infraestrutura física para expandir a cobertura do monitoramento do tráfego, além de gastos contínuos com manutenção. Novas tecnologias (por exemplo, dados de tráfego de redes sem fio e origens não integradas ao pavimento) têm o potencial de auxiliar na obtenção de dados de monitoramento de sistema ao fornecer maior cobertura a uma fração do custo associado com tecnologias de coleta de dados mais permanentes. Os dados com maior disponibilidade hoje são dados de uso de telefone celular, devido à alta taxa de penetração de celulares. Também é significativa a crescente penetração de telefones inteligentes com sensores de GPS que fornecem dados de localização e geram informações de velocidade precisas. Além disso, um amplo conjunto de métodos de coleta de dados é oferecido, incluindo sondas GPS, sensores Bluetooth e tecnologias de geração de imagens e de radar.

Origens de dados secundárias (fornecedores de dados) também coletam, processam e reempacotam dados para venda.

A combinação de vários tipos de dados é chamada de fusão de dados, e é mostrada na Figura 3. Fusão de dados é o processo de combinar dados de tráfego de vários tipos (velocidade, contagem etc.) de diversas origens para obter estimativas de condições de tráfego para uma estrada inteira. Em geral, fusão de dados envolve a captura de dados de diversas origens, filtragem de dados para remover artefatos desnecessários, combinação dos dados em um modelo matemático carregado em um armazém de dados, saída de estimativas ou previsões sobre condições de tráfego e visualização da saída.

Há vários desafios em uma implementação assim:

• Grandes volumes de dados de origens díspares devem ser coletados em tempo hábil para suportar uma representação de tráfego em tempo real.
• Diversas estratégias de limpeza são necessárias para gerenciar as características de erro das diferentes origens de dados e lidar com diferenças nos dados.
• Estratégias de gerenciamento de processo devem ser desenvolvidas para executar com sucesso o processo de fusão usando uma mistura de diversos fluxos de dados com valores sobrepostos.
• A sustentabilidade de um processo assim deve ser examinada, e os riscos devem ser mitigados dada a inerente viabilidade, complexidade e crescimento.

O mercado de informações de tráfego em tempo real com diferentes tipos de origens de dados está crescendo. Fornecedores podem fornecer novos serviços, um custo competitivo, a mais usuários dispostos a pagar para ter informações precisas de tráfego em tempo real. No entanto, grandes obstáculos para o sucesso são uma estrutura de política e normas mais claras, melhor transparência sobre o desempenho da tecnologia por parte dos fornecedores, e maior sinergia entre os agentes (operadores de celulares, engenheiros de tráfego, provedores de serviços).

Voltar para parte superior

Acessando dados de tráfego

IBM Intelligent Transportation obtém dados de tráfego em tempo real do Transportation Management Center (TMC) de uma cidade. Os dados são transferidos pela rede de longa distância de uma cidade para o IBM Intelligent Transportation, que conecta todos os dados de outros distritos da cidade gerenciados por diversos TMCs. Operadores de tráfego podem acessar o IBM Intelligent Transportation pela Internet, por meio de um navegador da web. A arquitetura de software é modular e aberta; usa software líder do segmento de mercado, de disponibilidade comercial, para comunicação e cálculo. Uma visão geral dos componentes do sistema é mostrada na Figura 4. (Veja uma versão ampliada da Figura 4..)

IBM Intelligent Transportation espera que dados originários de detectores de tráfego sejam limpos, filtrados e convertidos para o formato TMDD XML. Frequentemente isso é feito pelo Advanced Traffic Management Systems (ATMS) operando no Centro de Gerenciamento de Tráfego; mas muitas vezes o sistema ATMS não suporta o formato TMDD XML, ou não há sistema ATMS. As demais seções deste artigo mostram como um gateway de dados de tráfego pode consumir dados brutos de tráfego de sensores de campo e gerar dados de tráfego TMD XML que podem ser integrados com o IBM Intelligent Transportation.

Voltar para parte superior

Coleta e processamento de dados de tráfego

Os dados de tráfego de amostra usados neste artigo foram coletados de detectores de loop único para aproximadamente 28 ligações em um período de uma semana. A via mostrada na Figura 5, tem quatro faixas e um sensor de loop; isso significa que há uma via e quatro pontos que ligam para quatro registros de dados de fluxo de tráfego para cada sensor de loop. O intervalo de coleta de dados do sensor de loop (entrada) é de 30 segundos, e o intervalo de tempo da saída é de cinco minutos.

Os dados de 30 segundos recebidos do sensor de loop consistem em contagens (por exemplo, o número de veículos atravessando o loop) e ocupação (por exemplo, a fração média de tempo em que um veículo está presente no loop). Um componente de captura de dados processa os dados em tempo real e agrega valores de 30 segundos de contagem e ocupação.

• Ele calcula a velocidade de cada faixa.
• Ele calcula o valor agregado de fluxo, ocupação (dados de fluxo mostram a contagem de veículos que passam por um detector de loop a cada 30 segundos, e dados de ocupação mostram por quanto tempo esses veículos estão presentes no detector de loop em porcentagens de uma hora) e velocidade em todas as faixas em cada estação de detector. (Uma estação geralmente atende todos os detectores em todas as faixas em um local.)

O TMC usa os valores médios de cinco minutos de fluxo e velocidade para calcular as seguintes medidas de desempenho:

• VMT (vehicle-miles traveled)
• VHT (vehicle-hours traveled)
• Atraso
• Tempo de viagem

Os detalhes dos dados de tráfego de resultado são referências nos arquivos de amostra na seção Download deste artigo.

Os dados de tráfego coletados pelo TMC são, em seguida, enviados para um gateway de dados de tráfego para maior limpeza e filtragem, além de conversão para o formato da norma TMDD como descrito na seção a seguir. As etapas seguidas para limpeza e filtragem dos dados usam IBM InfoSphere DataStage e IBM InfoSphere QualityStage para realizar as tarefas de extração, transformação e carregamento (ETL) dos dados de tráfego, como mostra a A Figura 6.

Voltar para parte superior

Extração de dados de tráfego

Esta seção oferece um guia geral para as tarefas do InfoSphere DataStage e InfoSphere QualityStage geralmente desenvolvidas para extrair, limpar, transformar e carregar dados de tráfego. Código de amostra é fornecido nos arquivos de amostra (trafficxpath3.dsx); consulte Download.

Tarefa de limpeza de dados de tráfego

• Descrição da função: Projetar e desenvolver tarefas para limpar os dados através da extração de campos de dados que contêm dados e eliminação dos campos que não contêm valores.

Figura 7 e Figura 8 mostram a implementação e aplicação da extração. IBM InfoSphere DataStage e QualityStage Designer fornecem um cliente do Microsoft® Windows® que permite aos desenvolvedores projetar tarefas de integração e limpeza de dados sem precisar escrever código utilizando uma interface com o usuário baseada em gráficos. O processo de integração é desenhado e, em seguida, os detalhes são incluídos para cada estágio. Nesses exemplos, o processo de extração de dados de um arquivo é definido graficamente e os atributos que serão mantidos são identificados.

(Veja uma versão ampliada da Figura 7a.)

Entrada

A Figura 8 mostra uma amostra dos atributos dos dados de tráfego de origem.

A análise dos dados com o uso do InfoSphere QualityStage indicou que havia campos de dados que não continham valores (colunas vazias são visíveis). A entrada da tarefa de extração (TrafficDataIn.txt) é fornecida em Download. (Veja uma versão maior da Figura 8)..)

Output

A seguir temos uma visualização dos dados gerados através da tarefa de ETL. Como mostra a Figura 9, as colunas sem valores foram removidas pela tarefa de ETL para carregar apenas colunas necessárias para processamento posterior no recebimento dos dados.

A saída da tarefa de extração (CleanseData.txt) é fornecida em Download. Mais detalhes sobre o modelo da tabela de dados de saída são mostrados na Figura 9. (Veja uma versão ampliada da Figura 9..)

Tarefa de filtragem dos dados de tráfego

O estágio de filtro, mostrado na Figura 10, é um estágio de processamento que transfere registros de um arquivo de entrada que satisfazem requisitos específicos e filtra todos os outros registros. Neste caso, foram desenvolvidos conjuntos de regras para filtrar dados de tráfego para eliminar dados de sensor que continham erros. As especificações de entrada e saída de origem de dados mostradas na Figura 11 e na Figura 12 são exemplos.

Os registros de dados mantidos são aqueles que estão de acordo com um predicado especificado. Esse predicado determina os registros de dados ou linhas válidos cujas entradas de dados satisfazem a seguinte expressão lógica:

(VOLUME>0 AND SPEED>0) OR (VOLUME=0 AND SPEED=0).

• Descrição da função: Implementar e executar a tarefa de filtragem, como mostra a Figura 10, Figura 11eA Figura 12.

Entrada

Implementar e executar a tarefa de filtragem, como mostra a A Figura 11. A entrada da tarefa de filtragem (CleansedData.txt) é fornecida em Download.

Output

A saída da tarefa de filtragem (FilteredData.txt) é fornecida em Download.

Tarefas de conversão de dados de tráfego

Várias tarefas de transformação de dados (consulte a a Figura 13) foram criadas e executadas para transformar os dados de detector de tráfego em um formato especificado pela norma TMDD. O estágio Column Import mostrado nesse exemplo é um estágio de reestruturação que importa dados de uma única coluna e os coloca em uma ou mais colunas. Esse estágio é usado para dividir dados que chegam em uma única coluna em várias colunas. (Veja uma versão ampliada da Figura 13.)

A entrada das tarefas de transformação (FilteredData.txt) é fornecida em Download. Figura 14 contém uma amostra dos dados de entrada.

Output

A saída das tarefas de transformação (binarydatetimeFilteredData15.txt) é fornecida em Download. A Figura 15 contém uma amostra dos dados de saída. (Veja uma versão ampliada da Figura 15..)

Voltar para parte superior

Transformar fluxo de dados de tráfego sem erros em dados TMDD XML

IBM Intelligent Transportation suporta interface com Centros de Gerenciamento de Tráfego e Advanced Traffic Management Systems (ATMS) usando o padrão Traffic Management Data Dictionary (TMDD) do Institute of Transportation Engineers (ITE). TMDD V3 não apenas padroniza os objetos de dados de tráfego e evento, mas também define as mensagens e diálogos a serem trocados entre sistemas em um padrão U.S. ITS National Architecture Center-to-Center (C2C). (Consulte Recursos.)

Nesse padrão C2C de comunicação, o TMDD define a interface abstrata entre um centro proprietário e um centro externo. O centro proprietário é a organização ou sistema que está capturando e processando dados brutos de tráfego e evento do campo e, portanto, tem a propriedade das informações; enquanto o centro externo é a organização ou sistema interessado em receber os dados de tráfego e evento do centro proprietário. Para fins de integração com o IBM Intelligent Transportation, IBM Intelligent Transportation está no papel de centro externo, e organizações ou sistemas que fornecem dados a ele estão no papel de centros proprietários. figura 16 contém uma visualização conceitual do ambiente operacional de uma interface C2C como definida pela norma TMDD.

A próxima etapa na preparação dos dados de amostra apresentados para alimentação no IBM Intelligent Transportation é converter os dados de tráfego limpos nos formados de objeto de dados TMDD XML apropriados e implementar um serviço da web que suporte o processamento de diálogos de Centro Proprietário TMDD relevantes. O serviço da web deve suportar o recebimento de diálogos TMDD em envelopes Simple Object Access Protocol (SOAP) por meio de HTTP, de acordo com o perfil de aplicativo SOAP/HTTP no padrão NTCIP 2306. (Consulte Recursos.) É importante observar que os diálogos TMDD, que estão de acordo com um de três diálogos genéricos de solicitação-resposta, assinatura ou publicação (como mostram a a Figura 17, figura 18 e A Figura 19), são definidos e criados para serem usados para comunicar e carregar dados de tráfego, evento e dispositivo em tempo quase real no armazenamento de dados operacional do Intelligent Transportation.

Para ajudar na implementação de interfaces de centro proprietário baseado em TMDD, a IBM desenvolveu um Traffic Management Owner Center Simulator. Esse centro proprietário de amostra implementa os diálogos TMDD com os serviços da web de centro proprietário correspondentes e carrega dados de objetos TMDD CML a partir do sistema de arquivos. Para os fins deste artigo e estes dados de amostra, o InfoSphere DataStage XMLOut Stage pode ser usado para converter os dados de tráfego limpos acima para os arquivos de objeto de dados TMDD XML. Esses arquivos de objeto de dados podem, em seguida, ser apanhados pelo Traffic Management Owner Center Simulator para implementar uma interface completa de centro proprietário TMDD que pode ser usada pelo IBM Intelligent Transportation para coletar e armazenar esses dados de tráfego de amostra.

Em um alto nível, as seguintes etapas devem ser realizadas para transformar dados de tráfego limpos, como aqueles mostrados acima, nos arquivos de objeto de dados TMDD XML apropriados que podem ser consumidos pelo Traffic Management Owner Center Simulator:

Projetar a maneira como dados e metadados de tráfego de amostra devem ser representados em diversos objetos de dados TMDD.

Para melhor projetar como os dados e metadados de tráfego de amostra devem ser representados em diversos objetos de dados TMDD, é preciso primeiro entender um pouco como cada representação visualiza o mundo do gerenciamento de tráfego. Quanto melhor você entender como os diferentes modelos ou representações veem o mesmo mundo real de transporte, maior a precisão com que poderá projetar um mapeamento entre duas representações diferentes. Este artigo não discute em detalhes nenhum desses modelos de dados ou por que o mapeamento foi projetado da forma mostrada, mas apenas mostra um exemplo de um mapeamento.

Os metadados associados com os dados de tráfego de amostra foram modelados nesses objetos de alto nível: roads, links, nodes, points e geo-locations. No padrão TMDD, o conjunto de objetos de metadados é, em sua maioria, os objetos focados no inventário. Por exemplo, no mundo dos dados de tráfego, os objetos de metadados primários incluem NodeInventory e LinkInventory. Esses dois modelos e conjuntos de objetos podem ser mapeados de forma bem fácil, como mostra a Tabela 1; esse mapeamento fácil ocorre porque compartilham a mesma terminologia e representam as mesmas entidades físicas. Os dados de tráfego de amostra vieram originalmente de detectores de loop em campo, portanto o mapeamento para objetos de detector TMDD é adequado logicamente.

Mapear campos apropriados de dados de tráfego de amostra para o objeto de dados TMDD.

A Tabela 2 mostra o mapeamento dos campos de dados de tráfego para o objeto TMDD DetectorData, com base no entendimento do que cada campo representa no modelo correspondente.

Transformar dados de tráfego limpos, com base no mapeamento anterior, no formato TMDD XML.

Para gerar um documento TMDD XML que corresponda ao mapeamento anterior usando InfoSphere DataStage, os dados brutos de tráfego filtrados devem ser transformados, por meio de várias tarefas, para colocá-los em um formato fácil para a tarefa XMLOut do InfoSphere DataStage. Abaixo estão alguns detalhes da tarefa XMLOut, o formato de dados de entrada e um formato de dados de saída de amostra. Arquivos de amostra (subdiretório "devWorks_TMDD_Data") são fornecidos na seção Download deste artigo.

Estágio de transformação XML dos dados de detector de tráfego

• Descrição da função: InfoSphere DataStage e QualityStage Designer fornecem um estágio XMLOut de tarefa para transformar um arquivo de entrada separado por vírgulas (veja a figura 20) em um formato de arquivo XML (veja a A Figura 21). Esse arquivo (DetectorData_2009-06-01T00_37_59.xml) também é fornecido na seção Download deste artigo.

(Veja uma versão ampliada da Figura 20.)

(Veja uma versão ampliada da Figura 21..)

O esquema de metadados TMDD XML mostrado na Figura 22 é usado para gerar o seguinte gráfico, que mostra uma estrutura que contém informações de dados de detector de tráfego. No esquema, um documento pode conter vários elementos detector-id , e cada detector-id, por sua vez, pode ter vários elementos vehicle-count e vehicle-occupancy . Por fim, um detectorData pode ter vários elementos detector-id .

(Veja uma versão ampliada da Figura 22.)

Entrada

Os dados de tráfego limpos e filtrados são usados como arquivo de entrada para esse estágio de transformação XML final. Os elementos de dados nesse arquivo devem ser mapeados para os elementos de detector de dados de tráfego TMDD de metadados; veja a Figura 23, Figura 24 e A Figura 25.

O arquivo de origem (binarydatetimeFilteredData15fix1.txt) que é usado, o arquivo de exportação da tarefa (trafficxpath2.dsx) e a origem e definição do esquema XML (DetectorData_2009-06-01T00_37_59.xml) são fornecidos na seção Download deste artigo.

(Veja uma versão ampliada da Figura 23..)

(Veja uma versão ampliada da Figura 24.)

(Veja uma versão ampliada da Figura 25..)

Output

O estágio final de saída XML recebe os resultados vindos do estágio de transformador e produz o TMDD XML de destino como mostra a Listagem 1.

Após os arquivos de saída do InfoSphere DataStage serem criados, a última etapa para transformar esses dados em um formato que o Traffic Management Owner Center Simulator irá aceitar é nomear os arquivos de uma maneira consistente com a estrutura dada. Essa nomeação é uma etapa relativamente menor e foi feita manualmente para este artigo. A saída (devWorks_TMDD_Data.zip subdirectory "DetectorData") é fornecida na seção Download deste artigo.

   
            
   <?xml version="1.0" encoding="UTF-8"?>
<tns:DetectorDataTimeEntries
	xmlns:p1="http://www.ntcip.org/c2f-object-references" 
                  xmlns:p2="http://www.ntcip.org/c2c-message-administration"
	xmlns:p3="http://www.LRMS-Adopted-02-00-00" 
                  xmlns:p4="http://www.LRMS-Local-02-00-00"
	xmlns:p5="http://www.ITIS-Adopted-03-00-02" 
                  xmlns:p6="http://www.ITIS-Local-03-00-02"
	xmlns:tmdd="http://www.tmdd.org/3/messages" 
                  xmlns:tns="http://www.ibm.com/xmlns/transportation/tmdd/simulation"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
	<tns:DetectorDataTimeEntry entryStartTime="2009-06-01T00:37:59.000000">
		<tns:DetectorData>
			<tmdd:detector-id>10</tmdd:detector-id>
			<tmdd:detection-time-stamp>
				<tmdd:date>20090601</tmdd:date>
				<tmdd:time>003759</tmdd:time>
			</tmdd:detection-time-stamp>
			<tmdd:vehicle-count>0</tmdd:vehicle-count>
			<tmdd:vehicle-occupancy>0</tmdd:vehicle-occupancy>
			<tmdd:start-time>
				<tmdd:date>20090601</tmdd:date>
				<tmdd:time>003729</tmdd:time>
			</tmdd:start-time>
			<tmdd:end-time>
				<tmdd:date>20090601</tmdd:date>
				<tmdd:time>003759</tmdd:time>
			</tmdd:end-time>
			<tmdd:detector-data-type>actual</tmdd:detector-data-type>
			<tmdd:vehicle-speed>0</tmdd:vehicle-speed>
		</tns:DetectorData>
		<tns:DetectorData>
			<tmdd:detector-id>12</tmdd:detector-id>
			<tmdd:detection-time-stamp>
				<tmdd:date>20090601</tmdd:date>
				<tmdd:time>003759</tmdd:time>
			</tmdd:detection-time-stamp>
			<tmdd:vehicle-count>0</tmdd:vehicle-count>
			<tmdd:vehicle-occupancy>0</tmdd:vehicle-occupancy>
			<tmdd:start-time>
				<tmdd:date>20090601</tmdd:date>
				<tmdd:time>003729</tmdd:time>
			</tmdd:start-time>
			<tmdd:end-time>
				<tmdd:date>20090601</tmdd:date>
				<tmdd:time>003759</tmdd:time>
			</tmdd:end-time>
			<tmdd:detector-data-type>actual</tmdd:detector-data-type>
			<tmdd:vehicle-speed>0</tmdd:vehicle-speed>
		</tns:DetectorData>
		<tns:DetectorData>
			<tmdd:detector-id>14</tmdd:detector-id>
			<tmdd:detection-time-stamp>
				<tmdd:date>20090601</tmdd:date>
				<tmdd:time>003759</tmdd:time>
			</tmdd:detection-time-stamp>
			<tmdd:vehicle-count>1</tmdd:vehicle-count>
			<tmdd:vehicle-occupancy>3</tmdd:vehicle-occupancy>
			<tmdd:start-time>
				<tmdd:date>20090601</tmdd:date>
				<tmdd:time>003729</tmdd:time>
			</tmdd:start-time>
			<tmdd:end-time>
				<tmdd:date>20090601</tmdd:date>
				<tmdd:time>003759</tmdd:time>
			</tmdd:end-time>
			<tmdd:detector-data-type>actual</tmdd:detector-data-type>
			<tmdd:vehicle-speed>1</tmdd:vehicle-speed>
		</tns:DetectorData>
	</tns:DetectorDataTimeEntry>

</tns:DetectorDataTimeEntries>

Validar que os arquivos TMDD XML estão de acordo com o esquema XML

Usando uma ferramenta de validação XML simples, como aquela integrada no Eclipse, validar que o conjunto gerado de arquivos TMDD XML está de acordo com o esquema XML fornecido pelo Traffic Management Owner Center Simulator.

Para este exercício de validação, o conjunto de arquivos XML gerados, nomeados de acordo com o formato esperado pelo Traffic Management Owner Center Simulator, são carregados no Eclipse e, em seguida, a validação XML é executada para o conjunto inteiro. A Figura 26 exibe a validação ao ser concluída sem erros ou avisos.

Para cada objeto TMDD de metadados, mapear campos apropriados de metadados de tráfego para esse objeto TMDD.

Há um total de três objetos de dados TMDD diferentes que precisam ser criados no formato TMDD XML para melhor representar os metadados para esses detectores de tráfego dos quais os dados de tráfego de amostra se originam. Esses três, como listados na Tabela 1, são NodeInventory, LinkInventory e DetectorInventory. Tabela 3, Tabela 4 e Tabela 5 capturam os mapeamentos dos objetos de metadados para esses três objetos. Como se vê nessas tabelas, alguns dos campos são estáticos, alguns são mapeamentos simples e alguns dos campos requerem examinar vários valores e tabelas diferentes.

Transformar metadados de tráfego no formado TMDD XML para aquele objeto

Para essa etapa, três objetos de metadados TMDD diferentes precisam ser criados com base no design precedente. A transformação do InfoSphere DataStage e estágios XMLOut podem definitivamente ser usados para gerar esses arquivos. InfoSphere FastTrack pode ser usado para especificar os mapeamentos que o InfoSphere DataStage pode executar.

Validar que o arquivo TMDD XML gerado está de acordo com o esquema XML

Usando um processo semelhante ao descrito na Etapa 4 na lista anterior de instruções, os três arquivos de dados de inventário TMDD são validados usando Eclipse e o esquema XML do Traffic Management Owner Center Simulator.

A combinação desses três arquivos, um arquivo OrganizationInformation.xml estático e os arquivos de dados de detector formam a estrutura de dados da entrada do simulador. Esses dados agora estão prontos para serem usados pelo Traffic Management Owner Center Simulator para alimentação para o IBM Intelligent Transportation.

Voltar para parte superior

Carregar as mensagens TMDD XML no Traffic Management Owner Center Simulator

A última etapa do processo é criar um centro proprietário e carregá-lo nos dados de amostra (consulte "devWorks_TMDD_Data.zip" na seção Download) que você limpou e converteu, para que possam ser enviados ao centro externo quando forem solicitados.

Nós discutimos e diagramamos os vários métodos para enviar dados entre o centro proprietário e o centro externo anteriormente em "Transformando fluxo de dados de tráfego sem erros em dados TMDD XML." Os métodos são: diálogos solicitação-resposta, assinatura e publicação (como mostram as figuras nas seções anteriores). Qualquer um desses três métodos é um mecanismo válido para comunicar e carregar dados de tráfego, eventos e dispositivo quase em tempo real no armazenamento de dados operacional do IBM Intelligent Transportation (EC).

As etapas nesta seção abordam a criação de um centro proprietário simulado no WebSphere Application Server, o carregamento de dados de amostra, ou dos dados que você acabou de limpar e converter se estiver acompanhando este artigo, e o uso do simulador para começar a enviar os dados ao centro externo usando SOAP. Siga estas etapas:

1. Preparando e executando o centro proprietário (OC) TMDD no WebSphere Application Server:
   1. Verifique se você tem uma instalação limpa do WebSphere Application Server V7.0.
   2. Faça o seguinte para ativar o serviço bean de inicialização no WebSphere Application Server:
      1. Abra o console administrativo do WebSphere Application Server.
      2. Navegue para Servers, e em seguida para WebSphere Application Servers.
      3. Selecione server1.
      4. Expanda Container Services em Container Settings.
      5. Selecione a opção Startup Beans Service .
      6. Selecione a opção Enable service at server startup .
      7. Clique em OK.
      8. Salve a configuração.
      9. Reinicie o WebSphere Application Server para garantir que a configuração foi salva. (Isso também pode ser feito após aumentar o tamanho do heap da Máquina Virtual Java™; consulte a etapa C a seguir.)
      10. Para parar o WebSphere Application Server a partir da linha de comando no servidor, insira o seguinte comando a partir de <diretório de instalação do WAS>/bin:
          ./stopServer.sh server1
      11. Para iniciar o WebSphere Application Server a partir da linha de comando no servidor, insira o seguinte comando a partir de <diretório de instalação do WAS>/bin:
          ./startServer.sh server1
   3. Aumente o tamanho do heap da Máquina Virtual Java apropriadamente no WebSphere Application Server
      1. Abra o console administrativo do WebSphere Application Server.
      2. Navegue para Servers, e em seguida para WebSphere Application Servers.
      3. Selecione server1.
      4. Expanda Java and Process Management em Server Infrastructure.
      5. Selecione a opção process definition .
      6. Selecione Java Virtual Machine nas propriedades à direita.
      7. Configure o tamanho máximo de heap para 1024 MB.
      8. Clique em OK.
      9. Salve a configuração.
      10. Reinicie o WebSphere Application Server para garantir que a configuração seja salva (essa etapa pode ser feita em conjunto com a etapa B acima) - consulte o conjunto anterior de etapas para as instruções para parar e iniciar o servidor.
   4. Instale o EAR do Simulador TMDD no WebSphere Application Server:
      1. Abra o console de administração do WebSphere Application Server.
      2. Na navegação à esquerda, selecione Aplicativos e New Application.
      3. Selecione New Enterprise Application, como mostra a Figura 27.
         
         Figura 27. WebSphere Application Server – New Enterprise Application
         
         
         
      4. Selecione o local do arquivo TMDD TMD Simulator.ear que deve ser parte do Simulador TMDD.
      5. Use as configurações padrões, mas selecione a opção Deploy Web services como mostra a Figura 28.
         
         Figura 28. Opções de instalação para o EAR do Simulador TMDD no WebSphere Application Server
         
         
         
   5. Copie a estrutura de arquivo dos dados de amostra, incluindo todos os arquivos, para o diretório de arquivos do servidor:
      1. Faça o download dos Dados de Simulação TMDD (devWorks_TMDD_Data.zip); consulte a seção Download deste artigo.
      2. Extraia devWorks_TMDD_Data.zip. (O padrão é extrair para "c:/" se você estiver em um sistema Microsoft Windows) Dados devem ser locais para o WebSphere Application Server.
      3. É possível extrair para qualquer outro diretório, desde que a variável TMDD_SIMULATOR_DATA_DIRECTORY do WebSphere seja configurada para o diretório correto. Consulte as instruções a seguir.
   6. Atualize a variável do WebSphere Application Server que aponta para o diretório.

      Nota: o valor padrão da variável é C:/TMDD_Simulator_Data/. Se você instalou os dados nessa pasta e está em um sistema Windows, não é preciso fazer nada.

      1. Para alterar a variável, abra o console administrativo do WebSphere Application Server.
      2. Expanda o ativo do banco de dados Ambiente .
      3. Selecione a opção WebSphere Variables .
      4. Selecione Nó no menu suspenso de escopo.
      5. Selecione New para criar uma nova variável.
      6. Defina o nome da variável para TMDD_SIMULATOR_DATA_DIRECTORY.
      7. Defina o diretório como o diretório de dados (não se esqueça de incluir "/" no final do nome). Consulte a Figura 29.
         
         Figura 29. Gerenciamento de Variável do WebSphere Application Server
         
         
         
      8. Clique em Apply.
      9. É preciso reiniciar o servidor para que o novo valor seja captado pelo aplicativo simulador.
   7. Inicie o aplicativo corporativo Simulador TMDD TMC:
      1. Abra o console administrativo do WebSphere Application Server.
      2. Expanda o ativo do banco de dados Aplicativos .
      3. Selecione WebSphere enterprise applications.
   8. Verifique se o aplicativo TMDD TMC Simulator iniciou com sucesso e está executando, como mostra a Figura 30.
      
      Figura 30. TMDD TMC Simulator sendo executado no WebSphere Application Server
      
      
      

      Se não estiver em execução, verifique os logs do servidor para ver por quê. Talvez você tenha digitado errado o nome do diretório dos dados de amostra. O trace.log em <diretório de instalação do WAS>/profiles/AppSrv01/logs/server1 contém informações de inicialização e falha. Um exemplo na Figura 31 mostra que ele verifica a variável do WebSphere Application Server e volta para o padrão. O motivo nesse caso é que o diretório real não correspondia ao que foi encontrado na variável do WebSphere Application Server, por isso ele voltava para o padrão.

      
      
      Figura 31. Arquivo de log de amostra do WebSphere Application Server
      
      
      

      (Veja uma versão ampliada da Figura 31.)

2. Executando o centro proprietário e enviando dados para o centro externo.

   Você agora tem um centro proprietário funcional que está lendo TMDD XML de um diretório local e está pronto para enviar para um centro externo que o solicite. Aqui estão instruções para configurar e usar o simulador.

   1. Configure o centro proprietário do simulador de acordo com as preferências desejadas:
      1. Abra TMDD_Simulator_Data/simulation.properties em um editor de texto (o diretório depende de onde você instalou no servidor).
      2. Edite as propriedades de configuração conforme desejado.
      3. Salve e feche o arquivo de propriedades.
   2. Encontre e abra o Console Administrativo do Simulador:
      1. Identifique as portas nas quais o simulador está escutando (essas informações podem ser encontradas no trace.log mencionado acima).
      2. Abra o Console Administrativo do Simulador http://server-host:port/Simulator_Web_Admin/ incluindo o número da porta identificado na etapa anterior.
      3. A tela deve ser como na Figura 32.
         
         Figura 32. Visualização de um Centro Proprietário de Gerenciamento de Tráfego sendo executado com sucesso
         
         
         
      4. Se você modificou a configuração nas etapas anteriores, verifique se essas configurações estão ativas.
      5. Caso contrário, clique em Reload Configuration.
      6. Verifique se os valores de configuração foram atualizados.
   3. Quando o simulador tiver sido instalado e estiver sendo executado corretamente, comece a enviar dados para o Centro Externo TMDD:
      1. Para fazer com que o simulador comece a enviar dados, clique em Start Simulation.
      2. Após iniciar a simulação, é possível ver que os dados estão sendo enviados, pois o tempo de simulação continua mudando à medida que o simulador passa pelos dados do centro proprietário, como mostra a Figura 33.
         
         Figura 33. Visualização do simulador em execução no Console Administrativo do Simulador
         
         
         

         É possível verificar essa transmissão verificando se o centro externo está recebendo os dados. Figura 34 e Figura 35 mostram o recebimento dos dados em um centro externo simulado.

         Pode-se ver os comandos de solicitação de dados e de assinatura sendo processados, bem como o recebimento dos dados.

         
         
         Figura 34. Saída de amostra do teste mostrando dados de amostra sendo executados corretamente
         
         
         

         Na Figura 35, pode-se ver o simulador do centro externo recebendo os metadados de envelope SOAP bem como os dados XML.

         
         
         Figura 35. Monitor TCP/IP de amostra, mostrando TMDD XML sendo enviado do simulador
         
         
         

         (Veja uma versão ampliada da Figura 35..)

Voltar para parte superior

Conclusão

Este artigo teve o objetivo de demonstrar como consumir dados fornecidos em formatos relativamente arbitrários, usando o gateway de dados de tráfego, para o sistema IBM Intelligent Transportation. Incluímos instruções etapa por etapa e amostras de código e dados para ajudar a desenvolver sua própria integração com origens de dados. Esperamos que o material fornecido ajude a tornar você mais produtivo quando estiver desenvolvendo sua integração de dados de tráfego.

Voltar para parte superior

Agradecimento

Os autores desejam agradecer a Curt Brobst por sua contribuição para este artigo.

Voltar para parte superior

Download

Informações sobre métodos de download

Recursos

Aprender

• Modelo de Dados DATEX II
  
  
• IBM InfoSphere Information Server
  
  
• IBM InfoSphere DataStage
  
  
• Normas Traffic Management Data Dictionary (TMDD) Standards: IBM Intelligent Transportation suporta interface com Centros de Gerenciamento de Tráfego e Advanced Traffic Management Systems (ATMS) usando essas normas do Institute of Transportation Engineers (ITE).
  
  
• US National ITS Architecture Versão 6.1: Inclui diversos novos recursos que aprimoram a definição de arquitetura e facilitam o acesso às informações necessárias.
  
  
• Normas TMDD: Suporte a comunicações de centro a centro como parte da implementação regional do ITS para que os centros cooperem no gerenciamento de um corredor, artéria, mitigação de acidentes, gerenciamento de evento etc.
  
  
• "Build intelligent traffic management systems with the Traffic Management Data Dictionary (TMDD) standard" (developerWorks, julho de 2011) dá uma visão geral do padrão TMDD e do Traffic Management Owner Simulator e mostra como o Simulator ajuda com a implementação do padrão, incluindo como integrar com IBM Intelligent Transportation.
  
  
• Padrão NTCIP: Especifica interfaces de comunicação (formulário de mensagem, uso de mensagem e transporte) codificadas em Linguagem de Marcação Extensível (XML entre um centro e um centro externo.
  
  
• Institute of Transportation Engineers (ITE): Saiba mais sobre essa associação educacional e científica internacional de profissionais do transporte, responsável por atender a necessidades de mobilidade e segurança.
  
  
• Segmentos de mercado no IBM developerWorks: Obtenha todos os recursos técnicos específicos do segmento de negócio mais recentes para desenvolvedores.
  
  
• eventos técnicos e webcasts do developerWorks: Mantenha-se atualizado em relação à tecnologia nessas sessões.
  
  
• developerWorks no Twitter: Inscreva-se hoje para seguir os tweets do developerWorks.
  
  
• Podcasts do developerWorks: Ouça entrevistas e discussões interessantes para desenvolvedores de software.
  
  

Obter produtos e tecnologias

• Experimente o software IBM sem custo. Faça o download de uma versão de avaliação, faça login em uma versão de avaliação on-line, trabalhe com o produto em um ambiente de simulação ou acesse-o por meio da nuvem. Escolha dentre mais de 100 versões de avaliação de produtos IBM.
  
  

Discutir

• Crie seu perfil do developerWorks hoje e configure uma watchlist sobre gerenciamento de tráfego. Conecte-se e mantenha contato com comunidade do developerWorks.
  
  

Sobre os autores

Bai Qiang é Application Architect no IBM Global Business Solution Center (GBSC). Ele tem mais de oito anos de experiência no desenvolvimento e arquitetura de aplicativos de TI nos segmentos de mercado de telecomunicações e transporte. Atualmente é responsável técnico por gateway de dados de tráfego e ativo de sistema de gerenciamento de tráfego integrado na equipe GBSC.

Tony Carrato é Chief Product Architect para os produtos Smarter Cities de IBM SWG Industry Solutions. Como tal, ele é responsável pela arquitetura ao longo de IBM Intelligent Operations Center, IBM Intelligent Transportation e outros produtos do portfólio Smarter Cities. Antes desse cargo, Tony foi arquiteto chefe na equipe SOA Advanced Technology do IBM SWG. Tem mais de 30 anos de experiência em TI, trabalhando na América do Norte, Ásia e Austrália. Tony é Arquiteto de TI Certificado Senior IBM, Arquiteto de TI Destacado Certificado Open Group e membro da IBM Academy of Technology.

Chris é engenheiro de normas de solução do segmento de mercado nos segmentos de transporte e educação. Tem uma experiência importante no desenvolvimento de vários padrões de mercado de sistemas de mensagens (incluindo o TMDD e o DATEXII), XML, XML Schema e Java™ .

Dr. Magda Mourad é Certified Distinguished Chief IT Architect na equipe de Industry Solutions do IBM Software Group. Ela é arquiteta do produto IBM Intelligent Transportation. Ela passou a fazer parte da IBM em 1989 como cientista pesquisadora no T.J. Watson Research Center, onde se tornou gerente e depois CTO da unidade de negócios Digital Media em 2005. Também teve duas funções internacionais na Europa e no Oriente Médio. É atualmente chefe do grupo de trabalho do IEEE que desenvolveu uma Prática Recomendada para Digital Rights Expression Languages (DRELs) Adequada para Tecnologias de eLearning.

Pam Nesbitt é Senior Technical Staff Member de Industry Solutions Software na IBM. Muito do seu trabalho é centrado em ajudar a operacionalizar a estratégia técnica de Smarter Cities da IBM, alinhar as estratégias de negócios e técnicas da IBM e ajudar a ativar clientes com as novas soluções Smarter Cities da IBM. Suas atividades anteriores incluem desenvolvimento de software e entrega de soluções aos clientes. Nesbitt ganhou vários prêmios internos e externos por seu trabalho, fez apresentações em várias conferências internacionais e já publicou em alguns jornais com revisão dos pares. É IBM Master Inventor e tem 110 patentes concedidas e pendentes com o USPTO. É bacharel em neurobiologia pela Universidade Cornell e MCIS pela Universidade Cleveland State.

Jackie Ryan atualmente chefia o gerenciamento de produto de solução de segmento de mercado na divisão de Information Management da IBM. Com mais de 20 anos de experiência em tecnologias de informação em várias funções de desenvolvimento de software, estratégia de marketing e gerenciamento de produto, Jackie trabalhou ativamente com clientes para atingir suas metas de negócios utilizando tecnologias da IBM de gerenciamento de dados, integração de informações e analítica de informações.

Lei Zhang é IBM Certified Architect e ITS Lead Architect no Global Business Solution Center. Lei participou de várias implementações e entregas do projeto Smarter Transportation para desenvolver e coletar os ativos reutilizáveis, que estão ativando mais oportunidades de Smarter Transportation para a IBM.

Sri é engenheiro de software senior e líder de normas de solução do segmento de mercado para o segmento de mercado de transportes na IBM. É membro ativo em organizações de normas de transporte, incluindo Open Travel Alliance, trabalhando para criar modelos de serviço padronizados para funções essenciais, como reservas e emissão de passagens. Sri já chefiou relatórios técnicos de consórcios do segmento sobre o tema da aplicação de arquitetura orientada a serviços em segmentos como hotelaria, varejo e educação.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Introdução
• Configuração típica de sensores em estradas
• Desafios de implementação
• Acessando dados de tráfego
• Coleta e processamento de dados de tráfego
• Extração de dados de tráfego
• Transformar fluxo de dados de tráfego sem erros em dados TMDD XML
• Carregar as mensagens TMDD XML no Traffic Management Owner Center Simulator
• Conclusão
• Agradecimento
• Download
• Recursos
• Sobre os autores
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais