Posts com Tag ‘PMV’

PMV Shempo

.

Introdução

Neste artigo serão apresentadas algumas soluções e metodologias desenvolvidas num projeto específico, com o foco na verificação técnica de conformidade de PMVs com as especificações NTCIP. Essas soluções e metodologias também servem de referência para os demais agentes envolvidos no processo. O enfoque deste artigo técnico é a verificação de conformidade e mostrar os desafios decorrentes do grande número de requisitos e de procedimentos de teste definidos nas especificações NTCIP 1203[1] e seu ANEXO C[2]. Os procedimentos de testes descritos no ANEXO C são bastante detalhados. Basta segui-los ou implementá-los se forem realizados de forma automática. Neste artigo será desenvolvida uma metodologia que auxilia a identificar os requisitos obrigatórios, opcionais e condicionais, a partir das especificações de um PMV  e a definir quais os procedimentos de teste necessários para verificar a conformidade desses requisitos. Antes de prosseguir é recomendável que sejam lidos os artigos técnicos:

.

Metodologia

As especificações NTCIP para um determinado equipamento diferem muita das especificações de normas técnicas, pois as NTCIP são flexíveis e se compõem conforme a especificação do que é chamado de Lista de Requisitos de Protocolo ou de Perfil. Nessa lista são selecionados o tipo de painel, tecnologia, funções obrigatórias, opcionais e condicionais decorrentes das funções desejadas para o painel. Dessa forma, cada PMV terá a sua especificação particular e específica. Isso do ponto de vista dos recursos que o PMV pode oferecer. Quando se tratar de uma especificação decorrente de uma licitação de compra de PMVs, a especificação descrita na licitação deverá determinar as necessidades do comprador e determina as especificações mínimas e comuns aos painéis, dentro das especificações do NTCIP. Para realizar um sistema completo de testes automatizados, foram desenvolvidas diversas ferramentas e ambientes que facilitam tanto a especificação dos testes que deverão ser aplicados, quanto à determinação de conformidade de acordo com os resultados dos testes, o que não é trivial. A seguir serão descritos esses ambientes e ferramentas.

.

Especificação inicial dos requisitos

O levantamento dos itens a serem verificados numa avaliação de conformidade devem partir da preparação de uma lista de requisitos, onde são determinadas todas as características desejadas do PMV dentro das especificações NTCIP. Essa lista de requisitos deve ser transposta pelo o que é chamado de Tabela de Rastreabilidade de Requisitos para Procedimentos de Teste, que traduz e conecta os requisitos de alto nível da lista para as rotinas de teste elaboradas dentro da especificação NTCIP 1203, no seu ANEXO C, definindo quais são os testes padronizados, identificados pelo código C.X.Y, que verificam a conformidade com relação a cada requisito do NTCIP (Figura 1).

RTTCTM

Figura 1: Tabela de rastreabilidade de procedimentos de teste

.

A tradução realizada por essa matriz é bidirecional . Isso será discutido com um pouco mais de detalhes adiante. O processo está ilustrado na Figura 2.

 Fluxo de especificação

Figura 2: Ilustração do fluxo de especificação de requisitos

.

Para auxiliar a identificação dos requisitos e recursos disponíveis nos PMVs, foi criado um questionário, que deverá ser preenchido pelo fabricante ou comprador com o auxílio do pessoal técnico que irá realizar os testes de conformidade. Esse questionário traduz para uma linguagem um pouco menos técnica, porém bastante organizada, uma sequência de identificação dos requisitos disponíveis ou desejados para um PMV (Figura 3).

Questionario

Figura 3: Exemplo de dados apurados pelo questionário

.

Preparação dos dados para os testes

A preparação dos dados para os testes automatizados não é trivial. São necessários ao todo até 677 (seiscentos e setenta e sete) parâmetros e dados para os testes automatizados, dos quais uma grande parte deve ser gerada manualmente a cada nova avaliação. Note que na solução que está sendo apresentada aqui, a geração dos dados e a transferência desses dados foi projetada para que fosse feita manualmente. A transformação dessa a coleta e geração de dados manual para automática é simples.

A preparação dos dados começa pelo questionário já mencionado e uma eventual análise de um manual ou catálogo do PMV.  A partir desses dados deverá ser preenchida de imediato uma planilha de dados, que alimentará o sistema com os dados iniciais necessários para os testes (planilha PRLFigura 4).  Por uma questão de conveniência a planilha PRL engloba tanto os dados e parâmetros referentes à PRL, conforme indicado nos testes definidos no ANEXO C da especificação NTCIP 1203, quanto os referentes ao FABRICANTE. Não há motivos para separar esses dados.

PRL_plan

Figura 4: Extrato da planilha PRL preenchida

.

Se necessário, também deverão ser realizadas medidas físicas nos painéis, conforme descrito no documento Questionário de Campo (Figura 5). Esses dados devem ser transferidos para a planilha de CAMPO (Figura 6) .

Field Plan

Figura 5: Extrato do Questionário de Campo

.

CAMPO_Plan

Figura 6: Planilha com os dados de campo

.

Há ainda uma última planilha que precisa ser elaborada antes do início dos testes, que é planilha de planejamento dos testes, ou PLANOTESTE (Figura 7). Nessa planilha são detalhados todos os parâmetros e dados necessários para a realização dos testes automáticos.

TESTPLAN

Figura 7: Extrato da planilha PLANOTESTE

.

Essas planilhas, depois de prontas, são processadas e convertidas para um pequeno banco de dados, para que os dados e parâmetros possam estar disponíveis e serem lidos pelo sistema automático de teste para verificação de conformidade com o NTCIP 1203.

Note que as planilhas com os dados e parâmetros para os testes foram organizadas com várias colunas. A primeira coluna refere-se ao nome do dado utilizado nos testes, na grafia exata como ele é definido nos procedimentos de testes padronizados. Na segunda coluna é inserido o valor do parâmetro. A terceira coluna indica o tipo de dado, para verificação de consistência na hora de gerar o banco de dados. Na quarta coluna é indicado o número do procedimento de teste padronizado a que se referem aqueles dados. Na quinta coluna, é indicada a faixa permitida para aquele parâmetro, onde … quer dizer que não há limite, para teste de consistência também. A sexta coluna contém o nome da planilha que está sendo preenchida.

O fluxo de documentos e dados de entrada pode ser visualizado na Figura 8. Em destaque os números ao lado das setas, que representam a quantidade de dados fornecida por cada planilha.

Dados do PMV a

Figura 8: Fluxo de dados de entrada do Sistema de Testes

.

Descrição do ambiente de teste

O sistema automático de testes foi projetado de forma que ele possa requisitar os dados levantados e compilados nas planilhas, solicitar que um operador realize algumas ações antes de prosseguir ou que um operador confirme o resultado de uma ação do sistema e gera um arquivo de resultados que é utilizado posteriormente para a elaboração do relatório dos testes de avaliação. O núcleo do sistema de testes é o ambiente de testes TTWorkbench [5], fornecido pela empresa Testing Technologies, que permite o desenvolvimento de programas de teste automatizados em notação TTCN-3, a depuração desses programas e sua aplicação para teste de equipamentos. O sistema de testes poderia ter sido desenvolvido em qualquer outra linguagem, tais como C++, Java etc. Usar o TTCN-3 foi uma opção de conveniência.

Na configuração do TTWorkbench que possuímos, não é possível gerar dados externamente e alimentá-los ao sistema conforme a necessidade no decorrer dos testes, ou então solicitar ações ou confirmações ao operador. A solução encontrada para essas deficiências foi a de iniciar um programa que opera em paralelo com o TTWorkbench, que lê o banco de dados das planilhas e supre o TTWorkbench com as informações solicitadas. A solução engenhosa foi desenvolvida em PERL, no qual o programa lê, testa a consistência dos dados das planilhas e disponibiliza o conteúdo dos dados através de uma conexão local por acesso do tipo UDP. Nessa mesma porta o TTWorkbench pode solicitar ações ao operador e a confirmação de resultados, quando necessário. A Figura 9 ilustra a solução desenvolvida.

Sistema de Testes

Figura 9: Detalhes internos do Sistema de Testes Automáticos

.

Desenvolvimento das rotinas de teste

Todas as rotinas de teste automático foram desenvolvidas e escritas em notação TTCN-3 com auxílio do programa TTWorkbench. Os testes propriamente ditos estão definidos na especificação NTCIP 1203 v03.04, em seu ANEXO C. Os programas de teste automáticos em TTCN-3 foram realizados traduzindo-se da melhor maneira possível as descrições dos testes. Nas figuras a seguir é ilustrado um exemplo de como foi realizada essa tradução. Na Figura 10 pode-se ver a descrição de um Test Case, como é apresentado nas especificações NTCIP 1203 e na Figura 11 a sua tradução para TTCN-3. Pode-se observar que a tradução é quase direta.

Ao todo estão definidas na NTCIP 1203 194 (cento e noventa e quatro) procedimentos de teste, divididos em 14 (quatorze) grupos de teste especializados. Por exemplo, o grupo 1 especifica testes de configuração, o grupo 2 especifica testes relacionados com Fonts etc.

Test

Figura 10: Descrição de um procedimento de teste (Test Case)

.

 TTCN-3

Figura 11: Tradução do procedimento de teste para TTCN-3

.

O simulador de PMV como ferramenta

Foi utilizado um simulador de PMV, que simula as principais funções desejáveis de um painel desse tipo, para auxiliar na validação dos programas escritos em TTCN-3 e a geração dos dados necessários aos procedimentos de teste. Esse simulador foi cedido por um fornecedor nacional de PMVs. O simulador é executado como uma máquina virtual em qualquer microcomputador. A ele é atribuído um nº IP fixo e conhecido, para possibilitar o acesso ao simulador pelo sistema de testes. Na Figura 12 pode-se observar o simulador sendo acionado em resposta a um dos testes automatizados.

Simulador

Figura 12: Resposta do simulador a um teste automatizado

.

Desenvolvimento de nova ferramenta auxiliar

Após a revisão e validação dos procedimentos automatizados para teste de conformidade com a especificação NTCIP 1203 ficou bastante clara a dificuldade e a complexidade de se de se julgar se o resultado corresponde à conformidade com as especificações, uma vez que a própria especificação é flexível, dependendo dos itens obrigatórios e opcionais que forem selecionados para um determinado equipamento. Para auxiliar a visualizar o que efetivamente deve ser verificado e se o resultado obtido confere conformidade ao equipamento, foi desenvolvida uma ferramenta de software baseada numa planilha de cálculo. Essa ferramenta possui uma planilha principal, onde se encontra uma versão da lista de requisitos de protocolo ou de perfil (PRL), a qual deve ser preenchida com auxílio do questionário de requisitos. Nessa planilha são definidas as partes opcionais e obrigatórias da especificação. Essa planilha tem todos os campos protegidos com exceção dos campos onde constam as letras em negrito e vermelhas, na coluna “É requisito de projeto?”. Nesses campos é que se definem os itens opcionais e as obrigatoriedades decorrentes deles. Por exemplo, na Figura 13 pode-se ver um pequeno trecho dessa planilha onde o requisito de administração de Fonts é opcional. Pode-se observar também que todos os requisitos associados a essa opção também passam a ser opcionais e não precisam ser considerados para efeito de verificação de conformidade com as especificações.

Requisito Fonts

Figura 13: Requisito opcional de Fonts não selecionado na PRL

.

Quando se opta pela necessidade desse requisito, a planilha automaticamente aponta os demais requisitos que deverão ser considerados. Isso está ilustrado na Figura 14.

Requisito Fonts Sim

Figura 14 – Requisito opcional de Fonts selecionado e o efeito disso na PRL

.

Dessa forma fica muito mais fácil de se reconhecer o que realmente é necessário ser avaliado. A penúltima coluna das Figuras 13 e 14 representa a transposição automática dos resultados dos testes através da segunda planilha da ferramenta de software, que implementa a matriz de rastreabilidade e compila na parte superior de cada subitem, se todos os requisitos selecionados foram atendidos. Essa segunda planilha faz a conexão de requisitos formulados de uma forma mais genérica com os procedimentos de teste. Na realidade essa matriz funciona nas duas direções. Tanto transpõe os resultados para a lista de requerimentos e auxilia a definir a conformidade com as especificações, quanto na outra direção, define quais os testes que deverão ser realizados para essa avaliação. Na Figura 15, está ilustrada a parte da segunda planilha correspondente ao trecho de especificações de Fonts, no mesmo caso ilustrado na Figura 13, ou seja sem selecionar a administração de Fonts.

Matriz de rastreabilidade 1

Figura 15 – Matriz de rastreabilidade de requisitos sem a administração de Fonts

.

Na Figura 16, correspondente à seleção do requisito de administração de Fonts ilustrada na Figura 14, pode-se observar que foram ativados diversos procedimentos de testes que passaram a ser necessários para a avaliação. Ou seja, é necessária a execução dos procedimentos de teste C.3.2.1, C.3.2.2, C.3.2.3 e C.3.2.4 e o PMV nessa situação deve passar nesses testes para ser considerado em conformidade.

Matriz de rastreabilidade 2

Figura 16 – Matriz de rastreabilidade de requisitos com a administração de Fonts

.

A terceira planilha, ilustrada na Figura 17, apresenta a relação dos procedimentos de ensaio e permite que se registre nela se o PMV passou ou não nesses testes. Uma das colunas indica através da matriz de rastreabilidade se o teste deve ou não ser realizado.

Testes e Resultados

Figura 17 – Planilha com os procedimentos de teste e seus resultados

.

Foi criada ainda uma quarta planilha associada às outras três, que produz um resumo dos requisitos obrigatórios e opcionais correspondentes à avaliação corrente e também transpõe os resultados dos testes, ajudando assim a comprovar a conformidade com as especificações NTCIP. Essa planilha pode ser visualizada na Figura 18.

Resumo

Figura 18 – Planilha resumo dos requisitos e resultados dos testes

.

Conclusão

Neste artigo técnico foi apresentada uma metodologia desenvolvida para realizar os testes de conformidade de PMVs com as especificações NTCIP de forma automatizada. O desafio não é realizar os testes, mas saber quais testes são necessários e quais os requisitos a que se está verificando a conformidade. Para auxiliar com isso foi desenvolvida uma ferramenta de software em planilha de cálculo.

Uma ótima fonte de treinamento gratuito sobre NTCIP você encontra nos cursos online do ITS Professional Capacity Building Program (ITS-PCB)[6], oferecidos pelo Departamento Norte Americano de Transportes.

Referências

[1] http://www.ntcip.org/library/documents/pdf/1203v03-04_part_1_dms2011.pdf

[2] https://www.ntcip.org/library/documents/pdf/1203v03-04_Part_2_Annex_C_2011.pdf

[3] https://consulteengenheiroeletronico.wordpress.com/2015/05/29/o-que-e-o-protocolo-ntcip-de-comunicacao/

[4] https://consulteengenheiroeletronico.wordpress.com/2015/06/07/paineis-de-mensagens-variaveis-com-ntcip/

[5] http://www.testingtech.com/products/ttworkbench.php

[6] http://www.pcb.its.dot.gov/stds_training.aspx

.

Licença Creative Commons

Esta obra, “Conformidade de PMV com NTCIP 1203”, de Henrique Frank W. Puhlmann, foi licenciada sob uma Licença Creative Commons Atribuição-NãoComercial-CompartilhaIgual 3.0 Não Adaptada.

 

.

Introdução

Como já foi detalhado no artigo técnico O que é o protocolo NTCIP de comunicação? [1], existe uma resolução da ANTT que tornou obrigatória a conformidade das novas aquisições de equipamentos de ITS (Intelligent Transportation Systems) com o NTCIP a partir de novembro de 2009 (Resolução nº 3.323-A/2009 [2]) para as rodovias federais. Isso afeta a todos os agentes em torno desses equipamentos: fabricantes, desenvolvedores, compradores, concessionários e homologadores. Neste artigo será apresentado o PMV (Painel de Mensagens Variáveis) e alguns detalhes sobre a estrutura interna de dados e a comunicação no padrão NTCIP.

.

O que é um PMV?

Um PMV é um equipamento utilizado nas ruas e rodovias para sinalização e informação aos motoristas. Na Figura 1 está destacado um painel desses, do tipo fixo, que normalmente encontra-se instalado na beira da rodovia, projetando-se por sobre a pista. Existem outros tipos, os móveis por exemplo, que podem ser montados sobre carretas (Figura 2).

pmv fixo dba

Figura 1: Painel de Mensagem Variável do tipo fixo (Fonte: DBA Tecnologia)

.

PMV Movel

Figura 2: Painel de Mensagem Variável do tipo móvel (Fonte:Sinamóvel).

.

Apesar do seu aspecto externo bastante simples, o equipamento é extremamente complexo e sofisticado.

.

PMV com NTCIP

Na Figura 3 pode-se observar uma seleção de aplicação típica para um perfil de um PMV com NTCIP, destacando-se os blocos que devem compor o protocolo e portanto o caminho que a comunicação deve percorrer. A essa composição de blocos dá-se o nome de pilha ou perfil do protocolo. Ou seja, a pilha destacada na Figura 3 é composta pelos seguintes blocos dos níveis correspondentes:

  • Nível de Informação  – PMV             – NTCIP 1203
  • Nível de aplicação      – SNMP           – NTCIP 2301
  • Nível de transporte   – UDP/IP        – NTCIP 2202
  • Nível de subrede       – ETHERNET – NTCIP 2104

 Figura 3

Figura 3: Perfil típico para um PMV

.

Os detalhes de como escolher ou identificar os blocos necessários estão descritos no artigo técnico O que é o protocolo NTCIP de comunicação? [1] (Diagrama de Seleção de Perfil – Figura 5) ou na especificação NTCIP 9001 v04.06 – THE NTCIP GUIDE [3] (Profile Selection Chart).

É importante frisar, que a conformidade de um equipamento de ITS com as especificações NTCIP não se restringe apenas à conformidade com o dicionário de dados específico de cada equipamento, por exemplo as especificações NTCIP 1203 – NTCIP Object Definitions for Dynamic Message Signs (DMS)[5] para um PMV, mas implica na conformidade do equipamento com todos os níveis da pilha do perfil de implementação.

Para aprofundar seu conhecimento sobre PMVs com NTCIP  é recomendável que se realize a leitura da norma técnica NEMA TS-4:2005 Hardware Standards for Dynamic Message Signs (DMS) With NTCIP Requirements [4] . Nessa norma são especificados  requisitos ambientais, mecânicos, ópticos, eletroeletrônicos entre outros, inclusive são indicados os ensaios apropriados para a verificação desses requisitos.

.

Estrutura interna do Sistema do PMV com NTCIP

Todo equipamento com NTCIP deve implementar uma estrutura interna de endereçamento de objetos e variáveis conhecida como MIBs (Management Information Bases).

Segundo definição encontrada na Wikipedia, MIB é um banco de dados usado para gerenciamento de entidades em uma rede de comunicação. Mais frequentemente associada com o Simple Network Management Protocol (SNMP), o termo também é usado mais genericamente em contextos como no modelo de gerenciamento de rede OSI/ISO. Uma vez que sua intenção é de referir-se à coleção completa de informação de gerenciamento disponível em uma entidade, ele é frequentemente utilizado para se referir a um subconjunto particular, mais corretamente referenciado como módulo MIB.

Objetos na MIB são definidos usando um subconjunto da Abstract Syntax Notation One (ASN.1), em português Notação de Sintaxe Abstrata Um, chamada “Structure of Management Information Version 2 (SMIv2)” RFC 2578, em português Estrutura de Informação de Gerenciamento Versão 2.

O banco de dados é hierárquico (estruturado em árvore) e cada entrada é endereçada através de um identificador de objeto. Os RFCs de documentação na Internet discutem os MIBs, notavelmente o RFC 1155, “Estrutura e Identificação de Informação de Gerenciamento para redes baseadas no TCP/IP”, e seus dois complementares, RFC 1213, ‘Base de Informações de Gerenciamento para Gerenciamento de Redes baseadas no TCP/IP” e RFC 1157, “Um Protocolo Simples de Gerenciamento de Rede”.

Os objetos e parâmetros das MIBs do NTCIP estão incluídos na árvore de endereçamento da NEMA (National Electrical Manufacturers Association), que é a retratada na Figura 4. Ela está registrada na árvore de nomes globais da internet. A rede definida pela árvore é numerada nos seus subníveis, formando assim o endereço 1.3.6.1.4.1.1206 como prefixo ou endereço do nó da rede de comunicação de toda informação de gerenciamento pertencente à NEMA . Esse endereço também é conhecido como OID (Object Identifier), ou seja identificador de objeto. Para conhecer os detalhes dessa estrutura, consulte o documento NTCIP 8004 – NTCIP Structure & Ident. of Management Info (SMI) [6].

MIB Tree1Figura 4: Árvore de endereçamento do banco de dados de informação da NEMA

.

A árvore continua abaixo do nó NEMA e divide-se em 4 blocos. Os equipamentos NTCIP estão abaixo do quarto bloco, Transportation (Figura 5).

MIB Tree2

Figura 5: Nós da rede imediatamente abaixo do nó NEMA

.

Descendo mais um nível, abaixo do nó Transportation, nos leva à estrutura mostrada na Figura 6.

MIB Tree3

Figura 6: Nós abaixo de Transportation

.

Descendo mais um nível pelo nó devices, chegamos aos nós referentes aos equipamentos de NTCIP, sendo que o PMV é o nó 3 (DMS – Dynamic Message Sign). Assim, o endereço da raiz do PMV é 1.3.6.1.4.1.1206.4.2.3. Veja a Figura 7.

Devices

Figura 7: Árvore correspondente aos equipamentos com NTCIP

.

Na Figura 8 podemos ver os detalhes dos objetos definidos para o PMV, mostrados no aplicativo gratuito MIB Browser[7].

MIB Browser II

Figura 8: Detalhes da MIB do PMV

.

Nas especificações dos equipamentos NTCIP é comum, no corpo do documento, estar impressa a MIB correspondente àquele equipamento. Você pode consultar a MIB para o PMV no documento NTCIP 1203 – NTCIP Object Definitions for Dynamic Message Signs (DMS) [5]. Na Figura 9 pode-se observar a descrição do objeto dmsSignType. São definidos o tipo de objeto, se é de apenas leitura, se é obrigatório, os limites, os valores que esse objeto pode assumir e uma descrição explicativa para melhor compreensão.

MIB DMS

Figura 9: Detalhe do parâmetro dmsSignType

.

Onde conseguir as MIBs?

A descrição de todos os objetos e parâmetros da MIB do PMV é muito longa, estende-se por dezenas de páginas, dificultando a sua transcrição para uso. Para nossa sorte, existe um site na internet que nos permite baixar as MIBs do NTCIP. Esse site está hospedado no site da NEMA. O acesso é realizado por FTP:

endereço do site: http://www.nema.org/ntcip [8] usuário: speedway senha: metro11 (metro-onze)

.

Comunicação com o PMV

Toda a comunicação com o PMV é realizado por meio do protocolo de comunicação SNMP, que segundo definição do Wikipedia é Simple Network Management Protocol (SNMP), em português Protocolo Simples de Gerenciamento de Rede, é um “protocolo do padrão da Internet para gerenciamento de dispositivos em redes IP”. Dispositivos que normalmente suportam SNMP incluem roteadores, comutadores, servidores, estações de trabalho, impressoras, racks modernos e etc. SNMP é usado na maioria das vezes em sistemas de gerenciamento de rede para monitorar dispositivos ligados a rede para condições que garantem atenção administrativa. O SNMP é um componente do conjunto de protocolos da Internet como definido pela Internet Engineering Task Force (IETF). Ele consiste de um conjunto de padrões de gerenciamento de rede, incluindo um protocolo da camada de aplicação, um esquema de banco de dados, e um conjunto de objetos de dados.

O software de gerência de redes não segue o modelo cliente-servidor convencional pois para as operações GET e SET a estação de gerenciamento se comporta como cliente e o dispositivo de rede a ser analisado ou monitorado se comporta como servidor, enquanto que na operação TRAP ocorre o oposto, pois no envio de alarmes é o dispositivo gerenciado que toma iniciativa da comunicação. Por conta disso, os sistemas de gerência de redes evitam os termos ‘cliente’ e ‘servidor’ e optam por usar “gerente” para a aplicação que roda na estação de gerenciamento e “agente” para a aplicação que roda no dispositivo de rede.

O número de comandos desse protocolo é reduzido. São basicamente os seguintes:

  • GET, para obter um valor de um dispositivo;
  • SET, para colocar um valor num dispositivo.

O comando que especifica uma operação de GET ou SET deve especificar o nome ou endereço do objeto, que é único. O conjunto completo de comandos do SNMP é:

  1. GET, usado para ler uma variável ou parâmetro de gerenciamento;
  2. GETNEXT, usado interativamente para ler sequências de variáveis ou parâmetros de gerenciamento;
  3. GETBULK, usado para ler variáveis ou parâmetros de um grupo de objetos;
  4. SET, usado para escrever em variáveis ou parâmetros  do subsistema gerenciado;
  5. TRAP, usado para reportar uma notificação ou para outros eventos assíncronos sobre o subsistema gerenciado para o sistema administrador.

Na situação atual do protocolo NTCIP, o uso do comando TRAP foi abandonado, podendo-se utilizar os demais. Para ler os detalhes do protocolo SNMP no contexto do NTCIP, leia o documento NTCIP 2301 – Simple Transportation Management Framework (STMF) Application Profile (AP) (AP-STMF)[9].

 .

Resumo

Neste artigo foram apresentados os principais aspectos do protocolo NTCIP relacionados com Painéis de Mensagens Variáveis (PMVs). No próximo artigo serão abordados aspectos técnicos específicos para o teste de conformidade de um PMV com a especificação NTCIP 1203.

Uma ótima fonte de treinamento gratuito sobre NTCIP você encontra nos cursos online do ITS Professional Capacity Building Program (ITS-PCB)[10], oferecidos pelo Departamento Norte Americano de Transportes.

.

Referências

[1] https://consulteengenheiroeletronico.wordpress.com/2015/05/29/o-que-e-o-protocolo-ntcip-de-comunicacao/

[2] http://www.antt.gov.br/index.php/content/view/4323/Resolucao_3323.html

[3] https://www.ntcip.org/library/documents/pdf/9001v0406r.pdf

[4] https://www.nema.org/Standards/ComplimentaryDocuments/TS4.pdf

[5] http://www.ntcip.org/library/documents/pdf/1203v03-04_part_1_dms2011.pdf

[6] http://www.ntcip.org/library/documents/pdf/8004v0215.pdf

[7] http://www.ireasoning.com/mibbrowser.shtml

[8] www.nema.org/ntcip

[9] https://www.ntcip.org/library/documents/pdf/2301v0218.pdf

[10] http://www.pcb.its.dot.gov/stds_training.aspx

.

Licença Creative Commons

Esta obra, “Painéis de Mensagens Variáveis com NTCIP”, de Henrique Frank W. Puhlmann, foi licenciada sob uma Licença Creative Commons Atribuição-NãoComercial-CompartilhaIgual 3.0 Não Adaptada.

Rua noturna

.

Introdução

A ANTT (Agência Nacional de Transportes Terrestres) estabeleceu por meio da resolução nº 3.323-A[1], de 18 de novembro de 2009, que em todo o território nacional, os equipamentos de ITS (Intelligent Transportation Systems) deverão adotar os padrões de Protocolos de Comunicação de Dados e Dicionários de Padrões de dados do NTCIP (National Transportation Communications for ITS Protocol). Essa ação da ANTT obriga as empresas, os desenvolvedores, concessionários e homologadores a adaptarem os seus produtos e processos para cumprir essa resolução. Este artigo apresenta o protocolo de comunicação NTCIP de maneira bastante resumida, para que se possa ter uma visão panorâmica sobre esse assunto.

.

O que é NTCIP?

O setor de gerenciamento de tráfego possui uma longa história de implantação de sistemas com definições de dados privativos e protocolos de comunicações proprietários. Os dispositivos de campo e sistemas fornecidos por um determinado fabricante ou desenvolvedor não permitiam a interoperabilidade com os de outros fabricantes ou desenvolvedores. Como resultado disto, a expansão do sistema após a implantação inicial geralmente só podia ser feita usando-se dispositivos do mesmo tipo e geralmente do mesmo fabricante, como havia sido utilizado na implantação inicial. Com protocolos proprietários há pouca ou nenhuma oportunidade para que seja realizada uma licitação realmente competitiva na expansão do sistema e compra de dispositivos de campo, devido à falta de intercambiabilidade. Também não há qualquer oportunidade para licitação competitiva para adicionarem-se outros tipos de dispositivos de campo no sistema, devido à falta de interoperabilidade. As normas NTCIP[1] especificam definições de dados comuns e protocolos abertos. Elas são uma família completa de normas destinadas a satisfazer as necessidades de comunicação de vários dispositivos nas estradas e centros de gerenciamento de tráfego. A abordagem de padrões do tipo aberto é ilustrada na Figura 1.

  Figura 1

Figura 1: O NTCIP facilita a interoperabilidade e intercambiabilidade de dispositivos de campo

.

Interoperabilidade e intercambiabilidade são dois objetivos fundamentais do esforço para se criar as normas do NTCIP. Os termos interoperabilidade e intercambiabilidade geralmente refletem a capacidade de se usar dispositivos de fabricantes diversos no mesmo canal de comunicação, juntamente com a capacidade de trocá-los entre si. Por exemplo, a capacidade de se colocar qualquer marca de um controlador de semáforo que esteja em conformidade com as normas NTCIP no mesmo sistema, ao mesmo tempo reflete intercambiabilidade para esse tipo de dispositivo. Este texto está baseado no documento NTCIP 9001 v0406[2]. Para entender os detalhes desse protocolo, é recomendável a leitura desse documento, também chamado de The NTCIP Guide.

.

Conceitos

Interoperabilidade

A interoperabilidade reflete a capacidade de vários sistemas de gerenciamento centrais e dispositivos de diferentes fabricantes trocarem informações entre si objetivando alguma finalidade comum. A interoperabilidade permite que componentes do sistema, de fornecedores diferentes, se comuniquem uns com os outros de forma a prover as funções do sistema e a trabalhar conjuntamente como um sistema coeso. Por exemplo, a capacidade de usar a mesma infra-estrutura de comunicação para interconectar um sistema de gerenciamento central com os controladores de tráfego de sinal, painéis de mensagens variáveis (PMV) e outros dispositivos para gerenciar o tráfego, são um exemplo de aplicação real de interoperabilidade.

Intercambiabilidade

Intercambialidade reflete a capacidade de troca de dispositivos do mesmo tipo no mesmo canal de comunicações e esses dispositivos interagirem com outros dispositivos do mesmo tipo usando funções baseadas em padrões. Com intercambialidade, os componentes do sistema podem ser trocados por componentes semelhantes de fornecedores diferentes porque eles possuem características físicas e funcionais comuns. Um exemplo de intercambiabilidade é um controlador de semáforo, que pode ser de fabricantes distintos, interagir com outros semáforos para coordenar em conjunto uma via importante.

.

Panorama do NTCIP

 NTCIP é uma família de padrões de comunicação para transmissão de dados e mensagens entre sistemas de computador usados em sistemas de transporte inteligentes (ITS). Uma comunicação padrão especifica um conjunto de regras de como as mensagens são codificadas e transmitidas entre dispositivos eletrônicos. O equipamento em cada extremidade de uma transmissão de dados usa a mesma especificação para se comunicar com êxito.

  Comunicação do tipo “Centro para Campo” (C2F – Center to Field)

O protocolo NTCIP fornece padrões de comunicação para dois tipos diferentes de estruturas dos sistemas. O primeiro tipo é um sistema de comunicação entre um centro de monitoramento e controle  e vários dispositivos de controle ou monitoramento gerenciados por esse centro. Um exemplo de um sistema desse tipo é um computador no centro de gerenciamento de tráfego de uma cidade, monitorando e controlando a operação de controladores de semáforos nas vias de trânsito dentro dessa cidade. O sistema central pode enviar instruções para os controladores de semáforos para alterar os intervalos de tempo dos controladores conforme se alteram as condições de tráfego. Os controladores de semáforo também enviam informações de fluxo de tráfego e seu status para o computador.

Uma vez que a maioria dos aplicativos desse tipo envolvem um sistema central se comunicando com vários dispositivos de campo, este tipo de comunicação é definido como do tipo “Centro para o Campo” (C2F).   Comunicações do tipo “Centro para Centro” (C2C – Center to Center)

O segundo tipo de comunicação envolve as mensagens enviadas entre dois ou mais sistemas centrais de gerenciamento. Este tipo de comunicação é referido como comunicações de “Centro para Centro” (C2C), embora dois ou mais dos vários sistemas de fato podem estar localizados fisicamente no mesmo local, eles estão logicamente separados. A comunicação entre centrais envolve a comunicação ponto a ponto entre qualquer número de sistemas centrais numa rede complexa. Este tipo de comunicação é semelhante à Internet, em que qualquer centro pode solicitar informações de, ou fornecer informações para qualquer número de outros centros.

Um exemplo de comunicações entre centrais é a de dois centros de gerenciamento de tráfego que trocam informações em tempo real sobre o número e o status dos dispositivos de controle de tráfego. Isso permite que cada sistema central saiba qual o perfil de temporização que o outro sistema central está executando para permitir a coordenação de semáforos dentro dos seus limites geográficos. Na Figura 2 podemos observar como o NTCIP pode integrar sistemas de sistemas inteligentes de tráfego (ITS).

 Integração

Figura 2: Exemplo de integração de ITS utilizando o NTCIP

.

Estrutura do NTCIP

A estrutura do protocolo NTCIP, mostrada na Figura 3, usa uma abordagem em camadas ou modular para os padrões de comunicação, semelhantes à abordagem em camadas adotada pela Internet e pela Organização Internacional de Normas (ISO – International Standards Organization). Em geral, a comunicação de dados entre dois computadores ou outros dispositivos eletrônicos pode ser considerada para envolver as seguintes camadas primárias, chamadas “níveis” em NTCIP, para distingui-los daqueles definidos pela organização internacional para padronização (ISO) e a Internet. Os cinco níveis do NTCIP são:

  • nível de informação
  • nível de aplicação
  • nível de transporte
  • nível de sub-rede
  • nível de campo.

Os níveis no âmbito NTCIP são um pouco diferentes das camadas da pilha de comunicação definidas pelo modelo de referência de sete camadas de interconexão de sistemas abertos (OSI – Open Systems Interconnection) da ISO. O modelo OSI divide o processo de comunicação em sete camadas bem definidas. Cada camada tem um propósito definido, geralmente independente de camadas adjacentes. Apesar dos protocolos de comunicações OSI não serem amplamente utilizados, o modelo de estrutura em camadas permanece como referência.

A pilha de níveis do protocolo NTCIP estende-se além da pilha usual de comunicações para incluir dados informativos e interfaces para a infraestrutura física de comunicações. Os níveis e a terminologia usada no NTCIP foram escolhidos pela simplicidade e facilidade de compreensão por leitores leigos e relevância para aplicações típicas do setor de transporte. Note que na Figura 3 também são indicados através de um número entre parêntesis, os documentos que contêm as especificações NTCIP referentes a cada bloco. Por exemplo as especificações do bloco SNMP estão no documento 2301.

 Figura 2

Figura 3: Estrutura dos protocolos do NTCIP

.

  Conformance x Compliance

Cada norma do NTCIP contém uma seção que indica critérios de conformidade (conformance), que descrevem claramente quais os requisitos são necessários de serem atendidos para estar em conformidade com a norma. A facilidade ou dificuldade de se determinar a conformidade depende da complexidade da norma e a implementação resultante. Fica definido como estar em conformidade em relação às normas do NTCIP (conformance), quando um determinado dispositivo atende a todos os requisitos obrigatórios definidos por uma norma.

Fica definido como estar em conformidade em relação às especificações (compliance), quando um determinado item atende a todos os requisitos definidos por um usuário, em geral uma empresa de gerenciamento de tráfego.

 .

 Perfil de Implementação

Todo dispositivo, que está em conformidade com o NTCIP, utiliza um perfil de implementação, que determina a definição dentre as opções de cada nível do protocolo e quais as que estão implementados no equipamento. Define-se como pilha um subconjunto da estrutura geral de NTCIP determinando uma “rota” selecionada através dos níveis, dadas as opções disponíveis. Algumas pilhas incluem duas normas em alguns níveis, o que geralmente significa que o protocolo pode usar qualquer uma das normas opcionais. Protocolos NTCIP geralmente oferecem mais opções dentro da maior parte das normas. A parte destacada da Figura 4 ilustra um exemplo de uma escolha de pilha de protocolo que pode ser definida usando-se as normas do NTCIP.

Figura 3

Figura 4: Um exemplo de definição de perfil ou pilha de uma comunicação C2F

.

O protocolo ilustrado na Figura 4 tem um perfil SNMP – UDP/IP – Ethernet. Portanto esse perfil é quem define a que partes das normas do protocolo NTCIP o equipamento deve atender. Para auxiliar a identificação desse perfil, deve-se aplicar o Diagrama de Seleção de Perfil de NTCIP ilustrado na Figura 5. As formas de losango identificam os pontos de decisão. A progressão de pontos de decisão é identificada por um número entre colchetes, por exemplo [1]. Caixas com uma linha curva inferior representam documentos, nomeadamente as publicações de normas NTCIP. Estas caixas são codificadas por cores para corresponder com as cores do diagrama da estrutura do NTCIP (Figura 4): azul para o padrão de nível de aplicativo, verde para o nível de transporte e amarelo para o nível de sub-rede. As ovais representam o ponto inicial e o ponto final do caminho decisão tomado para selecionar as publicações de padrões NTCIP.

Fluxo

Figura 5: Diagrama de Seleção de Perfil de NTCIP

.

Seguem abaixo as explicações e considerações referentes aos textos escritos dentro de cada ponto de decisão:

  1. O dispositivo usa Ethernet [1]? — A porta de comunicação primária no dispositivo é um conector RJ-45? Se a resposta for SIM, deve-se verificar também se o dispositivo não está usando um servidor de terminal interno, que poderia aceitar um pacote de dados Ethernet, mas internamente extirpa o cabeçalho/rodapé de Ethernet para entregar um pacote de dados serial para o aplicativo de dispositivo do campo. Se o dispositivo não usa comunicações Ethernet então a resposta é NÃO. Se a resposta for NÃO, então prossiga com a pergunta “Dispositivo usa Serial [2]?”;
  2. O dispositivo usa Serial [2]? — se a resposta à primeira pergunta (Ethernet) é NÃO então o dispositivo usa uma interface serial, uma interface de dial-up ou uma interface não-definida pelo NTCIP. Se o dispositivo está em conformidade com o NTCIP, a resposta tem que ser SIM. Se o dispositivo é algo diferente, então a resposta é NÃO. Se a resposta à primeira pergunta (Ethernet) é NÃO e a resposta a esta pergunta (Serial) é NÃO, então não há padrão NTCIP para a configuração de comunicações em questão;
  3. Está usando Dial-Up [3]? — se a resposta à segunda pergunta (Serial) é SIM, o dispositivo ou utiliza uma interface serial ou então uma interface de dial-up. Se o dispositivo usa uma interface RS-232, então é provável que a resposta seja NÃO. Se o dispositivo tem um modem dial-up interno ou se conecta a um modem dial-up externo, a resposta é SIM;
  4. Tem Modem FSK [4]? — se a interface do dispositivo é serial, o usuário deve decidir se está sendo usado um modem FSK (também conhecido como Bell 202. Mesmo que se utilize um modem externo FSK, que normalmente contém uma porta RS-232 comum de conexão com o dispositivo, um usuário poderia decidir responder a esta pergunta como NÃO. Se os modems externos FSK são usados em ambas as extremidades, a resposta também é NÃO. É uma questão de onde se verifica a conformidade com o NTCIP, fora ou dentro do modem FSK externo.
  5. É requerida a transferência de arquivos [5]? — Não há atualmente algum tipo de dispositivo em conformidade com o NTCIP que opere utilizando exclusivamente um mecanismo de transferência de arquivos.. Se o sistema exige que sejam realizadas transferências de arquivos, a resposta é SIM. Caso contrário, a resposta é NÃO.
  6. É necessário o ACK [6]? — Aqui deve ser decidido se deve ser suportado o TCP/IP ou UDP/IP. Se o protocolo de transferência de arquivos é o FTP, então a resposta é SIM. Se for o TFTP, então a resposta é NÃO. O FTP é mais comumente utilizado, mas o FTP requer mais largura de banda de comunicação e mais recursos de processamento. Se nem o FTP ou o TFTP é usado, pode-se utilizar o TCP ou o UDP; no entanto, UDP é recomendado devido à sua maior eficiência.
  7. É obrigatório utilizar o STMP [7]? — O SMTP é um protocolo que é atualmente suportado apenas por dispositivos de controle de semáforo. A necessidade de se usar o STMP baseia-se nos requisitos de largura de banda do sistema e mídia utilizada.

Após a aplicação do Diagrama de Seleção de Perfil de NTCIP, temos uma relação das normas a que o dispositivo deve atender, além é claro da norma específica para o dispositivo (NTCIP Data Dictionaries) indicada no diagrama da estrutura do protocolo NTCIP em vermelho, quase no topo da estrutura.

O próximo passo, seguindo as orientações das normas do NTCIP, é o levantamento e preenchimento dos requisitos do dispositivo amarrados com os requisitos do protocolo. Trata-se da PRL (Protocol Requirements List) ou lista de requisitos de protocolo. Muitas das normas do NTCIP contêm a descrição de uma PRL, que serve para mapear a correspondência de cada necessidade de um usuário, para os requisitos que satisfazem essa necessidade, garantindo que todas as necessidades sejam atendidas. A PRL é também uma lista de todos os requisitos obrigatórios, opcionais e condicionais que satisfazem a cada necessidade do usuário suportada pelas normas do NTCIP. Se uma necessidade de um usuário é marcada na sua especificação, todos os requisitos obrigatórios que decorrem dessa necessidade de usuário devem ser suportados pela implementação. Requisitos opcionais também podem ser selecionados numa especificação técnica, se acaso esses requisitos forem considerados necessários para a sua execução. Requisitos condicionais podem ser obrigatórios ou facultativos, mas se aplicam somente quando o recurso ou as características identificadas são suportados. Na Tabela 1, observa-se um exemplo de uma PRL parcial relativa à norma NTCIP 1203 v03 [5] (PMV). Nessa tabela M (Mandatory) quer dizer obrigatório e O opcional.

Tabela 1: Exemplo de uma PRL – Lista de requisitos de protocolo.

PRL

.

Associada à PRL é definida uma matriz de rastreabilidade de requisitos (RTM). Uma matriz de rastreabilidade de requisitos (RTM) mapeia os requisitos de sistema para os elementos da solução de uma norma NTCIP, ou seja, os conceitos de dados tais como os elementos de dicionário de dados e diálogos normalizados. Se um requisito é incluído em uma especificação de um usuário, a matriz RTM descreve os conceitos de dados, incluindo os diálogos que devem ser implementados para atender a essa necessidade e em conformidade com a norma NTCIP. Essa matriz serve de guia para a realização de testes de conformidade. Um exemplo de uma matriz RTM parcial da  NTCIP 1203[5] é mostrado na Tabela 2.

Tabela 2: Exemplo de uma matriz de rastreabilidade de requisitos (RTM)

RTM

.

Na Figura 6 pode-se observar a ilustração de um diálogo padronizado para a ativação de uma mensagem, conforme definido na norma NTCIP 1203 v0300 [5].

 Dialogo Definir Mensagem

Figura 6: Diálogo padrão para a ativação de uma mensagem no PMV

.

Em algumas normas do NTCIP específicas para os dispositivos, são detalhados no Anexo C os procedimentos de teste normatizado.s  Esses procedimentos de teste têm o seu formato definido pela norma NTCIP 8007 – Testing and Conformity Assessment Documentation within NTCIP Standards Publications[4] e por sua vez segue as diretrizes da norma IEEE 829 – Standard for Software Test Documentation e definem os testes mínimos que deverão ser realizados para verificar a conformidade do equipamento com as normas do NTCIP. Na Figura 7, pode-se observar um Test-Case padronizado definido no Anexo C da NTCIP 1203 v0300[6].

Test

Figura 7: Exemplo de Test-Case padronizado, definido na norma do NTCIP

.

Essa padronização facilita muito a automação dos testes, uma vez que fica definido em norma todo o procedimento, diálogos e condições de aceite ou falha.

.

Resumo

Neste artigo técnico foi apresentado um breve panorama do protocolo de comunicação NTCIP. Devido à sua implementação ser obrigatória nas novas aquisições de equipamentos de ITS para as rodovias brasileiras, por determinação da ANTT, tornou-se necessário o estudo e conhecimento dos requisitos desse protocolo por parte de todos os agentes envolvidos no processo:

  • Fabricantes de equipamentos de ITS;
  • Desenvolvedores de equipamentos e sistemas;
  • Autoridades de gerenciamento de tráfego (licitações de compra);
  • Dos homologadores (testes de conformidade).

Uma ótima fonte de treinamento gratuito sobre NTCIP você encontra nos cursos online do ITS Professional Capacity Building Program (ITS-PCB)[7], oferecidos pelo Departamento Norte Americano de Transportes.

Leia também os demais artigos dessa série:

  • Painéis de Mensagens Variáveis com NTCIP[8] – Neste artigo são apontados os principais aspectos do NTCIP em PMVs;
  • Conformidade de PMV com NTCIP 1203 [9] – Aborda os desafios de se verificar a conformidade de PMVs com as especificações NTCIP.

Referências

[1] http://www.antt.gov.br/index.php/content/view/4323/Resolucao_3323.html

[2] https://www.ntcip.org/

[3] https://www.ntcip.org/library/documents/pdf/9001v0406r.pdf

[4] http://www.ntcip.org/library/documents/pdf/8007v01-19b.pdf

[5] http://www.ntcip.org/library/documents/pdf/1203v03-04_part_1_dms2011.pdf

[6] http://www.ntcip.org/new/1203v0301b_annex_c_ucd.pdf

[7] http://www.pcb.its.dot.gov/stds_training.aspx

[8] https://consulteengenheiroeletronico.wordpress.com/2015/06/07/paineis-de-mensagens-variaveis-com-ntcip/

[9] https://consulteengenheiroeletronico.wordpress.com/2015/06/14/conformidade-de-pmv-com-ntcip-1203/

.

Licença Creative Commons

Esta obra, “O que é o protocolo NTCIP de comunicação?”, de Henrique Frank W. Puhlmann, foi licenciada sob uma Licença Creative Commons Atribuição-NãoComercial-CompartilhaIgual 3.0 Não Adaptada.