Adriano Galindo Leal, Alessandro Santiago dos Santos, Henrique Frank Werner Puhlmann, Matheus Jacon Pereira

Transcrição

1 AVALIAÇÃO AUTOMATIZADA DA CONFORMIDADE E INTEROPERABILIDADE DE EQUIPAMENTOS E SISTEMAS DE ITS AO PADRÃO NTCIP POR MEIO DA PLATAFORMA DE TESTES TTCN-3 Adriano Galindo Leal, Alessandro Santiago dos Santos, Henrique Frank Werner Puhlmann, Matheus Jacon Pereira RESUMO Instituto de Pesquisas Tecnológicas do Estado de São Paulo S/A IPT Centro de Tecnologia da Informação, Automação e Mobilidade No contexto dos ITS (Sistemas de Transportes Inteligentes), um grande desafio é homologar e comprovar, de forma rápida e eficiente, a interoperabilidade de todos os componentes do sistema de transporte tanto em ambiente de desenvolvimento, quanto em cenários reais. A resolução Nº A da Agência Nacional de Transportes Terrestres definiu que todos os equipamentos de ITS devem 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). Assim, é essencial estabelecer uma plataforma de testes para avaliar tanto a conformidade com os padrões estabelecidos, quanto com as complexas regras de negócio da área de transportes. Sendo que a utilidade desta plataforma é indispensável nas etapas de desenvolvimento de equipamentos e na de integração de sistemas. Como solução prática, este artigo expõe a aplicação de ensaios automatizados de equipamentos de ITS utilizando a plataforma de testes TTCN-3 para homologação de conformidade com o protocolo NTCIP e outros. O método proposto foi aplicado com sucesso na homologação de conformidade com o protocolo de Transação DUAL em antenas AVI (Automatic Vehicle Identification) do sistema Sem Parar/Via Fácil. Adicionalmente é apresentada a perspectiva de extensão do uso desta metodologia envolvendo sistemas em cenários complexos de transporte utilizando NTCIP, como exemplo é citado o desenvolvimento da homologação pelo NTCIP de um painel de mensagens variáveis que estará completo em fevereiro de Em cenários internacionais, esta metodologia é utilizada em outras áreas, tais como: telecomunicações, redes de energia inteligentes (Smart Grid), serviços computacionais nas nuvens (Cloud Computing), etc. No entanto, esta metodologia é pouco difundida no Brasil. Palavras-chave: Sistemas de Testes Automatizados; TTCN-3, NTCIP, interoperabilidade, AVI. 1 INTRODUÇÃO Atualmente, em se tratando de equipamentos ITS, os sistemas e equipamentos oferecidos por um determinado fornecedor podem não permitir a interoperabilidade com os de outros fabricantes ou desenvolvedores. Como resultado disto, após a implantação inicial, as opções para a expansão do sistema podem restringir a utilização de modelos de outros fabricantes ou mesmo de um modelo mais moderno do mesmo fabricante. A adoção dos 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) tem o objetivo de estabelecer uma uniformidade funcional dos componentes que irão compor a solução de gestão de tráfego, de forma que sejam interoperáveis entre si e exista a intercambiabilidade de equipamentos de tráfego de diferentes procedências. Para aferir a conformidade com os padrões estabelecidos pela NTCIP, é essencial estabelecer uma plataforma de testes. No entanto, se utilizarmos a verificação manual dos requisitos, esta exigirá um enorme esforço em termos de homens-hora, além de ficar sujeita a um eventual erro humano. Por conseguinte, para viabilizar a redução do tempo gasto e melhorar a confiabilidade e repetitibilidade do processo, torna-se imprescindível automatizar o processo. 1

2 Entrementes, para se minimizar os riscos de adquirir uma solução que não atenda completamente aos requisitos, podendo gerar transtornos na implementação ou na operação da solução, o NTCIP recomenda que ao se definir a compra de equipamentos ou sistemas ITS, seja através de uma RFP (Request For Proposal) normalmente utilizada por instituições privadas, ou através de Editais de Licitação utilizados por instituições públicas, é importante estabelecer uma etapa de avaliação de conformidade de produtos. Todavia, não é viável em um processo de compra, um longo processo de avaliação de conformidade, pois isso gera um custo adicional ao processo que pode inviabilizá-lo. Consequentemente, mais uma vez torna-se essencial a utilização de plataforma de testes automatizados para testar aspectos críticos de interoperabilidade. Para estabelecer uma plataforma de testes automatizados é necessário incorporar componentes que automatizem os vários níveis de teste, isto é, que seja possível automatizar o teste de conformidade do protocolo de comunicação utilizado pelos equipamentos/sistemas (camadas de baixo nível), ou mesmo orquestrar as operações entre equipamentos e sistemas interoperáveis (camadas de alto nível), Figura 1. Camadas de alto nível Sistema de Controle Protocolos de comunicação Camadas de baixo nível Câmeras Antenas AVI Rede de Comunicação Semáforos Call box PMV Requisição de informações e ativação de funcionalidades Figura 1. Camadas Lógicas de Interoperabilidade Algumas tecnologias podem providenciar uma automação dos testes de conformidade, sendo algumas delas maduras e vêm sendo internacionalmente utilizadas para o desenvolvimento e homologação de diversas soluções, tais como: equipamentos de redes de computadores, redes de energia inteligentes (Smart Grid), serviços computacionais nas nuvens (Cloud Computing), etc. Neste artigo, é apresentada a plataforma tecnológica chamada TTCN-3 (Testing and Test Control Notation version 3), a qual emprega uma metodologia consistente para testes automatizados. Assim, descrevemos a metodologia e os resultados obtidos através de ensaios automatizados de equipamentos de ITS utilizando a plataforma de Testes TTCN-3 para homologação de conformidade com o Protocolo de Transação DUAL em antenas AVI do sistema Sem Parar/Via Fácil. Além disso, é apresentada a perspectiva de extensão da metodologia para aferir a conformidade com a família de normas do NTCIP, que estabelece as regras de comunicação necessárias para permitir que os equipamentos eletrônicos de controle de tráfego de diversos fabricantes operem de forma integrada. 2 MÉTODO PARA TESTES AUTOMATIZADOS EM ITS Um cenário tradicional de emprego de sistemas e equipamentos ITS envolve uma rede de comunicação, que integra fisicamente os equipamentos e uma Central de Controle Operacional que monitora e maneja os equipamentos por meio dos sistemas de controle em suas instalações (Figura 2). 2

3 Antenas AVI Call box CCO PMV Sistema de Controle Câmeras Semáforos Figura 2. Cenário de Integração de Equipamentos ITS e Sistemas de Controle Nesse mesmo contexto, a plataforma de teste pode ser configurada para um cenário de teste, que substitui o Sistema de Controle ao submeter um Script de Operações ao Equipamento sob teste, que avalia as respostas (conformidade) do equipamento para uma sequência de operações padronizadas (Figura 3 Cenário [A]). Da mesma forma, a plataforma de teste pode substituir o equipamento ITS, possibilitando testar o comportamento do Sistema de Controle para todas as situações e contingências que o equipamento ITS possa apresentar. Sendo que, em situações reais, algumas simulações nem sempre são possíveis ou economicamente viáveis (Figura 3 Cenário [B]). Ações dos scripts PLATAFORMA DE TESTES Script de teste Ações dos scripts PLATAFORMA DE TESTES Script de teste Cenário [A] Cenário [B] Figura 3. Cenários de testes com a plataforma A plataforma de teste empregada é baseada no padrão aberto de testes TTCN-3, normalizada pelo ETSI (European Telecommunications Standards Institute) e ITU-T (Telecommunication Standardization Sector). Esta plataforma atua tanto na camada de alto nível, representada na Figura 1, quanto consegue estabelecer comunicação direta com os equipamentos por meio de portas de comunicação padronizadas (RS232, Ethernet, etc.). 3 TTCN-3 A plataforma de Teste TTCN-3 é formada por uma série de Interfaces Normatizadas pela ETSI e ITU-T, tendo sido criada especificamente para implementar sistemas de teste complexos para diferentes tipos de tecnologias. Neste artigo, está sendo utilizada em cenários de comunicação de equipamentos ITS. Apesar desta tecnologia estar bem estabelecida no mercado europeu, ainda é relativamente pouco difundida em território brasileiro. 3

4 4.1 Arquitetura TTCN-3 A Figura 4 exibe a arquitetura empregada pelo TTCN-3 (ETSI, 2010), sendo composta pelos seguintes componentes: TTCN-3 Runtime Interface (TRI): É responsável pela implementação de componentes de teste específicos. Descreve e define a comunicação entre os testes e o sistema a se testar. Inclui também um Adaptador da Plataforma (PA) e Adaptador de Sistema (SA), para dar suporte a funções externas e integração de conceitos de tempo (ETSI, 2010); TTCN-3 Control Interface (TCI): Está associada à parte de controle do Sistema de Teste TTCN-3. No TCI estão incluídas 3 interfaces normalizadas. Component Handling (CH), Test Management (TM) e os Codec s (CD). (ETSI, 2010); Component Handling (CH): É responsável pela atribuição dos componentes de teste em sistemas físicos. Podendo realizar esta tarefa em um ou vários sistemas físicos em paralelo (ETSI, 2010); Test Management (TM): É responsável pela gestão global do sistema de teste (ETSI, 2010); Codec (CD): Tem a atribuição de codificar e decodificar os dados externos vindos do Sistema em Teste (ETSI, 2010). Figura 4. TTCN-3 Test System (Fonte: Testing Technologies) 4.2 Desenvolvimento de Testes automatizados em TTCN-3 Basicamente existem quatro etapas básicas para a execução de testes automatizados na plataforma: criação do pacote de testes automatizados, compilação do pacote, execução e análise dos resultados (ETSI, 2010). 1. A criação de pacotes de testes é feita através da criação de um conjunto de scripts de testes (Figura 5). Estes scripts são desenvolvidos de acordo com a norma TTCN-3 Core Language (CL) (ETSI, 2010); 2. Após a conclusão do processo de criação dos scripts, é necessário que estes sejam compilados, no caso deste artigo utilizou-se um framework baseado na IDE Eclipse, que é desenvolvido em Java (TESTINGTECH, 2010); 3. Com a compilação é criado um executável para cada script, estes executáveis compõe o TTCN-3 Executable (ETSI, 2010), que é a estrutura central da Plataforma de Testes TTCN-3 (Figura 4); 4. É gerado um completo ambiente de administração e de execução dos testes, permitindo aos utilizadores executar e analisar os resultados dos testes realizados em um ambiente gráfico (Figura 6). 4

5 Figura 5. Código genérico com sintaxe definida na TTCN-3 CL (fonte: Testing Technologies) Plataforma de teste ações do script Sistema sob teste recebendo e respondendo aos comandos da plataforma Figura 6. Representação gráfica da execução do script de teste Figura 7. Arquivo XML para configuração de ambiente de execução. (Fonte: Testing Technologies) 5

6 Para que os testes funcionem de maneira correta, é necessário realizar a configuração do ambiente de execução. Além disto, tem caráter fundamental a geração de um arquivo XML (Extensible Markup Language), onde constam as camadas responsáveis pela transmissão dos dados, bem como as informações e os endereços das Interfaces Normalizadas e do objeto em teste, conforme exemplo da Figura 7. 4 ESTUDO DE CASO A plataforma de testes, apresentada nas seções anteriores, foi empregada no teste de conformidade de Antenas DSRC (Dedicated Short Range Communications) com o protocolo de Transação DUAL - PTD Brasil (IPT, 2002) em antenas AVI do sistema Sem Parar/Via Fácil. Estas antenas são usadas em ambiente de coleta eletrônica de pagamentos (EFC - Electronic Fee Collection). Nesse ambiente, a Antena (RSE) é instalada em via de cobrança automática e se comunica com o controlador da via (computador), que se comunica com os sistemas de controle. A plataforma de teste foi instalada em um Notebook, o qual substituiu o computador de via, sendo o mesmo cenário apresentado pela Figura 3 cenário [A]. Para verificar a conformidade da Antena ao protocolo DUAL- PTD Brasil (Rigo, 2001), foi confirmado se a implementação dos comandos provindos do controlador de via está em conformidade com o Protocolo de Comunicação Serial (Q-FREE, 1997) (Q-FREE, 2003). Com o intuito de realizar tal verificação, utilizou-se o Laboratório de Interoperabilidade de Antenas de Pedágios do Instituto Pesquisas Tecnológicas do Estado de SP (IPT), que dispõe de um ambiente necessário para simular uma situação real de uma praça de pedágio. No laboratório, estão instalados uma Antena DSRC (Figura 8- [B]), e um sistema que movimenta uma Tag em velocidades equivalente a passagem do veículo pela via (Figura 8- [A]). Local de instalação da Tag Sentido do movimento Pista com Tag em movimento [A] Antena DSRC [B] Figura 8. Sistema que simula passagem de veículo com Tag em pista AVI Cabe à plataforma de testes TTCN-3 simular todos os comportamentos possíveis do controlador de via, conforme especificação do Protocolo de Comunicação Serial (Q- FREE, 1997) (Q-FREE, 2003). Por conseguinte, foram elaborados um conjunto de scripts de teste, de acordo com a norma TTCN-3 Core Language (ETSI, 2010), para simular todos os 22 comandos possíveis de serem executados pelo controlador de via. O objetivo deste conjunto de scripts é confrontar a resposta da Antena com a especificada pela norma, para avaliar a conformidade. 6

7 Como exemplo, a Figura 9 exibe parte do script principal do pacote, que executa o comando SetCountry. Como pode se observar, a IDE gera um relatório gráfico padronizado no formato TTCN-3 Graphical Presentation Format (GFT) (ETSI, EUROPEAN TELECOMMUNICATIONS STANDARDS INSTITUTE, 2010). Consequentemente, o usuário pode, através da IDE, avaliar graficamente a resposta da antena frente à execução do script de teste, o símbolo pass no final da representação gráfica indica sucesso na execução do script. Figura 9. Script principal e resultado gráfico da sua execução com sucesso. Com esta tecnologia, os 22 comandos, simulados pelos scripts, substituem os ensaios manuais que eram executados anteriormente, e acrescentam algumas vantagens: A reconfiguração do ambiente a cada teste pode ser refeita automaticamente pela plataforma de teste. Em um processo de teste manual, a cada execução, se gasta um tempo para reconfigurar o ambiente manualmente. Desta forma, permite maior agilidade e precisão na execução repetitiva dos testes para as várias possíveis posições angulares da Tag, já que cada veículo pode ter o para-brisa em ângulos diferentes; Com a automatização dos diversos procedimentos de teste de conformidade, o processo ficou mais repetitivo, independente do operador, confiável e eficiente, eliminando possíveis falhas humanas na operação da estrutura do laboratório; Os resultados são automaticamente documentados pela ferramenta, e elimina a falha humana na coleta e análise dos resultados das simulações. 5 APLICANDO A TECNOLOGIA TTCN-3 AO NTCIP Foi estabelecido que, no território nacional, os equipamentos de ITS 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). Esta determinação foi estabelecida pela resolução Nº A da Agência Nacional de Transportes Terrestres (ANTT, 18 de novembro de 2009). No restante deste capítulo, será dada uma breve introdução ao NTCIP baseada no documento NTCIP 9001 v0406. Para maior profundidade, recomenda-se a leitura completa de família de normas NTCIP. O NTCIP é uma família de normas que estabelece as regras de comunicação necessárias para permitir que os equipamentos de controle de tráfego de diversos modelos operem de forma integrada. Portanto, as normas NTCIP reduzem a dependência de fornecedores 7

8 de equipamentos específicos. A abordagem de padrões é ilustrada na Figura 10. Figura 10. O NTCIP facilita a interoperabilidade e intercâmbio de dispositivos de campo. (NTCIP 9001 v0406) Segundo a norma NTCIP NTCIP 9001 v0406, os padrões de comunicação entre os sistemas são divididos em dois tipos diferentes: Comunicação do tipo Centro para Campo (C2F Center to Field) e Comunicações do tipo Centro para Centro (C2C Center to Center). Na Figura 11, podemos observar como o NTCIP pode integrar sistemas ITS. Figura 11. Exemplo de integração de ITS utilizando o NTCIP. (NTCIP 9001 v0406) Como o NTCIP define uma comunicação padrão entre os equipamentos de ITS através de um conjunto de regras de como as mensagens são codificadas e transmitidas entre os dispositivos e sistemas, torna-se possível utilizar a plataforma de teste TTCN-3 para realizar os testes das camadas de alto nível, conforme modelo apresentado na Figura 1, e utilizar softwares específicos que sejam de capaz de testar as camadas de baixo nível com NTCIP. 8

9 5.1 Estrutura do NTCIP A estrutura do protocolo NTCIP, mostrada na Figura 12, usa uma abordagem em camadas ou modular para os padrões de comunicação, semelhantes à abordagem em camadas adotada pela Internet e a organização internacional de normas (ISO). 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 (NTCIP 9001 v0406). 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. A pilha de níveis do NTCIP estende-se além da pilha de comunicação definida pelo modelo de referência de sete camadas de interconexão de sistemas abertos da ISO (OSI - Open Systems Interconnection), uma vez que inclui 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 dos leitores e sua relevância para aplicações típicas do setor de transporte (NTCIP 9001 v0406). Figura 12. Estrutura dos protocolos do NTCIP. (NTCIP 9001 v0406) 5.2 Roteiro para a verificação de Conformidade com o NTCIP Todo dispositivo que está em conformidade com o NTCIP, utiliza um perfil de implementação que é a definição dentre as opções de cada nível do protocolo, de quais as opções 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. Para auxiliar a identificação desse perfil, devese aplicar o Diagrama de Seleção de Perfil de NTCIP ilustrado na Figura 13 (NTCIP 9001 v0406). 9

10 Begin Device Uses Ethernet? [1] Yes No Device Uses Serial? No [2] Non-NTCPIP Device Yes 2104 Ethernet Using Dial-Up? [3] No FSK Modem? [4] No 2101 PMPP & TIA-232-F Ye s Yes 2103 PPP & V Series Modem 2102 PMPP & FSK Modem File Transfer Required? [5] No Ye s File Transfer Required? [5] No 2302 TFTP Yes Ack Required?[6] No 2201 T2/Null Yes 2302 TFTP 2202 UDP/IP STMP Required? [7] No Yes 2303 FTP 2301 STMP 2202 TCP/IP 2301 SNMP Start/ End Decision Point LEGEND NTCIP Application Level Standard NTCIP Transport Level Standard NTCIP Subnetwork Level Standard End Figura 13. Diagrama de Seleção de Perfil de NTCIP. A seguir é descrita a simbologia utilizada no diagrama (NTCIP 9001 v0406): 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] (NTCIP 9001 v0406); 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 12): 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 (NTCIP 9001 v0406); As formas ovais representam o ponto inicial e o ponto final do caminho decisão tomado para selecionar as publicações de padrões NTCIP (NTCIP 9001 v0406). 10

11 Sequem abaixo as explicações e considerações referentes aos textos escritos dentro de cada ponto de decisão: 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]?" (NTCIP 9001 v0406); O dispositivo usa Serial [2]? Se a resposta à primeira pergunta (Ethernet) é NÃO, então o dispositivo usa uma interface serial ou 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, então a resposta a esta pergunta (Serial) é NÃO, e, portanto, não há padrão NTCIP para a configuração de comunicações em questão (NTCIP 9001 v0406); 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 (NTCIP 9001 v0406); 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 (NTCIP 9001 v0406); É 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 (NTCIP 9001 v0406); É 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 (NTCIP 9001 v0406); É 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 (NTCIP 9001 v0406). 11

12 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) indicado no diagrama da estrutura do protocolo NTCIP em vermelho (Figura 12), quase no topo da estrutura (NTCIP 9001 v0406). 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 (Profile Requirements List) ou lista de requisitos de perfil. A PRL é uma lista de todos os requisitos obrigatórios, opcionais e condicionais que satisfaz a cada necessidade suportada pelas normas do NTCIP. Se uma necessidade de um usuário é marcada na sua especificação, todos os requisitos obrigatórios que decorrem dela devem ser suportados pela implementação (NTCIP 9001 v0406). Na Figura 14 pode-se observar a ilustração de um diálogo padronizado para a ativação de uma mensagem, conforme definido na norma NTCIP 1203 v0239. :Management Station Precondition: The management station shall ensure that the desired message is supported by the DMS. This may entail downloading the desired message contents to the DMS. (See Clause ) Set() dmsactivatemessage.0 :DMS dms ActivateMessage.0 is structure containing the following data: -duration, -priority, -message memory type, -message number, -message CRC, -message source address PerformConsistencyCheck() If the response indicates noerror Get() shorterrorstatus.0 See Clause Otherwise Exit Process Get() dmsactivatemsgerror.0 dmsactivateerrormsgcode.0 If dmsactivatemsgerror does not equal syntaxmulti, exit the process. Otherwise, Get() dmsmultisyntaxerror.0 dmsmultisyntaxerrorposition.0 If dmsactivatemessageerror = syntaxmulti(8) and dmsmultisyntaxerror is other(1) Get() dmsmultiothererrordescription.0 Figura 14. Diálogo padrão para a ativação de uma mensagem no PMV. Esses procedimentos de teste têm o seu formato definido pela norma NTCIP Testing and Conformity Assessment Documentation within NTCIP Standards Publications e por sua vez segue as diretrizes da norma IEEE Standard for Software Test Documentation que definem os testes mínimos que deverão ser realizados para verificar a conformidade do equipamento com as normas do NTCIP. 12

13 5.3 Testes Automatizados de Conformidade com NTCIP Em resumo, as normas NTCIP especificam definições de dados comuns e protocolos abertos destinadas a satisfazer as necessidades de comunicação de vários dispositivos nas estradas e centros de gerenciamento de tráfego (NTCIP 9001 v0406). Adicionalmente, a norma documenta as várias atividades/procedimentos para avaliar a conformidade com o padrão NTCIP. Como explicitamos anteriormente, a aplicação dos testes de forma manual pode ser demasiadamente exaustiva e suscetível a falhas humanas. Assim, se for automatizado o processo como descrito na seção 4.2, obtém-se para a verificação de conformidade com os protocolos NTCIP, as mesmas vantagens apresentadas no estudo de caso da seção 4. Para tanto, o IPT está desenvolvendo testes de conformidade de equipamentos de ITS ao NTCIP, similares ao estudo de caso apresentado, usando TTCN-3. Até o momento, foram implementados 189 Test Cases para homologação de conformidade do equipamento PMV (Painel de Mensagens Variáveis) que estará completo em fevereiro de Na Figura 15, pode-se observar um Test Case padronizado na NTCIP 1203 v0239. Figura 15. Exemplo de Test Case padronizado, definido na norma do NTCIP. 13

14 6 CONSIDERAÇÕES FINAIS Dada a evolução tecnológica dos últimos 10 anos, o aumento do número de concessões rodoviárias, a necessidade de maior interoperabilidade entre equipamentos e menor custo total de propriedade dos sistemas inteligentes de transportes, houve um movimento normativo por parte das agências reguladoras de transporte, tanto a nível nacional, quanto internacional. Este movimento, materializado pela resolução n A da ANTT, de 18 de novembro de 2009, normatizou a aquisição e fornecimento de sistemas de ITS em território nacional. Desta forma, ao utilizar uma norma aberta internacional, é obtida uma segurança tanto para o comprador na forma de independência de fornecedor e interoperabilidade de equipamentos e sistemas, quanto para o fornecedor que viabiliza sua atuação no mercado internacional. Além disso, a norma possibilita a evolução tecnológica, ao mesmo tempo em que mantém a compatibilidade com sistemas NTCIP de versões anteriores. A conformidade com a norma NTCIP viabiliza a escalabilidade e confiabilidade do sistema e, consequentemente, diminui o custo total de propriedade para as concessionárias. Esta racionalização de custos pode ser repassada para o usuário final das rodovias. Neste contexto, existe a necessidade de órgãos independentes para avaliação profunda e detalhada de conformidade com a norma, mas de forma expedita. Atualmente, existe um mercado reprimido que necessita destes serviços não apenas para ITS, mas para outros equipamentos da área de energia (Smart Grid), telecomunicações (padrões da Internet do Futuro ), automotiva (computação embarcada). Consequentemente, existe espaço para atuar no desenvolvimento de novos sistemas e equipamentos, com eventuais ganhos de escala, ao abrir novos mercados de atuação para fornecedores nacionais, permitindo aumento de confiabilidade e melhoria contínua de produtos. Nos últimos três anos, os autores examinaram diversas soluções de mercado para avaliações de conformidade. Essa experiência demonstrou que o ponto fraco destas soluções era padecer com a falta de automatização, uma vez que se baseavam em um processo manual bastante interativo com as ferramentas. Este artigo teve como objetivo primordial introduzir os conceitos da metodologia de TTCN-3 aplicada ao contexto da homologação de equipamentos de ITS de acordo com as normas NTCIP integrados a um sistema inteligente de transportes. O TTCN-3 mostrou-se uma metodologia promissora devido a sua flexibilidade para a montagem de todo o conjunto de Test Cases estabelecidos em norma para cada tipo de equipamento. Além disso, possui flexibilidade ao permitir o desenvolvimento de testes de conformidade de acordo com as normas e regras de negócio específicas da empresa. REFERÊNCIAS BIBLIOGRÁFICAS ANTT. (18 de novembro de 2009). Resolução Nº A. Resolução, Agência Nacional de Transportes Terrestres, Brasilia. ETSI, European Telecommunications Standards Institute. (2010). ES TTCN-3 Graphical Presentation Format. European Telecommunications Standards Institute. ETSI. (2010). ES TTCN-3: Core Language. European Telecommunications Standards Institute. ETSI. (2010). ES TTCN-3 Documentation Comment Specification. European Telecommunications Standards Institute. ETSI. (2010). ES TTCN-3 Runtime Interface. European Telecommunications Standards Institute. ETSI. (2010). ES TTCN-3 Control Interface. European Telecommunications Standards Institute. Faria, N. M. (2008). Metodologia de Teste para Sistemas com DRM. Porto - Portugal: Faculdade de Engenharia da Universidade do Porto. 14