- 03 U UNIVERSIDADE ESTADUAL PAULISTA Faculdade de Ciências e Tecnologia Graduação em Engenharia Cartográfica LUIZ FERNANDO ANTONIO DALBELO

Transcrição

1 2 unesp - 03 U UNIVERSIDADE ESTADUAL PAULISTA Faculdade de Ciências e Tecnologia Graduação em Engenharia Cartográfica LUIZ FERNANDO ANTONIO DALBELO DGPS EM REDE: DESENVOLVIMENTO E IMPLANTAÇÃO VIA INTERNET UTILIZANDO A REDE GNSS DO ESTADO DE SÃO PAULO Presidente Prudente Fevereiro/2010

2 LUIZ FERNANDO ANTONIO DALBELO DGPS EM REDE: DESENVOLVIMENTO E IMPLANTAÇÃO VIA INTERNET UTILIZANDO A REDE GNSS DO ESTADO DE SÃO PAULO Dissertação apresentada ao Programa de Pós-Graduação em Ciências Cartográficas da Faculdade de Ciências e Tecnologia da Universidade Estadual Paulista, para obtenção do título de Mestre em Ciências Cartográficas. Orientador: Dr. João Francisco Galera Monico Co-orientadores: Dr. Milton Hirokazu Shimabukuro e Dra. Daniele Barroca Marra Alves Presidente Prudente Fevereiro/2010

3 4 D139d Dalbelo, Luiz Fernando Antonio. DGPS em Rede : Desenvolvimento e Implantação Via Internet Utilizando a Rede GNSS do Estado de São Paulo / Luiz Fernando Antonio Dalbelo. - Presidente Prudente : [s.n], f. : il. Dissertação (mestrado) - Universidade Estadual Paulista, Faculdade de Ciências e Tecnologia Orientador: João Francisco Galera Monico Banca: João Francisco Galera Monico, Eno Darci Saatkamp, Eniuce Menezes de Souza Inclui bibliografia 1. DGPS em Rede. 2. Ntrip. 3. DGPS Via Internet I. Autor. II. Título. III. Presidente Prudente - Faculdade de Ciências e Tecnologia. CDD(18.ed.) Ficha catalográfica elaborada pela Seção Técnica de Aquisição e Tratamento da Informação Serviço Técnico de Biblioteca e Documentação - UNESP, Câmpus de Presidente Prudente.

4 5

5 6 RESUMO Atualmente é cada vez mais presente na comunidade civil a utilização do Global Positioning System (GPS). Um dos métodos de posicionamento GPS de grande destaque é o Differential GPS (DGPS). Esse método utiliza dois receptores, um como base e outro como móvel. O DGPS tem como princípio básico considerar a alta correlação dos erros provocados pela ionosfera, troposfera e órbita dos satélites. No entanto, com o afastamento entre o usuário e a estação base, a eficiência do método diminui, pois a correlação dos erros é reduzida. Mas, quando se utiliza uma rede de estações de referência, pode-se ter uma melhor modelagem dos erros na área de abrangência da rede. Surge então o conceito de DGPS em Rede (DGPSR). Alguns experimentos realizados com o DGPSR em modo pós-processados apontaram acurácia da ordem de 50 cm. Portanto, nesta pesquisa foi proposta a implementação do DGPSR em tempo real. As correções DGPSR são calculadas em tempo real por meio dos dados obtidos via Internet utilizando o protocolo Ntrip (Networked Transport of RTCM via Internet Protocol). Para isso, foram introduzidas várias alterações no software BNC, software este que foi desenvolvido pelo BKG e realiza a função do NtripClient. No que concerne às estações de referência GPS, foram utilizados dados da rede GNSS do oeste do estado de São Paulo (Rede GNSS/SP). A rede está composta, até o momento, por 10 receptores de alta tecnologia que podem ser conectados diretamente a Internet. Com relação aos resultados pode-se observar que o DGPSR utilizando 4 estações de referência apresentou melhorias de até 32% em planimetria e de 28% em altimetria, quando comparados ao DGPS utilizando somente uma estação de referência. Com relação a avaliação da latência pode-se verifica que latências de até 12 segundos parecem não causar influência nos resultados. Palavras chave: Posicionamento GPS; Erros Atmosféricos; DGPS em rede; Comunicação via internet; Ntrip.

6 7 ABSTRACT Nowadays, the Global Positioning System (GPS) has been very used by the civil community. One of the GPS positioning methods that have been emphasized is the Differential GPS (DGPS). In this method, two receivers are used. One of them as base and the other as rover station. The DGPS has the basic concept of considering high correlation of the errors caused by ionosphere, troposphere and satellite orbits. However, with the baseline growth the method efficiency decreases, because the errors correlation is reduced. But, using a reference station network it is possible to obtain an error modeling in the area of the network, using the network DGPS concept. Some experiments accomplished with DGPSR post processed mode presented promising results. Accuracy better than 50 cm was obtained. Therefore, in this research the goal is to implement the DGPS in real time. The corrections will be computed through data received by Internet using the Ntrip (Networked Transport of RTCM via Internet Protocol). In order to accomplish that, it was implemented several modifications in the BNC software. This software was developed by BKG and make the function of a NtripClient. It will be used a GPS network that is set up in the west of São Paulo State. This network is composed by 10 receivers of high technology that can be directly connected by Internet. Regarding the results, the DGPSR using 4 reference stations showed improvements of up to 32% in planimetry and 28% in altimetry when compared to pure DGPS. Regarding the assessment of latency it was noted that latencies of up to 12 seconds seems not to cause influence the results. Keywords: GPS positioning; Network DGPS; Atmospheric Effects, Internet communication; Ntrip.

7 8 LISTA DE SIGLAS API ASCII ARP CRC CRN DGPS DGPSR FE GNSS GPS GLONASS GALILEO GAGAN HTTP IGU IGS INCRA IBGE IODE IDSAT ITRF IETF IP LGE LSB MSBAS MSB MJD Ntrip P2P PDA RADGPS Application Programming Interface American Standard Code for Information Interchange Antenna Reference Point Cyclic Redundancy Ckeck Carrier-to-Noise Ratio Differential GPS DGPS em Rede Fator de Escala Global Navigation Satellite System Global Positioning System Global Navigation Satellite System European Satellite Navigation System GPS Aided Geo Augmented Navigation Hypertext Transfer Protocol UltraRapid Predicted Orbit) International GNSS Service Instituto Nacional de Colonização e Reforma Agrária Instituto Brasileiro de Geodésia e Estatística Issue of Data Ephemeris Identificação do Satélite International Terrestrial Refece Frame Internet Engineering Task Force Internet Protocol Laboratório de Geodésia Especial Last Significant Bit Multi- Funcional Satellite Augmentation System Most Significant Bit Dia Juliano Midicado Networked Transport of RTCM via Internet Protocol Peer-to-peer Personal Digital Assistants Regional Area

8 9 RTCM RTK SBAS SMTP SA TCP UDRE UDP UGF VHF WADGPS Radio Technical Commission for Maritime Services Real Time Kinematic Space Based Augmentation Systems Simple Mail Transfer Protocol Selective Availability Transmission Control Protocol User Differential Range Error User Datagram Protocol Ultra High Frequency Very High Frequency Wide Area DGPS

9 10 DADOS CURRICULARES Luiz Fernando Antonio Dalbelo NASCIMENTO: 13/06/ Parapuã - SP FILIAÇÃO: Arcângelo Aparecido Dalbelo Iria Helena Bissolli Dalbelo : Graduação Engenharia Cartográfica Faculdade de Ciências e Tecnologia - UNESP : Pós-Graduação Mestrado em Ciências Cartográficas Faculdade de Ciências e Tecnologia UNESP

10 11 Aos meus amados e estimados pais, Arcangelo Aparecido Dalbelo e Iria Helena Bissoli Dalbelo, fundação para minha vida, força e apoio em minha caminhada durante todas as etapas de minha vida. A minha amada noiva e, muito em breve, esposa, Ened Camila Hanamoto Silva, que minha inspiração, minha companheira para todos os momentos em que precisei. A minha irmã, Thais, pela amizade e força de uma irmã muito dedicada em minha caminhada.

11 12 AGRADECIMENTOS Desejo externar os meus sinceros agradecimentos a todos que colaboraram com o desenvolvimento desse trabalho, em especial: A Deus, que sempre me guiou pelos melhores caminhos, pois sem sua ajuda não conseguiria seguir em frente para alcançar meus objetivos. Ao meu orientador Dr. João Francisco Galera Monico pela contribuição no desenvolvimento dessa pesquisa, pela confiança e amizade. Ao Dr. Milton Hirokazu Shimabukuro, meu co-orientador, pelo enorme auxílio durante a implementação do software, no entendimento de vários problemas de computação, pelos sábados inteiros de estudos em conjunto e logicamente pela amizade estabelecida. A Dra. Daniele Barroca Marra Alves, minha co-orientadora ( a fera ), não só pela grande contribuição em minha pesquisa, mas também pelo enorme apoio dado em momentos difíceis pela minha passagem na UNESP e pela grande amizade durante estes bons momentos. Aos professores do Departamento de Cartografia e aos funcionários da FCT que de forma direta ou indireta contribuíram no desenvolvimento dessa Dissertação. Ao Dr. Eno e a Dra. Eniuce Menezes de Souza, membros da banca examinadora pelas contribuições dadas na fase final desse pesquisa. Aos amigos do PPGCC e da FCT/UNESP, pelas contribuições e ajudas. Ao grande animador e contador de piadas o nosso grande amigo, o Gaúcho (Marcelo Holzschuh). A meu grande amigo e companheiro de toda hora, o Wesley, aos inestimáveis amigo de republica João Pualo (o JP), Luís (o falante), o Goiano e o Filipe. Aos alunos do GEGE e grandes amigos que também contribuíram de alguma forma: Wesley Sato e Jackson. O meu primo e também amigo Fazan, programador exímio que muito me ajudou. Um especial agradecimento e estima a Eniuce, Lauri, Letícia, Guilherme, RCris e Willian. Não poderia me esquecer do GPSR (O Poli), pessoa simples e sincera e do Mario Reiss, um amigão. Aos familiares e demais amigos que sempre me incentivaram e acreditaram em mim. Ao Conselho Nacional de Desenvolvimento Científico e Tecnológico - CNPQ, pelo auxílio financeiro nessa pesquisa, sob forma de bolsa de demanda social.

12 2 LISTA DE FIGURAS Figura 01 Conceito do DGPS...15 Figura 02 Interpolação por ponderação de distância...21 Figura 03 Duas primeiras palavras de cada quadro da mensagem RTCM versão Figura 04 Mensagem tipo 1 do RTCM versão Figura 05 Codificação dos bits a serem transmitidos...31 Figura 06 Algoritmo de paridade...32 Figura 07 Mensagem tipo 1 ASCII do RTCM versão Figura 08 Decodificação da primeira palavra da mensagem tipo Figura 09 Conteúdos das mensagens 1001 e 1002 para um satélite específico...41 Figura 10 Esquema de representação da pseudodistância em mili-segundos da velocidade da luz...42 Figura 11 Conteúdos das mensagens 1005 e Figura 12 Conteúdos das mensagens 1007 e Figura 13 Formato geral de uma mensagem de requisição HTTP Figura 14 Padrão URL...57 Figura 15 Mensagem HTTP de requisição...59 Figura 16 Formato geral de uma mensagem de resposta HTTP...59 Figura 17 Mensagem HTTP de resposta Figura 18 Distribuição de dados por Ntrip Figura 19 - Configuração da rede GNSS/SP Figura 20 - DGPSR via Internet Figura 21 - DGPSR via Internet Figura 22 Configuração das estações utilizadas e comprimento das linhas de base Figura 23 Resultados do DGPSR para as 4 configurações adotadas dia 02 de fevereiro..75 Figura 24 Latência calculada para as quatro estações base utilizadas na configuração R4- dia Figura 25 - Resultados do DGPSR para as 4 configurações adotadas dia 03 de fevereiro..77 Figura 26 - Latência calculada para as quatro estações base utilizadas na configuração R4- dia Figura 27 Erro Médio Quadrático das discrepâncias para o dia 02 e 03 de fevereiro...79

13 3 LISTA DE TABELAS Tabela 01 Tipos de Mensagem RTCM versão Tabela 02 Informações contidas nas duas primeiras palavras de cada mensagem...25 Tabela 03 Indicador de saúde da estação de referência...26 Tabela 04 Informações contidas na mensagem do tipo 1 para cada satélite Tabela 05 - Fatores de escala das correções diferenciais Tabela 06 UDRE Tabela 07 Grupos de mensagens Tabela 08 Cabeçalho das mensagens RTCM Tabela 09 Conteúdo da mensagem Tabela 10 Estrutura do formato RTCM versão Tabela 11 RTCM versão 3.0 versus versões anteriores...50 Tabela 12 - Camadas da Internet Tabela 13 - Comparação entre UDP e TCP...62 Tabela 14 Configuração das redes utilizadas nos experimentos Tabela 15 Distância entre as estações base e estação móvel...73 Tabela 16 EMQ para os 4 configurações utilizadas dia Tabela 17 EMQ para os 4 configurações utilizadas dia Tabela 18 Valores em diferentes bases de contagem....91

14 4 SUMÁRIO 1 INTRODUÇÃO Caracterização do Assunto Objetivos Justificativa Conteúdo da dissertação GPS DIFERENCIAL Pseudodistância Conceitos básicos do DGPS Cálculo das correções das pseudodistâncias Cálculo do erro do relógio do receptor Cálculo das coordenadas do satélite no instante de transmissão do sinal Utilizando as correções DGPS em rede Interpolação das correções diferenciais para posição da estação móvel O PADRÃO RTCM RTCM Algoritmo de Paridade e Decodificação da Mensagem Tipo Algoritmo de Paridade Decodificação das mensagens RTCM RTCM Camada de Aplicação Camada de Apresentação Camada de Transporte Camada de Enlace dos Dados Camada Física RTCM 2.3 Versus RTCM COMUNICAÇÃO VIA INTERNET E O PROTOCOLO NTRIP Comunicação Via Internet Camada de Aplicação Camada de Transporte Camada de Rede Camada de enlace Camada física Ntrip DADOS UTILIZADOS E METODOLOGIA EMPREGADA Rede GNSS/SP Metodologia Empregada EXPERIMENTOS E ANÁLISE DOS RESULTADOS CONSIDERAÇÕES FINAIS E RECOMENDAÇÕES Considerações finais Recomendações para trabalhos futuros REFERÊNCIAS BIBLIOGRAFICAS...84

15 5 1 INTRODUÇÃO 1.1 Caracterização do Assunto O Global Navigation Satellite System (GNSS) integra vários sistemas de posicionamento por satélites existentes como o Global Positioning System (GPS), o Global Navigation Satellite System (GLONASS), e num futuro próximo o European Satellite Navigation System (GALILEO) e o Beidou 2/Compass da China. Estes sistemas têm como principal objetivo viabilizar a navegação de baixa, média e alta precisão. Hoje em dia existem vários sistemas adicionais em operação, que estão disponíveis para complementar o GPS, o GLONASS e o GALILEO. Estes sistemas são genericamente denominados de Space Based Augmentation Systems (SBAS), os mesmos transmitem sinais extras que certos receptores (GNSS) podem decodificar e utilizar juntamente com os sinais GNSS para obter melhor desempenho no posicionamento (ENGEL; HEISER, 2004). Dentre os sistemas de posicionamento que integram o GNSS, o GPS tem grande destaque. Várias técnicas de posicionamento têm sido desenvolvidas para explorar a capacidade que o GPS possui em prover coordenadas precisas com um pequeno intervalo de tempo de coleta de dados, ou até mesmo quando o receptor está se movendo ao longo de uma trajetória. Pode-se citar o posicionamento por ponto estático ou cinemático e o relativo estático, estático rápido, semi-cinemático ou cinemático (MONICO, 2007; SEEBER, 2003). Uma das diferenças entre o posicionamento estático e o cinemático refere-se à acurácia factível de ser obtida em cada um deles. Segundo Seeber (2003), no posicionamento GPS estático os erros aleatórios de medição são absorvidos pelos resíduos após o ajustamento, enquanto no posicionamento cinemático a maior parte dos erros aleatórios é absorvida pelas coordenadas. Um dos métodos de posicionamento que tem se destacado desde a concepção do sistema GPS é o Differential GPS (DGPS GPS Diferencial). No DGPS tem-se como principio básico assumir uma alta correlação dos erros (ionosfera, troposfera e órbita dos satélites) em uma determinada área de abrangência. Este método envolve o uso de dois receptores, sendo que um fica instalado sobre uma estação base que possui suas coordenadas conhecidas e o outro receptor (móvel/usuário) percorre os pontos de interesse. Conhecendo-se a posição da estação base pode-se calcular correções que são enviadas para

16 6 o usuário e aplicadas nas observações do mesmo obtendo-se assim uma melhor de acurácia no posicionamento. Este método foi desenvolvido inicialmente com o intuito de minimizar o efeito da Selective Availability (SA). O SA tratava-se de um programa que manipulava as efemérides transmitidas pelos satélites e desestabilizava sistematicamente os osciladores dos satélites, o que provocava uma degradação no posicionamento para usuários GPS não autorizados (MONICO, 2007). Com a desativação do SA, a precisão do posicionamento obtido com o DGPS foi melhorada. O DGPS tem sido utilizado em diversas aplicações como: navegação, levantamentos, atividades de engenharia, locação, agricultura de precisão, etc. Esse tipo de posicionamento pode ser realizado utilizando como observáveis as pseudodistâncias ou as pseudodistâncias filtradas pela portadora. Além disso, no DGPS os dados podem ser processados em tempo real, bem como após a coleta de dados (pós-processamento). Outro ponto que deve ser destacado é que devido à decorrelação espacial dos erros (ionosfera, troposfera e órbita dos satélites), a distância entre a estação de referência e o usuário é limitada, dependendo principalmente das condições da ionosfera (SEEBER, 2003). De acordo com Seeber (2003), o DGPS proporciona, em geral, acurácia de 1 a 3 m. Usualmente, para que se tenha um desempenho razoável, a área de cobertura é de aproximadamente 150 km (PARKINSON; ENGE, 1996). Porém, segundo Monico (2007), para algumas condições um afastamento de até 1000 km pode mostrar resultados com precisão em um intervalo de 1 a 10 m. Dessa forma, quando uma melhor acurácia é requerida no posicionamento DGPS uma modelagem dos erros causados pela troposfera, ionosfera e órbita dos satélites se torna indispensável. Em função dessa necessidade, surgiu o Wide Area DGPS (WADGPS), que ao invés de produzir uma correção escalar para cada pseudodistância observada, proporciona um vetor de correções, para cada satélite, composto dos erros das efemérides e do relógio, além dos parâmetros inerentes a refração ionosférica e troposférica. No entanto, o WADGPS, muitas vezes, é um serviço pago, com custo elevado (KEE, 1996). Além disso, o WADGPS é um sistema desenvolvido e implementado para os Estados Unidos. Assim, devido ao fato de que as correções calculadas por esse sistema são obtidas a partir de estações de referência situadas no território dos EUA, as mesmas não representariam reais correções em outras regiões do globo terrestre.

17 7 Os sistemas atualmente denominados por SBAS seguem basicamente o princípio do WADGPS. Alguns dos sistemas mais conhecidos que emitem sinais com correções para melhorar o posicionamento GPS são: o sistema dos Estados Unidos denominado Wide Area Augmentation System (WAAS), o Europeu denominado por European Geostationary Navigation Overlay System (EGNOS), o sistema indiano GPS Aided Geo Augmented Navigation (GAGAN) e o japonês Multi- Funcional Satellite Augmentation System (MSAS) (DEMPSTER e HEWITSON, 2007). Estes sistemas basicamente utilizam uma rede de estações de receptores GNSS e, com base no conhecimento das posições precisas destes receptores, pode-se calcular correções (órbita dos satélites, relógio dos satélites, ionosféricas e troposféricas). Estas correções são enviadas para satélites geoestacionários que por sua vez transmitem estes dados para os receptores GNSS, os quais as utilizam para obter uma melhor acurácia no posicionamento. Além disso, os satélites geoestacionários emitem sinais similares aos do GPS que também podem ser utilizados para realizar posicionamento (KOWOMA, 2006). Nessa pesquisa é abordado o DGPS em Rede, algumas vezes denominado na literatura de Regional-Area DGPS (RADGPS DGPS para uma Área-Região) (KAPLAN & HEGARTY, 2006). Neste texto essa técnica será denominada DGPS em Rede (DGPSR). Essa dissertação é continuação da pesquisa de Iniciação Científica desenvolvida pelo autor, na qual foi implementado o DGPS, o DGPS em uma nova abordagem e o DGPSR, modo pós-processado. Vários experimentos foram realizados para testar o software desenvolvido para esses diferentes métodos. No que concerne ao DGPS, em um dos experimentos realizados, com uma linha de base de 430 km, a acurácia obtida na determinação da posição da estação móvel foi de aproximadamente 3 m (DALBELO, 2005a, 2005b, 2005c). Na nova abordagem do DGPS foram utilizadas as efemérides IGU (UltraRapid Predicted Orbit) fornecidas pelo IGS (International GNSS Service), o modelo de Previsão Numérica do Tempo (PNT) para corrigir os erros de troposfera (SAPUCCI et al, 2003) e o modelo de ionosfera (Mod_Ion) para corrigir os erros provocados pela ionosfera (CAMARGO, 1999; MATSUOKA, 2003; AGUIAR 2005). Utilizando as efemérides precisas e aplicando as correções atmosféricas obteve-se uma acurácia de 1,9 metros na determinação da posição da estação móvel, o que representa uma melhoria de 36,6% com relação ao DGPS convencional (DALBELO, 2005c).

18 8 Em se tratando do DGPS em rede os resultados obtidos apresentaram discrepâncias menores que 50 cm, as quais representam melhorias de até 66,9 % na acurácia da componente planimétrica e 56% para a componente altimétrica quando comparado com o DGPS (DALBELO, 2006a). Com este nível de precisão o DGPS em rede atende à lei 10267/2001 de georreferenciamento de imóveis rurais, que vem sendo muito discutida atualmente pela comunidade cartográfica (BRASIL, 2001; 2002). Em virtude desta e outras demandas o Instituto Nacional de Colonização e Reforma Agrária (INCRA) adquiriu, em parceria com o Instituto Brasileiro de Geodésia e Estatística (IBGE), e instalou, recentemente mais de 80 receptores GPS/GNSS (estações de referência de dupla freqüência) por todo o Brasil. Além disso, foi implantada no estado de São Paulo uma rede GNSS equipada com receptores de alta tecnologia que são ligados diretamente a Internet. A rede é formada por 10 receptores que foram adquiridos pela FCT/UNESP por meio de dois projetos financiados pela FAPESP (Auxílio a Pesquisa - Processo 04/03384 e Programa de Equipamentos Multiusuário Processo 04/ ). Atualmente, esses 10 receptores já estão em funcionamento. Como os receptores podem ser conectados diretamente à Internet, existe a possibilidade de gerenciá-los à distância e seus dados podem ser acessados em tempo real via Internet. A central de controle dessa rede é o Laboratório de Geodésia Espacial (LGE) da UNESP de Presidente Prudente. É importante acrescentar que nos últimos anos, com o avanço da Internet, da infra-estrutura de comunicação disponível para o público em geral (rede para celulares, por exemplo) e da tecnologia dos receptores GPS, muitas pesquisas têm sido desenvolvidas para a utilização da Internet na realização do DGPS e do DGPSR. A Internet funciona como um link para a transmissão das correções para os usuários (KECHINE; TIBERIUS; VAN DER MAREL; 2003; HADA et al, 1999; YAN, 2006). Atualmente, tem-se utilizado o protocolo de Internet denominado de Networked Transport of RTCM via Internet Protocol (Ntrip) para disseminar dados GNSS pela Internet. Esse protocolo foi desenvolvido pela Federal Agency for Cartography and Geodesy juntamente com a Universidade de Dortmund e a Trimble Terrasat GmbH. Este protocolo foi implementado com o intuito de substituir a transmissão via rádio, que muitas vezes é limitada pela distância entre as estações (LENZ, 2004; WEBER, GEBHARD e KALAFUS, 2005). Assim, nesse projeto serão abordados os conceitos de Internet bem como a comunicação via Internet, os formatos RTCM, utilizado no Ntrip, além dos conceitos de

19 DGPS e DGPSR. Esses, conceitos serão de fundamental importância pois servirão de base para a implementação do DGPSR em tempo real via Internet Objetivos O objetivo principal deste projeto é implementar o DGPSR em tempo real utilizando o protocolo NTRIP para transmissão das correções via Internet. Além da implementação do DGPSR pretende-se gerar informações a respeito da latência sofrida pelo dados utilizando a Internet como meio de comunicação e avaliar sua influência na qualidade do posicionamento que será realizado. Finalizando, a realização dessa pesquisa tem o objetivo de contribuir de forma significativa com o desenvolvimento científico e tecnológico nacional, visto que o DGPSR tem sido utilizado em inúmeras aplicações e apenas softwares comerciais de alto custo estão disponíveis para esse tipo de posicionamento. 1.3 Justificativa Nos dias atuais é cada vez maior o interesse de se realizar posicionamento em um curto período de rastreio e que proporcione uma acurácia razoável. Além disso, a rede ativa do Estado São Paulo tornará viável a implantação no futuro do Serviço DGPSR de forma efetiva para comunidade usuária, pois esta rede possui receptores com capacidade de conexão direta à Internet e característica que facilita a emissão dos dados das mesmas via Internet. Deste modo, o desenvolvimento de um sistema DGPSR que disponibilize correções para os usuários em tempo real pode ser de grande valia para a comunidade usuária e/ou científica. Visto que os usuários deste serviço necessitarão apenas de receptores GPS de simples freqüência (muito mais barato que os receptores de dupla freqüência) e poderão realizar o posicionamento de forma rápida e com uma boa acurácia, minimizando custos e obtendo uma maior produtividade nos levantamentos em geral. Este projeto poderá contribuir, por exemplo, com os levantamentos para fins de realizar o georreferenciamento de imóveis rurais, o que é previsto por lei. Assim, este método de posicionamento (DGPS em rede) pode ser futuramente aplicado para a nova rede

20 10 do INCRA que é de abrangência nacional e será integrada a RBMC. Além disso, poderá ser aplicado a diversas outras atividades como: levantamentos em geral, navegação, obras de engenharia, agricultura de precisão, locação, entre outras. Uma outra contribuição importante refere-se ao software que foi desenvolvido. Este software científico tem o seu código aberto de modo que no futuro rotinas implementadas neste software possam ser utilizadas em outros softwares, ou aprimoradas com outros modelos matemáticos. Cabe acrescentar que esta pesquisa contribui com o desenvolvimento e continuidade de pesquisas realizadas na FCT/UNESP, pesquisas estas que são financiadas por projetos FAPESP (Auxílio a Pesquisa - Processo 04/03384 e Programa de Equipamentos Multiusuário Processo 04/ ). 1.4 Conteúdo da dissertação A organização desta pesquisa é descrita a seguir, com o conteúdo de cada capítulo. No capítulo 2 são descritos os aspectos teóricos da técnica de posicionamento DGPS. Para tanto, foi introduzida a descrição da observável utilizada nesta técnica que é a pseudodistância. Ainda neste capítulo são apresentadas seções que tratam da seqüência de cálculos para obtenção das correções diferenciais, como são calculadas as coordenadas dos satélites para o instante de transmissão, os cálculos dos erros do relógio do receptor, a forma que estas correções são aplicadas a pseudodistância da estação móvel, o conceito do DGPSR e como são interpoladas as correções para posição do usuário no DGPSR. O capítulo 3 descreve as versões 2.3 e 3.1 do formato RTCM. Nesse contexto é apresentada uma descrição das principais mensagens, para cada versão, utilizadas no DGPS. O capítulo 4 por sua vez apresenta os conceitos básicos de internet e uma descrição dos protocolos de aplicação o HTTP e o Ntrip. No capítulo 5 apresenta-se a metodologia utilizada para o desenvolvimento dessa pesquisa.

21 11 Com a finalidade de apresentar qual a acurácia esperada para o DGPSR na área de abrangência da Rede do Estado de São Paulo, o capítulo 6 apresenta alguns experimentos realizados com essa rede. Finalmente, no capítulo 7 tem-se as considerações finais dessa pesquisa e recomendações para trabalhos futuros.

22 12 2 GPS DIFERENCIAL Desde o surgimento do GPS, várias técnicas de posicionamento foram desenvolvidas com o intuito de explorar a capacidade que o GPS tem de prover coordenadas precisas sobre a superfície terrestre, ou próximo dela (SEEBER, 1993). A determinação das coordenadas de um objeto com relação a um referencial específico pode ser classificada como posicionamento absoluto (ou posicionamento por ponto), no caso do GPS, quando as coordenadas estão referenciadas diretamente ao geocentro. Quando as coordenadas são determinadas com relação a um referencial materializado por um ou mais pontos de coordenadas conhecidas, trata-se do posicionamento relativo. O que também se leva em consideração é se o objeto a ser posicionado está em repouso (posicionamento estático) ou em movimento (posicionamento cinemático). Assim, o posicionamento pode ser realizado no modo absoluto estático ou absoluto cinemático, ou também, relativo estático ou relativo cinemático (MONICO, 2000; SEEBER, 2003). O DGPS é tratado por alguns autores como posicionamento absoluto e por outros por posicionamento relativo. Mais detalhes desse tipo de posicionamento serão dados na seção 2.2. Segundo Kaplan e Hegarty (2006) o posicionamento diferencial pode ser simplesmente denominado por DGPS, como apresentado anteriormente, ou como Regional- Area DGPS (RADGPS - DGPS para uma área regional) ou como Wide-Area DGPS (WADGPS DGPS para uma Área Ampla). Essas técnicas serão discutidas nesse capítulo. Nessa dissertação o RADGPS é denominado por DGPS em rede, ou simplesmente, DGPSR. Para essas três variações do DGPS a observável básica é a pseudodistância ou pseudodistância filtrada pela portadora. No entanto, o método que utiliza somente as pseudodistâncias é o mais empregado na prática (MONICO, 2000). Portanto, na seção 2.1 serão descritas as principais características da observável pseudodistância. Cabe ressaltar que as pseudodistâncias contêm erros como: refração troposférica, efeitos ionosféricos, erros do relógio do satélite e do receptor, erro nas órbitas dos satélites GPS e multicaminho. No que concerne ao multicaminho, assume-se que a estação de referência foi implantada em local com o mínimo desse efeito, ou calibrada

23 através de técnicas apropriadas (SOUZA, 2004). E que os demais erros são minimizados no processo de diferenciação (ver seção 2.2) Pseudodistância A medida da pseudodistância é obtida a partir da correlação entre o código gerado pelo satélite no instante de transmissão (t s ) e sua replica gerada no receptor no instante de recepção (t r ). O termo pseudodistância é usado em virtude do nãosincronismo entre os relógios responsáveis pela geração do código no satélite e sua replica no receptor (LEICK, 1995). Vários fatores acarretam erros na determinação da pseudodistância, como por exemplo: erros dos relógios do satélite e do receptor, refração troposférica, efeitos ionosféricos, multicaminhamento, erro da órbita do satélite, etc. A equação que fornece a pseudodistância entre o satélite e o receptor na época t, é dada por (GIZAWY, 2003; OLYNIC, 2002): s r s r s s s s s ( dtr dt ) + Ir + Tr + dmr + d r + s PD r PD ( t) = ρ ( t) + c ρ, (2.1) onde: ρ s (t) - distância geométrica entre o receptor no instante de recepção do sinal e o satélite r no instante de transmissão, em metros; c - velocidade da luz no vácuo, m/s; dt r - erro do relógio do receptor em relação ao tempo GPS no instante de recepção, em segundos; s dt - erro do relógio do satélite em relação ao tempo GPS no instante de transmissão, em segundos; s I r - erro causado pela refração ionosférica, em metros; s T r - erro causado pela refração troposférica, em metros; s dm r - erro causado pelo multicaminho, em metros; s dρ r - erro causado pela órbita do satélite, em metros; s - erro da pseudodistância devido aos efeitos não modelados e aleatórios. PD r

24 Conceitos básicos do DGPS O DGPS foi desenvolvido inicialmente com o intuito de reduzir os efeitos provocados pela Selective Availability (SA). É uma técnica usada para melhorar a posição do usuário através da aplicação de correções provindas de uma estação GPS de rastreamento contínuo, chamada estação de referência ou estação base (estação de coordenadas conhecidas). Essas correções podem ser enviadas ao usuário através de um link de rádio (Figura 01) (SEEBER, 2003). Atualmente protocolos de Internet estão sendo utilizados na transmissão dos dados GNSS, o que será discutido no capítulo 4. Diferentes procedimentos podem ser utilizados para a geração das correções, como (SEEBER, 2003): Correções na posição a posição da estação de referência derivada do GPS é comparada com sua posição considerada verdadeira. As correções da posição em coordenadas cartesianas X, Y, Z ou geodésicas ϕ, λ e h, são transmitidas e utilizadas para corrigir a posição do receptor móvel. No entanto, essa técnica tem deficiências, tal como o fato de requerer que a estação base e a estação móvel estejam coletando os mesmos satélites para assegurar que as diferenças em posição expressem melhor os erros envolvidos (KAPLAN e HEGART, 2006; SEEBER, 2003). Correções na pseudodistância as pseudodistâncias observadas (arquivos de observação) de todos os satélites visíveis são comparadas com as calculadas a partir das coordenadas da estação base e dos satélites. As diferenças e suas variações são transmitidas para o receptor móvel para corrigir as pseudodistâncias observadas (seção 2.2.4). No entanto, devido à decorrelação dos erros (ionosfera, troposfera e órbita), quando o receptor móvel se afasta da estação de referência, a acurácia decresce aproximadamente 1m para cada 100 km.

25 15 Figura 01 Conceito do DGPS No caso das correções na pseudodistância, o cálculo é feito da seguinte forma: a partir das órbitas dos satélites GPS (calculadas através dos dados emitidos pelos satélites, efemérides transmitidas) e as coordenadas da estação base (conhecidas), faz-se o cálculo da distância geométrica entre a estação base e o satélite para um determinado instante. Assim, com a diferença entre as distâncias calculadas e as pseudodistâncias contidas no arquivo de observação, e considerando também o erro do relógio do receptor que é diferente para a estação base e a estação móvel, tem-se a correção que será enviada ao receptor móvel. O DGPS é uma técnica cujo processamento geralmente é realizado em tempo real, pois atrasos na obtenção dos resultados podem ocorrer devido ao intervalo de tempo de envio das correções da base para a estação móvel. Neste texto para simplificarmos vamos chamar simplesmente de tempo real. O processamento dos dados após a coleta pode ser realizado sem problemas. No processamento em tempo real, as correções devem ser enviadas para o receptor móvel com suas respectivas variações, pois existe uma latência, ou seja, um atraso das correções devido ao tempo de envio das mesmas (HOFMANN-WELLENHOF, LICHTENEGGER e COLLINS, 1997). A taxa de atualização das correções depende diretamente da capacidade que a estação base tem de realizar o posicionamento absoluto, a partir do qual se obtém os

26 16 erros do relógio do receptor, e gerar as correções (onde são utilizados os erros do relógio do receptor base) e suas respectivas taxas de variação (POZ et al., 2003). A variação temporal diz respeito à latência das correções diferencias, ou seja, é o intervalo de tempo decorrido desde o instante em que foram geradas as correções até o instante em que são utilizadas no cálculo da posição da estação móvel (BRIONES e KUEGUER, 1999). A latência depende das características do sistema que realiza os cálculos, do controle e envio das correções por um sistema de transmissão. A taxa de transmissão dada em bits por segundo (bps) depende da capacidade que o sistema de comunicação tem de transferir os dados da estação base para a estação móvel (SAATKAMP e KRUEGER, 2002). Deste modo, quanto maior for a taxa de transmissão menor será a latência. Segundo Parkinson e Enge (1996) se as correções forem aplicadas a pseudodistância da estação móvel, com uma latência de até 10 segundos, os erros comuns as duas estações serão praticamente eliminados, proporcionando uma precisão de 1m (1 sigma) num raio de 50 km. No entanto, Dal Poz et al. (2003) apresentam experimentos para distâncias curtas em que latências maiores que 10 segundos (de 20 a 90 segundos) não influenciam nos resultados. Isso mostra que a desativação do SA acarretou em uma lenta variação dos erros, o que permite uma diminuição da taxa de atualização das correções sem prejudicar os resultados do posicionamento com o DGPS. Como mencionado anteriormente, em se tratando das correções na pseudodistância, pode-se utilizar a observável original ou a filtrada pela portadora. Quando as pseudodistâncias originais são utilizadas, o posicionamento DGPS proporciona, geralmente, acurácia de 1 a 3 m. Já no caso onde as pseudodistâncias são filtradas pela portadora, o posicionamento DGPS pode alcançar acurácia submétrica (SEEBER, 2003). Usualmente, a área de cobertura para que se tenha um bom desempenho é de aproximadamente 150 km (PARKINSON e ENGE, 1996). Porém segundo Monico (2007) para algumas aplicações um afastamento de até 1000 km pode mostrar resultados adequados, com acurácia entre 1 a 5m.

27 Cálculo das correções das pseudodistâncias s ( I ) r s A partir dos termos referentes aos erros de troposfera ( T ) r, ionosfera s, que serão considerados nesse texto como parte dos erros residuais ε r, erro do relógio s do satélite ( i ) dt e o erro do relógio do receptor dt r (seção 2.2.2), será obtida uma correção i para cada pseudodistância, restando apenas os erros residuais, que é dada por: s s s ( t ) = PD ( t ) ρ ( t ) c( dt i r dt ) p i r i r i i, (2.2) onde t i é o tempo na época especificada. s Na equação (2.2), a pseudodistância calculada ρ r será obtida a partir das coordenadas conhecidas da estação base e das coordenadas dos satélites, isto é ρ S s 2 S s 2 S s ( X ( t ) X ( t )) + ( Y ( t ) Y ( t )) + ( Z ( t ) Z ( t ) 2 s r = B r B r B r ), (2.3) onde: S S S S S S X ( t ), Y ( t ), Z ( t ) - coordenadas do satélite no instante de transmissão do sinal; X t ), Y ( t ), Z ( t ) - coordenadas da estação base no instante de recepção do sinal. B ( r B r B r satélite e do receptor. Além disso, a pseudodistância será corrigida dos erros dos relógios do Portanto, para determinar as correções residuais da pseudodistância, a pseudodistância observada (arquivo de observação) será subtraída da calculada s s s ( ρ c( dt r dt ) + ε ) r +. Em seguida, assim que dados de novas épocas ficarem disponíveis, r o processo será repetido e as variações das correções serão calculadas para serem disponibilizadas aos usuários juntamente com as correções. Logo, obtendo-se as correções p das épocas t i e t i+1, por exemplo, pode-se calcular a variação da correção p& como: ( ti+ 1) p( ti ) ( t t ) p p& = (2.4) i + 1 i

28 18 O próximo passo é tranferir as correções e suas respectivas variações podem ser aplicadas nas pseudodistâncias da estação móvel. Essa correção deverá ser gerada seguindo o formato RTCM SC-104 desenvolvido pela Radio Technical Commission for Maritime Services (RTCM, 2004). Um detalhe que deve-se observar é que as coordenadas dos satélites utilizadas na equação 2.3 devem ser as calculadas no instante de transmissão do sinal. No entanto, o instante de transmissão deve ser determinado por um método iterativo. A seção apresenta o procedimento adotado nesta pesquisa Cálculo do erro do relógio do receptor Para o cálculo do erro do relógio do receptor (dt r ) da estação base (conhecida) pode-se utilizar a equação: PD s r s r s ( dt dt ) = ρ + c, (2.5) r onde: s PD r - pseudodistância medida entre o satélite r e receptor s, obtida nos arquivos de observação, em metros; s ρ r - distância geométrica entre o satélite s no instante de transmissão e o receptor r no instante de recepção, em metros; c - velocidade da luz no vácuo, em m/s; s ε r - erros residuais entre o satélite, no instante de transmissão, e o receptor, no instante de recepção, em metros; segue: Dessa forma, é determinado um valor de dt r para cada observação como dt r = PD s r s ρr + cdt c s (2.6) único valor Em seguida, é calculada a média de todos os valores, obtendo assim um dt r para a época específica, o que irá melhorar sua qualidade.

29 19 dt r n dtr i= = 1 n, (2.7) onde n é o número de observações da época. Ou seja, o número de satélites rastreados Cálculo das coordenadas do satélite no instante de transmissão do sinal pela equação: Uma aproximação inicial para o instante de transmissão pode ser dada t s = t r s ρ r, (2.8) c s onde ρ r é a distância geométrica aproximada entre o satélite, no instante de transmissão, e o receptor no instante de recepção e c é a velocidade da luz no vácuo. transmissão ( s No entanto, para se obter uma melhor aproximação para o instante de t ), deve-se conhecer o intervalo de tempo de progação do sinal ( ) δ do satélite ao receptor, no instante de transmissão e recepção respectivamente, o erro do s relógio do receptor ( dt r i ) e o erro do relógio do satélite ( dt i ), ou seja: t t s r ri si ( dt δ ) = t dt +, (2.9) t onde, t r é o instante de recepção do sinal. Porém, para se obter s δ deve-se conhecer a distância geométrica ( ) t que por sua vez é calculada a partir das coordenadas do satélite. Visto isso, pode-se notar que o processo é iterativo. Como o erro do relógio do receptor é determinado no ajustamento, a partir deste calcula-se um novo instante de transmissão e em seguida faz-se a interpolação das coordenadas do satélite para este novo instante calculado. ρ, Os erros dos relógios dos satélites são gerados pelo IGS e disponibilizados aos usuários via arquivos de efemérides IGU. Esses erros são de melhor precisão que os erros enviados nas efemérides transmitidas. r

30 Utilizando as correções Na concepção do DGPS, o usuário que deseja utilizar as correções da pseudodistância na época t k em relação a época t 0 deverá aplicar a seguinte correção na pseudodistância observada: onde: p( ) t k ( t ) = p( t ) + p( t )( t ) p & (2.10) é a correção a ser aplicada; é a correção na época t 0 ; p( ) t 0 p& ( ) t 0 k 0 0 k t0 é a razão de variação da correção. Em seguida as correções (equação (2.2)) serão aplicadas nas pseudodistâncias observadas da estação móvel. Portanto, na estação móvel, as pseudodistâncias corrigidas (PD corr ) serão dadas por: PD corr s r s ( t ) c( dt r dt k ) p( t ) = PD k k k (2.11) Assim, utilizando as observáveis corrigidas, tal como na equação (2.11), o usuário poderá realizar o posicionamento por ponto nessa estação para determinar sua posição (MONICO, 2000). 2.3 DGPS em rede No DGPS em rede as correções diferenciais são calculadas, individualmente, para cada uma das estações de referência da rede. O cálculo das correções para cada uma das estações é feito do mesmo modo que para o DGPS (utilizando somente uma estação base) (seção 2.2.1). No entanto, para se aplicar as correções diferenciais para a estação móvel, deve-se obter um único vetor de correção, ou seja, uma única correção de

31 pseudodistância para cada satélite. Nesse sentido, um modelo de interpolação deve ser utilizado Interpolação das correções diferenciais para posição da estação móvel Existem vários métodos de interpolação das distâncias tais como interpolação por superfícies matemáticas, interpolação por plano de correções, etc. Dentre os vários métodos está o de interpolação por ponderação da distância entre as estações base e a estação móvel. Este método foi escolhido pois o mesmo já foi comparado com outros métodos em outras pesquisas (ALVES, 2008) e foi apontado como o método que apresenta os melhores resultados. Na interpolação por ponderação de distância, aplica-se um peso maior para correções das estações mais próximas. Quanto maior for a distância das estações, menor será o peso dado a correção da respectiva estação, para que se possa gerar as correções da estação móvel (KAPLAN e HEGART, 2006). P ( ) Como pode-se observar na Figura 02, a estação 3 ε 3 ( ) P M ε M, logo a peso dado as correções ε 3 estação móvel ( ) está mais próxima da da estação P3 será maior. (ϕ ) P 1 ( ε 1 ) P ε M ( ) M P 2( ε 2 ) P 3( ε 3 ) ( λ ) Figura 02 Interpolação por ponderação de distância. distância: A correção DGPSR é determinada por meio da interpolação ponderada pela

32 22 n j ε M = s ε j j= 1 s, (4.10) onde: n é o número de estações de referência; s = s móvel ( ) j P ε. M M n s j j= 1 ; 1 =, sendo d j é a distância entre a j-ésima estação de referência e a estação d j

33 23 3 O PADRÃO RTCM A Radio Technical Commission for Maritime Services (RTCM) é uma organização que está localizada em Washington, nos Estados Unidos, e não possui fins lucrativos. Essa comissão fundou em 1983 o Comitê Especial 104, com a finalidade de desenvolver recomendações e critérios para a transmissão das correções das pseudodistâncias (possibilitando realizar somente o DGPS) (SAATKAMP, 2003). Essas recomendações foram implementadas em 1985 originando a primeira versão do padrão, denominado RTCM 1.0. A partir de então, novas versões desse padrão foram publicadas (versões 2.1, 2.2, 2.3). Atualmente encontra-se disponível o RTCM 3.1, publicada em 31 de Agosto de As versões mais atuais do RTCM permitem a prática das mais diversas aplicações GNSS. Todavia, vale dizer que a RTCM não monitora e nem impõe o uso de seus padrões (SANTOS, 2003). O padrão RTCM é codificado em mensagens binárias para a transmissão via link de comunicação entre estações base e móveis quaisquer. A transmissão dessas mensagens era realizada, comumente, por enlaces de rádio. Atualmente, muitas pesquisas e aplicações são realizadas utilizando a Internet como meio de comunicação para transmissão das mensagens RTCM. O padrão RTCM 2.3 possibilita a transmissão de dados e/ou correções GNSS entre uma estação base e uma estação móvel qualquer. Os dados transmitidos em tempo real permitem a realização de técnicas de posicionamento como o DGPS e o RTK. No entanto, essa versão não permite a realização de aplicações utilizando uma rede de estações de referência, como é o caso do RTK em rede (RTCM, 2001). O RTCM 3.0 é mais eficiente e suporta o transporte de um número maior de informações possibilitando a realização do RTK em rede (RTCM, 2004). A seguir serão apresentadas as principais mensagens utilizadas no DGPS e RTK das versões 2.3 e 3.1 do RTCM, e ainda uma comparação entre as duas. 3.1 RTCM 2.3 Na versão 2.3 as mensagens são separadas em tipos e identificadas através de seus números de reconhecimento, variando de 1 a 63. De maneira geral, elas se

34 classificam em: fixas, tentativas ou reservadas. A Tabela 01 ilustra as principais mensagens utilizadas no DGPS e RTK. 24 Tabela 01 Tipos de Mensagem RTCM versão 2.3 Tipo de Mensagem Status Atual Nome da Mensagem 1 Fixa Correções Diferenciais GPS 2 Fixa Correções Diferenciais GPS Delta 3 Fixa Parâmetros da Estação de Referência GPS 5 Fixa Saúde da Constelação GPS 7 Fixa Almanaque dos Radiofaróis DGPS 14 Fixa Tempo da Semana GPS Fonte: RTCM (2001) As mensagens citadas acima são as mais utilizadas no em aplicações DGPS. Para entender como é realizada a codificação e decodificação das mensagens RTCM, a seguir será apresentado como exemplo a descrição da mensagem tipo 1. O início de cada quadro de mensagem consiste de duas palavras-padrão (ou cabeçalho) (Figura 03). Cada quadro de mensagem pode ter o comprimento de n+2 palavras, onde n é o número das palavras que contêm os dados, e o número 2 refere-se às duas primeiras palavras do cabeçalho (Figura 03) da mensagem. O número máximo de palavras de dados permitido por mensagem é 31, logo o número máximo de palavras de uma mensagem é de 33. Por exemplo, a mensagem do tipo 1 que é utilizada para transportar as correções diferenciais é composta pelas 2 palavras do cabeçalho (Figura 03) e mais o número de palavras necessárias para transmitir as correções dos satélites disponíveis (Figura 04). Primeira palavra de cada mensagem Preâmbulo Tipo de Identificação da Paridade Mensagem Estação MSB LSB MSB LSB Segunda palavra de cada mensagem MSB Contador Z N o de Comp. do Saúde Paridade Modificado Seq. Quadro da Est. LSB Figura 03 Duas primeiras palavras de cada quadro da mensagem RTCM versão 2.3 Fonte: RTCM (2001).

35 25 A sigla MSB significa Most Significant Bit e LSB significa Least Significant Bit, mais detalhes da utilidade desses bits serão apresentados na seção O conteúdo das duas primeiras palavras é sumarizado na Tabela 02. Tabela 02 Informações contidas nas duas primeiras palavras de cada mensagem. Palavra Conteúdo Nº de bits Fator de escala e Unidades Comprimento Preâmbulo Primeira Tipo de mensagem (Nota 1) Identificação da estação Paridade 6 (Nota 2) -- Contador Z modificado 13 0,6 seg seg Nº de seqüência Segunda Comprimento do quadro 5 1 palavra 0-31 palavras Saúde da estação condições Paridade 6 (Nota 2) -- Nota 1: o número 64 é indicado com todos bits preenchidos com zeros; Nota 2: ver seção A seguir são descritos cada um dos campos das duas primeiras palavras: Preâmbulo: é utilizado para identificar o sistema de posicionamento utilizado. Por exemplo, é convencionado que o código identifica o sistema GPS (SAATKAMP, 2003). Tipo de mensagem: é utilizado para identificar o tipo de mensagem enviada em fixa, tentativa ou reservada. A mensagem fixa é aquela que não está sujeita a alterações no seu padrão, as tentativas são mensagens que estão sujeitas a alterações ou adequações em seu padrão e as reservadas destinam-se a suportar novos parâmetros que venham a ser implementados. Identificação da estação: é um parâmetro que pode ser arbitrário e é definido pelo emissor da mensagem. Paridade: o algoritmo de paridade gera, a partir dos bits de dados de uma palavra binária, bits extras com o objetivo de verificar se houve erros na transmissão dos dados, ou seja, para checar se há igualdade (= paridade) entre os bits de dados transmitidos e os recebidos (SAATKAMP, 2003). Contador Z modificado: para pseudo-satélites o contador Z modificado é o instante de início do próximo quadro de dados, assim como instante de referência para os parâmetros da mensagem. Para o caso em que não se têm pseudo-satélites este é apenas a referência de

36 tempo dos parâmetros da mensagem. Este contador terá o intervalo de uma hora variando de 0 até 3599,4. Para obter o valor dessa fração de hora deve-se multiplicar o valor recebido nesse campo por um fator de escala constante de 0,6 seg. Esse campo tem a extensão de uma hora devido ao fato de que o usuário do receptor móvel já terá acesso a outros dados (hora dia, mês e ano) quando ele iniciar o receptor. Número de seqüência: ajuda na sincronização dos quadros de mensagem. Comprimento do quadro: é o terceiro campo da segunda palavra que transporta o comprimento do quadro dado em número de palavras, como segue: (comprimento do quadro) = (número de palavras do cabeçalho = 2) + (número de palavras necessário para transmissão dos dados correspondentes a mensagem em questão). Saúde da estação: é enviada no quarto campo da segunda palavra. O estado 111 indica que a estação não está funcionando apropriadamente e o estado 110 indica que a transmissão não é monitorada. Esses parâmetros e outros 6 são apresentados na Tabela 03. Os últimos 6 parâmetros da Tabela 03 indicam os fatores de escala do parâmetro UDRE (User Differential Range Error), que está contido nas mensagens de correção diferencial (tipos 1, 2, 9, 31 e 34). Muitos serviços podem prover o esquema apresentado na Tabela 03. No entanto, podem optar por utilizar somente os estados 000, 110 e 111. Caso o esquema apresentado na Tabela 03 seja utilizado, os estados de 001 até 101 devem ser empregados às mensagens de correções diferenciais (tipos 1, 2, 9, 31 e 34). Todavia, se a estação de referência utilizar somente o esquema 000, 110 e 111, ao invés do esquema da Tabela 03, o receptor móvel deve ignorar os estados de 001 até 101. Uma vez que esses estados são ignorados o usuário utilizará somente o fator de escala igual a 1 (estado 000). Tabela 03 Indicador de saúde da estação de referência. Código Indicação 111 Estação de referência não está funcionando 110 Transmissão da estação de referência não monitorada 101 Fator de escala UDRE = 0,1 100 Fator de escala UDRE = 0,2 011 Fator de escala UDRE = 0,3 010 Fator de escala UDRE = 0,5 001 Fator de escala UDRE = 0, Fator de escala UDRE = 1 26

37 27 Como apresentado, as mensagens RTCM são compostas por duas palavras iniciais (cabeçalho), como descrito acima e, somadas a essas duas palavras, seguem os dados específicas específicos de cada mensagem (exemplos ver Tabela 01). Como exemplo, a seguir a mensagem do tipo 1 será apresentada. Como se pode observar na Figura 04, os dados referentes às correções de cada satélite não são passíveis de serem transmitidos em uma única palavra da mensagem. As informações referentes a cada satélite ocupam um total 40 de bits. Logo, não é possível alocar os dados de um satélite em uma única palavra, fazendo com que haja a necessidade de se ocupar mais de uma palavra para alocar os dados de um satélite. Dessa forma para se obter o número de palavras necessárias para o transporte de dados de N s satélites (na mensagem tipo 1) pode-se utilizar a seguinte formula: 40* Ns n = round (3.1) 1 24 Na primeira palavra da Figura 04, os 24 bits que contém: o Fator de Escala (FE) das correções, o UDRE, a IDSAT e a correção diferencial ρ( t )). A próxima palavra aloca as variações ( k das correções ( p& ), o IODE (Issue of Data Ephemeris) (essas informações serão descritas em mais detalhes ainda nessa seção) e o início das informações do segundo satélite (ver exemplo na Figura 04). Assim, pode-se notar que haverá variações na forma de como os dados de cada satélite serão dispostos nas palavras. Na Figura 04 pode-se notar que existirão 7 diferentes possibilidades de disposição dos dados nas palavras do quadro de mensagens. Os últimos 6 bits de cada 1 Round é o maior inteiro: round (10,4)=11; round (10,6)=11; round (10,5)=11

38 28 palavra são reservados para os bits de paridade. Nesse caso se o número de satélites transmitidos não for múltiplo de 3 então a última palavra poderá ter dois formatos diferentes, contendo 8 ou 16 campos de bits. E para esses dois casos o espaço livre restante é preenchido com uma seqüência de bits 1 e 0 (ver exemplo na Figura 04) FE UDRE IDSAT Palavras 3, 8, 13 ou 18 5 p( t k ) Paridade Palavras 4, 9, 14 ou p& IODE FE UDRE IDSAT Paridade p& Paridade p ( t k ) Palavras 5, 10, 15 ou 20 Palavras 6, 11, 16 ou IODE FE UDRE IDSAT p( t k ) Palavras 7, 12, 17 ou 22 Paridade p( t k ) p& IODE Paridade M Última palavra, se o número dos satélites for 1, 4, 7 ou p& IODE Preenchimento Paridade Última palavra, se o nú mero dos satélites for 2, 5, 8 ou IODE Preenchimento Paridade

39 29 Figura 04 Mensagem tipo 1 do RTCM versão Fonte: RTCM (2001) A seguir é apresentada a Tabela 04 que contêm os parâmetros apresentados na Figura 04, o número de bits ocupado por cada parâmetro, os fatores de escala, as unidades utilizadas e a extensão de cada parâmetro. Tabela 04 Informações contidas na mensagem do tipo 1 para cada satélite. Parâmetros Nº de Bits Fator de escala e unidades Extensão do parâmetro Fator de Escala 1 Ver Tabela 05 2 UDRE 2 Ver Tabela 05 4 SATID (nota 1) ρ( t k ) ou 0.32 m ± ou ± m (nota 3) p& ou m/s ± ou ± m/s (nota 4) IODE 8 (nota 5) Total 40 * N s Campo complementar 8 x [Ns mod 3]3 Bits Paridade n x 6 Ver seção Ns é o número de correções diferenciais contidas na mensagem, o que corresponde ao número de satélites; n é o número de palavras que contém dados. O que implica em um quadro com o comprimento igual a n+2 palavras; Nota 1: o satélite 32 é indicado com zeros (00000); Nota 3: o número binário indica um problema com o satélite para que o equipamento pare imediatamente de utilizá-lo; 5 Na primeira palavra da Figura 04 (terceira palavra da mensagem) a numeração 3, 8, 13 ou 18, significa que para mensagem tipo 1, os campos da 3ª palavra irão se repetir com a mesma estrutura nas 8ª, 13ª e 18ª palavras. 3 Na equação do Campo complementar da Tabela 04 (8 x [Ns mod 3]), o número 8 refere-se ao número de bits de cada byte e mod refere-se ao resto da divisão. Logo esse é o número de bits que deverão ser utilizados para preencher a última palavra do quadro da mensagem tipo 1.

40 30 Nota 4: o número binário indica um problema com o satélite para que o equipamento pare imediatamente de usar o mesmo; A seguir serão apresentadas as descrições de cada campo da mensagem tipo 1: Fator de escala: representa o fator de escala das correções diferenciais e das variações das correções. Esses fatores de escala são apresentados na Tabela 05. Tabela 05 - Fatores de escala das correções diferenciais. Código Número Indicação 0 0 O fator de escala da correção de pseudodistância é 0,02 m e o fator de escala da taxa de variação das correções é 0,002 m/s 1 1 O fator de escala da correção de pseudodistância é 0,32 m e o fator de escala da taxa de variação das correções é 0,032 m/s UDRE: representa o desvio padrão da correção diferencial a um sigma. Os valores de UDRE são apresentados na Tabela 06. Note que esses valores devem multiplicados pelos fatores de escala (Tabela 03). Tabela 06 UDRE. Código Número UDRE metro 01 1 > 1 metro e 4 metros 10 2 > 4 metro e 8 metros 11 3 > 8 metros SATID: é a identificação do satélite, que é representada pelo PRN do satélite; ρ t ): é a correção diferencial calculada pela estação base. A correção é obtida a partir ( k da diferença da distância calculada utilizando as coordenadas da estação base e a pseudodistância observada pelo receptor (corrigida do erro do relógio do receptor). Para mais detalhes consultar Dalbelo, Alves e Monico (2006). p& (2006). : é a taxa de variação das correções diferenciais, ver Dalbelo, Alves e Monico IODE: esse campo permite que o usuário verifique se está utilizando os mesmos parâmetros orbitais e de relógio que foram utilizados pela estação base. 3.2 Algoritmo de Paridade e Decodificação da Mensagem Tipo 1

41 31 Até o presente momento foram apresentadas as principais características do RTCM versão 2.3, bem como o cabeçalho das mensagens e a mensagem tipo 1, que é responsável por transportar as correções diferenciais e suas variações. Nessa seção são apresentados os procedimentos para a decodificação e interpretação das seqüências binárias da mensagem tipo 1. Esse procedimento é empregado na maioria dos receptores que são capazes de realizar o posicionamento diferencial. No entanto, o processo de decodificação ainda não é muito difundido na comunidade científica brasileira Algoritmo de Paridade A Figura 05 apresenta o algoritmo de paridade. Esse algoritmo é o chamado Hamming Code (IS-GPS, 2004). Nesse algoritmo são gerados bits de paridade que são utilizados posteriormente, pelo receptor móvel, para verificar se os valores de paridade enviados são iguais aos valores calculados pelo receptor móvel, utilizando esse mesmo algoritmo. Os bits de paridade (B 25 até B 30 ), que serão enviados, são gerados a partir dos 24 bits calculados pelo receptor base (b 1 até b 24 ), e pelos últimos dois bits da palavra anterior (B 29, B30 ) a que está sendo gerada. B 1 = b 1 B 30 B 2 = b 2 B 30 B 3 = b 3 B 30 M M B 24 = b 24 B 30 B 25 = B 29 b 1 b 2 b 3 b 5 b 6 b 10 b 11 b 12 b 13 b 14 b 17 b 18 b 20 b 23 B 26 = B 30 b 2 b 3 b 4 b 6 b 7 b 11 b 12 b 13 b 14 b 15 b 18 b 19 b 21 b 24 B 27 = B 29 b 1 b 3 b 4 b 5 b 7 b 8 b 12 b 13 b 14 b 15 b 16 b 19 b 20 b 22 B 28 = B 30 b 2 b 4 b 5 b 6 b 8 b 9 b 13 b 14 b 15 b 16 b 17 b 20 b 21 b 23 B 29 = B 30 b 1 b 3 b 5 b 6 b 7 b 9 b 10 b 15 b 16 b 17 b 18 b 21 b 22 b 24 B 30 = B 29 b 3 b 5 b 6 b 8 b 9 b 10 b 11 b 13 b 15 b 19 b 22 b 23 b 24 Onde: O símbolo representa que o bit é da palavra anterior; B 1, B 2,..., B 2 4 são os bits calculados pelo algoritmo acima; b 1, b 2,..., b 29,b 30 são os bits fonte gerados pela estação base. Figura 05 Codificação dos bits a serem transmitidos. Adaptado de: IS-GPS (2004).

42 32 De acordo com as equações apresentadas na Figura 05, aplicando o operador todos os bits de b1 até b24 serão invertidos caso o último bit da palavra anterior (B30 ) seja igual a 1. Esse operador é denominado de complemento binário chamado de soma módulo dois. As possíveis somas realizadas com esse operador são: 1 1=0, 0 1=1, 1 0=1, 0 0=0. Logo, caso o último bit seja igual a 0 (zero) a inversão não ocorrerá. Note que na Figura 05 os bits transmitidos pelo receptor base (B1,..., B30) serão, posteriormente, considerados neste texto com a notação b1,...,b30, quando os mesmos forem recebidos pelo receptor móvel. Segundo o IS-GPS (2004) o algoritmo de paridade, para o usuário (estação móvel), pode ser implementado como o esquema apresentado na Figura 06. Entrada Aplicar em b 1,..., b 24 para obter B 1,...,B 24 Sim Se B 30 = 1 Não Não aplicar em b 1,..., b 24 para obter B 1,..., B 24 Substituir b 1,..., b 24, B 29 e B 30 nas equações de paridade da figura 05. Não Os bits B 25,..., B 30 calculados são iguais aos b 25,..., b 30 recebidos? Sim Checagem de paridade rejeitada Checagem de paridade aceita Fim Fim Figura 06 Algoritmo de paridade. Adaptado de: IS-GPS (2004).

43 33 O algoritmo de paridade verifica se os bits b 25,...,b 30 recebidos pelo receptor móvel são iguais aos B 25,...,B 30 calculados (aqui são os bits calculados pela estação móvel), utilizando os dados recebidos. Caso constate-se essa igualdade pode-se concluir que todos os bits foram transmitidos corretamente. Porém se os bits calculados não forem iguais aos enviados significa que os dados devem ser rejeitados. Segundo o padrão RTCM (2001) esse algoritmo é capaz de detectar até dois bits de dados com problemas em uma palavra Decodificação das mensagens RTCM 2.3 A seguir, na Figura 07, será apresentada uma amostra da mensagem RTCM tipo 1 no formato ASCII 4. O procedimento para decodificação e a mensagem utilizada nesse exemplo foi baseado em Saatkamp (2003). O padrão RTCM 2.3 transporta os dados empacotados em bytes de 8 bits. Segundo Saatkamp (2003), para decodificar uma mensagem deve-se seguir o padrão definido pelo RTCM e as regras para a composição dos bytes. Os sistemas computacionais que trabalham com 8 bits indicam que o primeiro bit de dados enviado é o menos significativo (LBS) e que o oitavo bit é o mais significativo (MBS) (RTCM, 2001). As interfaces de comunicação serial, em sua maior parte, seguem essa convenção. Todavia, o padrão RTCM segue a ordem inversa dessa convenção (MSB-LSB) (ver Figura 03 da seção 3.1). Dessa forma, o emissor de dados RTCM deve realizar um rotacionamento dos bits do byte (deve-se trocar a ordem de LSB- MSB para MSB-LSB), antes que os mesmos sejam enviados. O receptor do usuário por sua vez deve realizar a operação contrária, logo após receber cada byte da mensagem. Outro aspecto importante a ser considerado é que dos 8 bits de cada byte transmitido, somente 6 bits são utilizados para codificação dos dados. Os bits utilizados 4 ASCII American Standard Code for Information Interchange. Esse formato ASCII é composto por 8 bits. Mais informações podem ser encontradas em (MIZRAHI, 2001)

44 34 para codificação são os bits de b 1 até b 6, os bits b 7 e b 8 são fixados como marca (bit igual a 1) e espaço 5 (bit igual a 0). Seguindo as características apresentadas tem-se que um caractere ASCII lido na porta serial será escrito como: 1 byte = 8 bits = 0 1 b 6 b 5 b 4 b 3 b 2 b 1, onde se pode observar que os bits estão na ordem MSB para o LSB. Aplicando a rotação nos bits desse byte obtém-se b 1 b 2 b 3 b 4 b 5 b Como apresentado anteriormente na seção 3.1, na Figura 03, cada palavra da mensagem RTCM possui 30 bits (24 bits de dados + 6 bits de paridade). Logo as palavras RTCM serão formadas por 5 caracteres de 8 bits, visto que cada byte carrega somente 6 bits de dados. Figura 07 Mensagem tipo 1 ASCII do RTCM versão 2.3. Fonte: Saatkamp (2003). Tomando como exemplo os 5 primeiros caracteres da mensagem tipo 1 da Figura 07, tem-se (ver tabela ASCII no anexo A): f = 102 d = 66 h = b rotacionando os bits tem-se A = 65 d = 41 h = b rotacionando os bits tem-se B = 66 d = 42 h = b rotacionando os bits tem-se ` = 96 d = 60 h = b rotacionando os bits tem-se Y = 89 d = 59 h = b rotacionando os bits tem-se O termos marca e espaço são entendidos, na comunicação digital, respectivamente, como nível lógico alto (1) e nível lógico baixo (0).

45 35 Onde os sub-índices d, h e b representam respectivamente valores decimais, hexadecimais e binários. Como se pode observar no exemplo acima a seqüência de bits de dados (bd) da primeira palavra são os bits em verde, depois de rotacionados. Logo, a primeira palavra é escrita colocando os bd em fila, como segue: primeira palavra RTCM da mensagem = Os bits na cor azul são os bits obtidos através do caracter ASCII Y citado no exemplo acima, representando os bits de paridade da palavra. Para transformar um número da base binária para a base decimal basta seguir a fórmula: S N N i ( bit ) = b d * b i= 1 2 (3.2) Utilizando a equação 3.2 foi realizada a decodificação do tipo da mensagem e da identificação da estação (ver Figura 08). Primeira palavra de cada mensagem Preâmbulo Tipo de Identificação da Paridade Mensagem Estação Identificação do Sistema GPS 0* * * * * *2 0 = 1 0* * * *2 6 +0* * * * * *2 0 = 1 Aplicar algoritmo de paridade Figura 08 Decodificação da primeira palavra da mensagem tipo 1. De acordo com o padrão RTCM, os 6 últimos bits (em azul) são os bits de paridade. Esses bits são os que devem ser verificados, como apresentados na seção O tipo da mensagem é igual a 1 e a identificação da estação também é igual a 1. Os últimos 6 bits são referentes ao algoritmo de paridade. 3.3 RTCM 3.1 As informações contidas nessa seção foram escritas com base no padrão RTCM 3.1 (RTCM, 2007). Como mencionado anteriormente essa é a versão mais atual do RTCM. A Versão 3.1 do padrão RTCM foi desenvolvida para suportar operações

46 36 cinemáticas em tempo real, com múltiplas estações de referência. Esse novo formato possibilita a transmissão de uma quantidade maior de informações, permitindo assim a realização de muitas aplicações que requerem a transmissão de grande quantidade de dados, como o RTK em Rede (RTCM, 2007). O RTCM 3.1 tem mensagens que suportam dados GPS e GLONASS RTK, incluindo observações do código e da fase da onda portadora, parâmetros da antena e parâmetros auxiliares do sistema (RTCM, 2007). O documento da versão 3.1 descreve mensagens e técnicas para dar suporte as operações realizadas como GPS e GLONASS. Além disso, esse formato é capaz de suportar modificações desses sistemas (por exemplo, os novos sinais L2C e L5), e novos sistemas em desenvolvimento (por exemplo, o GALILEO). Outros sistemas, como os sistemas de aumento que utilizam satélites geoestacionários, também são suportados por esse formato. Esses sistemas são denominados na literatura por SBAS. O primeiro desses sistemas a ser implementado nas mensagens RTCM 3.1 foi o WAAS. O segundo sistema que será implantado é o European Geostationary Navigational Overlay System (EGNOS Sistema de Cobertura de Navegação Geoestacionário Europeu) (ENGEL e HEISER, 2004; SAKAI et al., 2006). Esse segundo sistema será acomodado em novas mensagens do RTCM 3.* (RTCM, 2007). Essa nova versão permite ainda: (1) mensagens de efemérides GPS, que proporcionam registros dos satélites utilizados pela estação base, (2) mensagens de efemérides GLONASS, que proporcionam um registro dos satélites utilizados pela estação base, (3) uma mensagem que contém informações textuais e por último (4) um conjunto de mensagens proprietárias, que poderão ser utilizadas pelos fabricantes de receptores. Essa versão propõe uma estrutura para prover integridade e capacidade para aplicações existentes e futuras de uma maneira eficiente. Para promover tais qualidades esse padrão é definido em camadas adaptadas de um Open System Interconnection (OSI). As camadas do sistema OSI utilizadas como adaptação para o RTCM são: de aplicação, de apresentação, de transporte, de comunicação e camada física. Vale salientar nesse texto que as camadas citadas nesse parágrafo são adaptações das camadas definidas para Internet (sistema OSI), utilizadas como conceito base para aplicações de comunicação e transmissão das mensagens RTCM versão 3.*. Essas camadas serão apresentadas nas seções a seguir.

47 Camada de Aplicação A camada de aplicação especifica como as mensagens da versão 3.1 do RTCM SC-104 são passíveis de serem utilizadas em diferentes aplicações. Um serviço diferencial tem como aspecto fundamental a transmissão de dados, e não de um link bidirecional. A informação é produzida por uma central, um Serviço Provedor, que possui um interesse institucional ou comercial em prover serviços de posicionamento ou navegação (RTCM, 2004). As aplicações do RTK no ar, água e operações terrestres são numerosas e não caberia citá-las, pois não faz parte do escopo dessa pesquisa, mas, as principais, são: Marinhas: levantamentos hidrográficos, operações em draga, navegação em canais estreitos, altura de marés, colocação e revisão de bóias; Aéreas: levantamentos aéreos, testes de sistemas terrestres, calibração de outros sistemas de navegação; Terrestres: levantamentos, construção de edifícios e pontes, superfícies de mineração, agricultura, construção de estradas, locação de recursos e manejo. As exigências para essas diferentes aplicações não variam muito. A largura de banda do link de transmissão e as taxas de atualização são determinadas principalmente pela acurácia requerida e pelas obstruções do meio físico (RTCM, 2004) Camada de Apresentação A versão 3.1 do padrão RTCM SC-104 é escrita em um formato de base de dados. As mensagens RTK GPS e GLONASS estão definidas de forma que evitem a colocação de identificadores (flags) nas mensagens, pois isso muda o comprimento ou o significado dos dados nas mensagens. Existem algumas variabilidades que não podem ser evitadas, pois o número de satélites utilizados nas aplicações não é fixo. No entanto, é possível determinar o número de satélites examinando o comprimento da mensagem, visto que o número de satélites é a única quantidade variável. Em mensagens cujos comprimentos não se alinham com os bytes limites, a estação de referência deve preencher o final com zeros (RTCM, 2004). As mensagens dessa versão são padronizadas em diferentes grupos, divididos de acordo com a realização de uma determinada operação/serviço. Sendo que os

48 emissores devem transmitir pelo menos uma mensagem de cada um dos vários grupos, apresentados na ). Tabela 07, para que se possa realizar uma determinada aplicação (RTCM, Tabela 07 Grupos de mensagens. Nome do grupo Nome do sub-grupo GPS L1 GPS L1/L2 Observações GLONASS L1 GLONASS L1/L2 Coordenadas da estação Descrição da antena Tipo da mensagem Dados auxiliares das estações da rede 1014 Correções RTK em rede Diferenças de correções ionosféricas 1015 Inf. auxiliares Informações proprietárias Diferenças de correções geométricas 1016 Diferenças das correções ionosféricas e geométricas combinadas 1017 Parâmetros do sistema Dados de efemérides dos satélites 1020 String de texto 1029 Atualmente designadas de 4088 a 4095 Fonte: RTCM (2007). Nessa versão do RTCM, diferentes mensagens em um mesmo grupo contêm informações similares. A mensagem mais curta contém o mínimo necessário para proporcionar um serviço, enquanto as outras mensagens são dotadas de informações

49 39 adicionais para aumentar o desempenho de um determinado serviço. Por exemplo, a mensagem tipo 1001 é a menor mensagem para observações GPS, nomeada de observável L1-only. Essa mensagem é ideal quando se tem um link de comunicação com limitações com relação à capacidade de transmissão. Já a mensagem tipo 1002 contém todas as informações que a mensagem tipo 1001 contém, porém com informações adicionais que podem acrescentar melhorias em uma determinada aplicação. A seção apresenta o conteúdo de algumas mensagens apresentadas na Tabela Mensagens RTCM versão 3.1 Cada mensagem contém um conjunto específico de campos de dados, muito embora alguns campos podem se repetir em mensagens diferentes. O conjunto de dados é enviado em uma lista ordenada. Múltiplos valores de bytes são caracterizados com o primeiro byte, que é o mais significante transmitido, e o último byte que é o menos significante transmitido. Diferente da versão 2.*, no padrão a versão 3.* não há inversão de bits dentro de um byte. A Tabela 08 apresenta o conteúdo dos cabeçalhos das mensagens 1001 a Tabela 08 Cabeçalho das mensagens RTCM Campo de dados Tipo de dados 6 N o de bits Número da mensagem (ex: 1001 = ) uint12 12 Identificação da estação de referência uint12 12 Tempo da época GPS (ToW) uint30 30 Mensagem de sincronismo GNSS bit (1) 1 6 A sigla uint vem de unsigned integer, que é um sistema numérico que não usa números inteiros negativos. O número que segue a sigla representa o tamanho do campo. A sigla int significa que o sistema numérico utilizado é o dos números inteiros. E por último bit significa que o campo de dados é apenas binário, ou seja 0 ou 1.

50 40 N de sinais de satélite GPS processados uint5 5 Indicador de Suavização livre de divergência GPS 7 bit (1) 1 Intervalo de suavização GPS bit (3) 3 Total 64 Fonte: RTCM (2004). Uma descrição de cada campo citado na tabela 07 é apresentada a seguir: Número da mensagem: é um nome auto-explicativo para esse campo; Identificação da estação de referência: é a identificação de uma determinada estação de referência em uma aplicação, que é definida pelo provedor do serviço; Tempo da época GPS (ToW - Time of Week): é o número de segundos contados desde o início da semana GPS até o instante de tomada da observação; Mensagem de sincronismo GNSS: se o flag for 0 (zero), significa que não há uma observável GNSS adicional referenciada a mesma época para ser transmitida. Isso significa que o receptor pode iniciar o processamento dos dados imediatamente após a decodificação da mensagem. Caso contrário, se esse campo for 1 (um), significa que a próxima mensagem contém informações de uma outra fonte GNSS referenciada a mesma época; N de sinais de satélite GPS processados: é o número de satélites contidos na mensagem. Esse número não é necessariamente o número de satélites visíveis na estação base; Indicador de Suavização livre de divergência GPS: se esse número for 0 (zero) significa que a suavização livre de divergência não é usada, se for 1 significa que a mesma é utilizada. O algoritmo de suavização não será descrito aqui, para maiores detalhes consultar Konno et al. (2006); Intervalo de suavização GPS: é o período de integração sobre o qual a pseudodistância é suavizada usando informações da fase da onda portadora. A Figura 09 ilustra mensagens do tipo 1001 e Essas mensagens transportam informações da portadora L1. 7 O método de suavização livre de divergência está descrito em Konno et al (2006).

51 1001 Campo de dados Tipo de dados N o de bits Identificação do satélite GPS uint6 6 Indicador do código L1 GPS bit(1) 1 Pseudodistância L1 GPS uint24 24 Distância em fase L1 pseudodistância L1 Int20 20 Indicador de tempo de lock L1 GPS uint7 7 Módulo de ambigüidade da Pseudodistância inteira L1 uint8 8 CNR (Carrier-to-Noise Ratio) L1 uint8 8 Total 74 Figura 09 Conteúdos das mensagens 1001 e 1002 para um satélite específico Fonte: RTCM (2004) Pode-se notar na Figura 09 que, como mencionado, o conteúdo da mensagem 1001 é menor que o conteúdo da mensagem A mensagem 1002 contém informações adicionais que podem prover um melhor desempenho. A descrição de cada campo contido nas mensagens 1001 e 1002 é apresentada a seguir: Identificação do satélite: é realizada através dos números PRNs, que para o GPS são números no intervalo de 1 até 32. A identificação de satélites acima de 32 é reservada para sinais de satélites dos SBAS. Mas deve-se considerar que os PRNs dos satélites SBAS correspondem ao intervalo de 120 a 138. No entanto, a identificação reservada para os satélites SBAS no RTCM 3.1 é de 40 até 58, e é por esse motivo que os PRNs SBAS são obtidos a partir do RTCM versão 3 adicionando um termo constante de 80. Indicador do código L1 GPS: identifica o código que está sendo rastreado na estação de referência. Receptores civis são capazes de rastrear o código C/A, e opcionalmente o código P, enquanto que os receptores militares são capazes de rastrear o código P e Y, os quais sempre são emitidos pelos satélites. Assim, o valor 0 indica que o receptor rastreia o código C/A e o valor 1 indica que o receptor está coletando o código P(Y); Pseudodistância L1 GPS: esse campo proporciona a recuperação da pseudodistância original medida na estação de referência (em metros). No entanto, para isso, deve-se considerar o seguinte: a medida de pseudodistância da estação base e de pseudodistância da estação móvel têm comprimentos similares (Figura 10). Dessa forma, esse campo da mensagem RTCM fica responsável por transportar apenas uma parte da pseudodistância da estação base. Parte essa que pode variar de 0 até ,458 m. O valor ,458 m corresponde a um mili-segundo multiplicado pela velocidade da luz. Assim, a pseudodistância da estação base pode ser reconstruída na estação móvel pela seguinte expressão: (pseudodistância da base) = (campo pseudodistância L1 GPS) + (a soma das

52 distâncias inteiras referente a um mili-segundos da velocidade da luz definidos pela estação móvel). 42 Satélite Valor fracionário transmitido Estação base Um mili-segundo * a vel. da luz Estação móvel Figura 10 Esquema de representação da pseudodistância em mili-segundos da velocidade da luz. Fonte: adaptado de Talbot (1996). Distância em fase L1 pseudodistância L1: esse campo proporciona informações necessárias para se determinar medições de fase de batimento da onda portadora em L1 provinda da estação base. Note que a distância em fase aqui definida tem o mesmo sinal que a pseudodistância. Deve-se considerar que esse campo transporta a diferença entre a observação de fase em L1, a qual tem maior qualidade que a pseudodistância, e a pseudodistância em L1. Essa diferença é utilizada apenas como uma técnica numérica para reduzir o tamanho da mensagem. A distância obtida a partir da fase é construída como segue (as grandezas aqui apresentadas são dadas em metros): (medida da fase em L1) = (pseudodistância em L1 construída por meio do campo da pseudodistância em L1 GPS) + (Distância em fase L1 pseudodistância L1). Tenho duvida por favor pode ajudar. Indicador de tempo de lock L1 GPS: provê uma medida do montante de tempo decorrido, durante o qual o receptor da estação de referência manteve uma sintonia contínua com o sinal do satélite. Se uma perda de ciclo ocorrer durante a medição prévia dos ciclos, o indicador de sintonia será reiniciado, sendo atribuído a esse o valor zero.

53 43 Módulo de ambigüidade da Pseudodistância inteira L1: esse campo representa o número inteiro da divisão da medida de pseudodistância original (dados brutos) por ,458 m. CNR (Carrier-to-Noise Ratio) L1: esse campo transporta a estimativa da razão do ruído da fase do sinal do satélite em db-hz. Se esse campo for igual a 0 (zero) significa que a CNR não foi calculada. As mensagens 1003 e 1004 contêm, também, as informações das mensagens 1001 e 1002 e, em adição, as informações para a portadora L2. Informações estas que são alocadas em campos que utilizam também estratégias para diminuir o tamanho da informação que será transmitida. No entanto, essa estratégia utiliza uma combinação entre as observações de L1 e de L2 para gerar parâmetros que possibilitem o usuário (receptor móvel) reconstruir a medida de pseudodistância e de fase para a portadora L2. Essa estratégia, bem como essas mensagens, não serão apresentadas nessa pesquisa, pois nessa dissertação de mestrado apenas dados de C1 serão utilizados, para mais informações consultar RTCM (2007). A Figura 11 apresenta os dados das mensagens 1005 e Essas mensagens, como mencionando anteriormente, referem-se ao grupo de mensagens que transportam informações sobre as coordenadas da estação. A mensagem 1005 transporta as coordenadas cartesianas do ponto de referência da antena (que na literatura em inglês é chamado de ARP Antenna Reference Point). A mensagem 1006 proporciona, além das informações da 1005, a altura do ARP acima do monumento que está sendo levantado. Essa mensagem é designada para operações com GPS, mas pode ser igualmente utilizada para o GLONASS e no futuro para o Galileo. A mensagem 1005 e 1006 também transportam as coordenadas do centro de fase da antena provindas do IGS. Campo de dados Tipo de dados N o de bits Número da Mensagem uint12 12 Identificação da estação de referência uint12 12

54 1005 Reservado para o ano de realização do ITRF uint6 6 Indicador GPS bit(1) 1 Indicador GLONASS bit(1) 1 Reservado para indicador GALILEO bit(1) 1 Indicador da estação de referência bit(1) 1 Ponto de referência da antena ECEF 8 -X int38 38 Indicador de oscilador único bit(2) 2 Ponto de referência da antena ECEF-Y int38 38 Reservado bit(2) 2 Ponto de referência da antena ECEF-Z int38 38 Altura da antena uint16 16 Total 168 Figura 11 Conteúdos das mensagens 1005 e Fonte: RTCM (2004) A seguir são apresentadas as descrições de cada campo contido na Figura 11, a menos dos dois primeiros campos que já foram apresentados na descrição do cabeçalho das mensagens 1001 a 1004: Reservado para o ano de realização do ITRF: atualmente esse campo é configurado para transportar todos os bits como sendo iguais a 0, pois o mesmo ainda não é utilizado nessa versão do RTCM. No entanto, esse campo é reservado para as futuras versões. O ano de realização do ITRF identifica a definição do datum no qual as coordenadas estão referenciadas. Indicador GPS: 1 indica suporte ao serviço GPS e 0 indica que o serviço GPS não está em uso. Indicador GLONASS: 1 indica suporte ao serviço GLONASS e 0 indica que o serviço GLONASS não está em uso. Reservado para indicador Galileo: 1 indicará suporte ao serviço Galileo e 0 indicará que o serviço Galileo não está em uso. Indicador da estação de referência: se o valor transmitido for igual a 0 a estação é uma estação de referência real. Se o valor transmitido for igual a 1 a estação de referência não é 8 Coordenadas Earth-Center-Earth-Fixed do ponto de referência da antena para uma estação de referência estacionária.

55 uma estação real. Ou seja, a estação pode ser uma estação virtual (ALVES, MONICO e ALBELO, 2007). Indicador de oscilador único: se o valor transmitido for igual a 0 significa que todas as observações contidas nas mensagens de 1001 a 1004 e de 1009 a 1012 podem ter sido coletadas em instantes diferentes. Caso o valor enviado seja igual a 1 significa que todas as observações contidas nas mensagens de 1001 a 1004 e de 1009 a 1012 foram tomadas ao mesmo tempo. Ponto de referência da antena ECEF-X, Y e Z: são as coordenadas do ponto de referência da antena dadas em ITRF no ano da realização utilizado. Altura da antena: esse campo provê a altura do ponto de referência da antena acima do monumento ou marco utilizado na campanha do levantamento. A Figura 12 ilustra as mensagens 1007 e Essas mensagens levam descrições ASCII das antenas das estações. Na maioria das vezes as convenções do IGS Central Bureau serão utilizadas, desde que a mesma seja aceita universalmente. O IGS Central Bureau mantém uma tabela com a nomeação e descrição para as antenas usadas em aplicações que requeiram alta precisão. Essas mensagens contem ainda o número serial da antena, o qual elimina qualquer ambigüidade relacionada ao modelo da antena Campo de dados Tipo de dados N o de bits Número da mensagem uint12 12 Identificação da estação de referência uint12 12 Contador descritor N d uint8 8 Descritor da antena (char8)*n d 8*N d Identificação do setup da antena uint8 8 Contador de número serial M s uint8 8 Número serial da antena (char8)*m s 8*M s Total 48+8*(M+N) Figura 12 Conteúdos das mensagens 1007 e Fonte: RTCM (2007). As descrições das informações contidas na Tabela 11 são: Contador descritor N d : define o número de caracteres (bytes) do campo Descritor da antena. Descritor da antena: esse campo pode transportar caracteres alfanuméricos. O IGS limita o número de caracteres a 20, esse campo permitirá mais caracteres para futuras versões do RTCM

56 Identificação do setup da antena: se esse campo for 0 significa que o padrão IGS é utilizado. Se esse campo contiver algum número entre 1 a 255 significa que está sendo utilizado um setup específico para a identificação da antena. Contador de número serial M s : esse campo define o número de caracteres (bytes) do campo seguinte, que é o número serial da antena. Número serial da antena: esse campo é composto por caracteres alfanuméricos que compõem o número serial da antena, que é dado pelo fabricante da antena. apresentado na Tabela 09. Por último apresenta-se a mensagem O conteúdo dessa mensagem é Tabela 09 Conteúdo da mensagem Campo de dados Tipo de dados No de bits Número da mensagem uint12 12 Identificação da estação de referência uint12 12 Dia Juliano Modificado Uint16 16 Segundos do dia (UTC) Uint17 17 N de identificação da mensagem (N m ) Uint5 5 Saltos de segundo uint8 8 Identificação da Mensagem # 1 Uint12 12 Identificação da Mensagem # 1 flag de sincronismo Bit(1) 1 Mensagem # 1 intervalo de transmissão Uint16 16 Identificação da mensagem # 2 Uint12 12 Mensagem # 2 flag de sincronização Bit(1) 1 Mensagem # 2 intervalo de transmissão Uint16 16 Total 70+29*N m 46 A seguir serão descritos os campos contidos na mensagem 1013: Dia Juliano Modificado (MJD): é a contagem contínua do dia desde 16 de novembro de Por exemplo, no primeiro dia da semana GPS 0 o JD era Segundos do dia (UTC): são os segundos do dia contados a partir da meia noite no tempo de Greenwich. Os segundos da semana GPS tem que ser ajustados para o número apropriado de saltos de segundo. O valor de , que corresponde ao número de segundos, é reservado para o caso em que saltos de segundo tenham sido transmitidos. N de identificação da mensagem (N m ): informa ao receptor o número do tipo da mensagem e a freqüência de suas transmissões realizadas pela estação de referência. Saltos de segundo: ver as especificações de sinal IS-GPS (2004) GPS/SPS, disponíveis em U.S. Coast Guard Navigation Information Service. O número 255 indica que o valor não é proporcionado.

57 47 Identificação da Mensagem # 1: cada notificação lista a identificação da mensagem transmitida pela estação de referência. Identificação da Mensagem # 1 flag de sincronismo: se o bit for igual a 0 significa que os dados não são transmitidos em intervalos regulares, se o flag for 1 significa que os dados são transmitidos em intervalos regulares. Mensagem # 1 intervalo de transmissão: cada notificação lista o intervalo de transmissão da mensagem transmitido pela estação de referência. Se não houver sincronismo, o intervalo de transmissão é aproximado Camada de Transporte A camada de transporte define a estrutura utilizada para enviar ou receber mensagens RTCM SC-104 versão 3.0 e 3.1 O propósito de definir esta camada é assegurar que os dados RTCM SC-104 podem ser decodificados corretamente pelas aplicações (ex: DGPS e RTK). A estrutura básica para transferência de dados de alta integridade consiste basicamente de em um preâmbulo fixo, a definição do tamanho da mensagem, a mensagem, e 24 bits para Checagem de Redundância Cíclica (Cyclic Redundancy Check - CRC) (RTCM 2004). A técnica CRC ao contrário da verificação de paridade, que é baseada na adição de bits adicionais ao bloco de dados, é baseada em uma divisão binária (FOROUZAN, 2006). A estrutura do formato é apresentada na Tabela 10. Tabela 10 Estrutura do formato RTCM versão 3. Preâmbulo Reservado Tamanho da Mensagem Mensagem de tamanho variável 8 bits 6 bits 10 bits Tamanho variável, n o inteiro de bytes Não definido, estabelecido como Tamanho da mensagem em bytes Fonte: RTCM (2007) bytes CRC 24 bits QualComm CRC-24Q O preâmbulo é fixado numa seqüência de 8 bits. Os próximos seis bits são reservados, e devem ser estabelecidos zero para todas as mensagens. Em versões futuras, estes bits poderão conter a transmissão da identificação da estação e/ou uma seqüência de contagem. A versão 3.1 utiliza o algoritmo QualComm CRC com permissão. Nesse algoritmo, vinte e quatro bits de paridade CRC proporcionam proteção contra uma curta

58 seqüência de erros ou erros aleatórios, com uma probabilidade de não-detecção de erro = 5. 96* 10 para todos canais de erros de bits com probabilidades O CRC opera em uma seqüência de bits começando com o preâmbulo, até o fim da mensagem, que pode ter comprimento variável, usando uma semente de 0 (zero). A seqüência de 24 bits (b1, b2,..., b24) é gerada de uma seqüência de bits de informação (m1, m2,..., m24n b ), onde N b é o total de números de bytes em uma seqüência. Esse total consiste do preâmbulo da mensagem somado com o comprimento de definição dos parâmetros da mensagem. Isso é realizado por meio de um código que é gerado por um polinômio: g 24 i ( X ) = g i X i= 0, (3.3) onde g = 1, para i = 0, 1, 3, 4, 5, 6, 7, 10, 11, 14, 17, 18, 23, 24 e caso contrário g = 0. i Esse código é chamado de CRC-24Q (Q for Qualcomm Comparation). O gerador do polinômio desse código é dado da seguinte forma: ( X ) = ( 1 X ) p( X ) g + onde p ( X ) é um polinômio primitivo e irredutível:, (3.4) ( X ) = X + X + X + X + X + X + X + X + X + X + 1 p (3.5) Quando, por aplicação de álgebra polinomial binária, g ( X ) acima é 24 dividida dentro de m ( X ) X, onde a seqüência de informações ( X ) 2 k 1 ( X ) = m + m + X + m X +... m X k k 1 k m é expressa por: m, (3.6) o resultado é um quociente cujo resto R ( X ) tem grau < 24. A seqüência de bit formada por esse resto representa a seqüência de checagem da paridade. Ou seja, R(X) é o CRC que será adicionado ao final da mensagem gerada na estação base e enviada para a estação móvel. O bit de paridade b i, para um i de 1 até 24, é o coeficiente de Esse código tem as seguintes características: 24 em ( X ) X i R. i detecta todos os erros de bits simples por palavra código. 2 - detecta todas as combinações de erros de bits duplos em uma palavra código porque o gerador de polinômio g ( X ) tem um fator de pelo menos três termos. 3 - detecta qualquer número excedente de erros, pois ( X ) g contém um fator 1 + X.

59 4 - detecta os maiores erros de estouro com comprimento melhor que o comprimento da paridade r = 24 bits. A fração do erro de estouro de comprimento b > 24 não detectável é: 24 8 a) 2 = , se b > 25 bits e b) 2 = , se b = 25 bits. 23 Como notado anteriormente, a estação de referência deve inserir zeros em todos os campos reservados, e para as mensagens cujos comprimentos que não se alinham com bytes limites, zeros podem ser utilizados para bits indefinidos com a finalidade de preencher o último byte não preenchido Camada de Enlace dos Dados A camada de enlace dos dados define como a mensagem RTCM SC-104 versão 3.1 é codificada na camada física (seção 3.3.5). Isso também pode incluir controle de fluxo, empacotamento ou checagem de erros adicionais. Tudo é determinado pelo provedor do serviço, que define esta camada de forma apropriada para a aplicação (RTCM, 2007) Camada Física A camada física define como os dados das mensagens RTCM SC-104 versão 3.1 são transportados ao nível eletrônico e mecânico. Por exemplo: UHF, Modem de VHF, link de Satélite, cabo fixo, etc. Isto também é determinado pelo provedor do serviço, que define esta camada de forma apropriada para a aplicação (RTCM, 2007). Para o caso da presente pesquisa o transporte será realizado por meio da Internet. Dessa forma as dados serão transmitidos parte por cabos fixos (cabos da rede de Internet) e parte por comunicação sem fio como, por exemplo, através de conexões de serviços de telefonia celular. 3.4 RTCM 2.3 Versus RTCM 3.1 apresentadas na Tabela 11. As principais diferenças entre o padrão RTCM versão 3.1 e versão 2.* são

60 50 Tabela 11 RTCM versão 3.0 versus versões anteriores RTCM versão 3.1 RTCM versão 2.* Suporta RTK em rede Não suporta oficialmente RTK em rede Múltiplas estações de referência Apenas uma estação de referência Os tipos das mensagens começam em 1000, o Um número limitado de mensagens está que permite uma maior capacidade para disponível suportar novas mensagens Utiliza algoritmo CRC de 24 bits no fim de cada mensagem para detecção de erros Utiliza algoritmo de paridade de 6 bits no fim de cada palavra de 24 bits Combinação flexível das mensagens para prover Combinação de mensagens rígida vários níveis de serviços RTK e DGPS Possui mensagens reservadas para transmissão de dados proprietários Mais eficiente que a versão 2.3, pois está preparado para um maior número de aplicações, como por exemplo RTK e DGPS em redes. Fonte adaptada de Lachapelle (2004) Não possui mensagens reservadas para transmissão de dados em formato proprietário Observando a Tabela 11 pode-se perceber que o RTCM versão 2.3 tem a limitação de não suportar RTK em rede, ele só deve ser utilizado no RTK ou DGPS convencional, quando uma única estação de referência é utilizada (RTCM, 2001).

61 4 COMUNICAÇÃO VIA INTERNET E O PROTOCOLO NTRIP 51 Essa pesquisa utilizará a Internet como meio de comunicação entre as estações base e a estação móvel. Assim, nesse capítulo serão apresentados os conceitos fundamentais da comunicação através da Internet. Esses conceitos são importantes para que se possa realizar a implementação e adaptação de protocolos que possibilitarão a transmissão dos dados GNSS. Nesse capítulo, também será apresentado o protocolo Ntrip que utiliza os padrões RTCM para realizar o transporte dos dados GNSS via Internet. Os dados no formato RTCM por sua vez são encapsulados no formato HTTP 1.1 para que possam ser transportados. Assim, para entender melhor o funcionamento do NTRIP será apresentada uma descrição do protocolo HTTP. 4.1 Comunicação Via Internet Nos últimos anos com os grandes avanços Internet, no que diz respeito à capacidade de transmissão, é crescente a utilização deste meio de comunicação em aplicações GNSS. Aplicações essas que necessitam do transporte de dados de uma estação para outra, ou de uma rede de estações. A comunicação via Internet possibilita, atualmente, a realização do DGPS, DGPS em rede, RTK e RTK em rede (HU et al, 2002; RETSCHER, 2002). Ela vem substituindo os links de rádio utilizados para o envio de dados ou correções diferenciais no RTK e DGPS. A Internet também é utilizada para transferência de dados como os que são disponibilizados pelo IGS. Um exemplo desses dados são as efemérides IGU que podem ser utilizadas em aplicações GPS em tempo real. Devido a sua acurácia ser bastante superior a das efemérides transmitidas, às mesmas serão utilizadas nesta pesquisa. A transmissão e as operações realizadas com dados através da Internet são baseadas na padronização através de protocolos. São os protocolos que organizam o envio e o recebimento de informações dentro da Internet. O TCP (Transmission Control Protocol Protocolo de Controle de Transmissão) e o IP (Internet Protocol Protocolo de Internet)

62 52 são os dois protocolos mais conhecidos e mais importantes da Internet. Dada a importância de protocolos para a Internet, é imprescindível o entendimento do que cada protocolo faz. Na Internet esses padrões são desenvolvidos pela IETF (Internet Engineering Task Force Força de Trabalho de Engenharia de Internet) (KUROSE e ROSS, 2006). O IETF é o responsável pelo desenvolvimento de protocolos como o TCP, IP, HTTP (HyperText Transfer Protocol Protocolo de Transferência de Hipertexto) e o SMTP (Simple Mail Transfer Protocol Protocolo de Simples Transferência de Correio). Os protocolos básicos da Internet são alocados em camadas distintas. A divisão dos protocolos de Internet em camadas provê uma modularidade de cada camada fazendo com que fique muito mais fácil modificar a implementação do serviço de cada nível, desde que a camada (ex: TCP) forneça o mesmo serviço para a camada que está acima (ex: HTTP) e use o mesmo serviço que da camada que está abaixo (ex: IP). Deste modo, quando a implementação de uma camada é alterada, o restante do sistema fica inalterado (KUROSE e ROSS, 2006). A Tabela 12 apresenta as camadas da Internet. Tabela 12 - Camadas da Internet. Aplicação HTTP, FTP, NTRIP... Transporte TCP e UDP Rede IP Enlace de dados Switch Física Equipamentos (hardware) Uma camada de protocolo pode ser implementada em software, em hardware, ou em uma combinação dos dois. Protocolos de camadas de aplicação como HTTP e SMTP em geral são implementados em sistemas finais (ex: computadores, receptores GPS, celulares, etc.) e o mesmo acontece com protocolos da camada de transporte. A camada física e de enlace são implementadas em placas de interface de rede. A camada de rede quase sempre tem uma implementação mista de hardware e software (KUROSE e ROSS, 2006). Nas próximas seções são descritas, rapidamente, as camadas físicas, de enlace de dados, de rede, de transporte e, mais detalhadamente, a camada de aplicação (KUROSE e ROSS, 2006). A implementação de aplicações, como por exemplo, o DGPS e o RTK requerem alterações na camada de aplicação da Internet, por esse motivo nessa pesquisa a camada de aplicação será descrita com maiores detalhes.

63 Camada de Aplicação A camada de aplicação é onde se encontram as aplicações e seus protocolos. Nesta camada pode-se encontrar protocolos como o HTTP (que provê requisição e transferência de documentos via Web), o SMTP (que provê o envio de mensagens de correio eletrônico) e o FTP (que provê a transferência de arquivos entre dois sistemas finais da Internet, como por exemplo, dois computadores). Esses são alguns dos protocolos de aplicação padrões mais utilizados comumente. No entanto, nada impede que uma pessoa ou empresa defina seu próprio protocolo de aplicação que seja mais adequado as suas necessidades (KUROSE e ROSS, 2006). Essa camada define uma interface bem estruturada para que aplicações em computadores diferentes se comuniquem. Alguns exemplos podem ser citados: abrir um arquivo remotamente, requisitar uma pagina da Web, enviar um , etc. Os protocolos da camada de aplicação simplificam a comunicação entre os processos em uma rede e determinam como esses devem interagir (DEITEL, 2005). Para entender melhor as funções da camada de aplicação, nas seções a seguir serão apresentados alguns dos conceitos mais importantes envolvidos com a mesma Arquitetura de aplicações de rede Ao iniciar o desenvolvimento de uma nova aplicação o programador pode optar por escolher uma das arquiteturas mais utilizadas em aplicações modernas de rede, essas arquiteturas são (KUROSE e ROSS, 2006): cliente-servidor nessa arquitetura sempre há um hospedeiro (ex: um computador) em funcionamento, que é denominado servidor. O servidor é responsável por atender as requisições de diversos hospedeiros, que são denominados clientes. Os clientes podem estar sempre em funcionamento ou somente às vezes. Um exemplo bastante comum de aplicação cliente servidor é a aplicação Web. Quando um hospedeiro cliente realiza uma requisição de um determinado objeto, o servidor Web se encarrega de responder essa requisição enviando o objeto requisitado. Em uma aplicação cliente-servidor os clientes não se comunicam diretamente, ou seja, a comunicação é realizada sempre através do servidor. Outra característica dessa arquitetura é que o servidor tem um IP fixo e bem conhecido.

64 54 P2P (peer-to-peer) nesse tipo de arquitetura não existe um servidor sempre em funcionamento para atender aos clientes. Ao contrário da arquitetura cliente-servidor, na arquitetura P2P, pares arbitrários de hospedeiros, denominados peers, comunicam-se diretamente entre si. Nesse tipo de aplicação nenhuma das máquinas envolvidas na aplicação precisa estar sempre em funcionamento e ter um IP fixo. A característica mais importante dessa arquitetura é a sua escalabilidade. Isso significa que em uma aplicação P2P cada novo par de hospedeiros que gera novas requisições também geram capacidade de serviço. Em uma aplicação P2P de compartilhamento de arquivos, pode haver a participação de milhões de pares hospedeiros, que podem participar da uma comunidade de compartilhamento de arquivos, sendo que cada um contribui como se fosse um servidor. Ou seja, todos hospedeiros que requisitam arquivos, também têm que atender a requisições feitas pelos outros hospedeiros. Híbrida cliente-servidor/p2p um exemplo desse tipo de arquitetura é mencionado por Kurose e Ross (2006). Esse exemplo trata-se das mensagens instantâneas. Esse tipo de aplicação geralmente utiliza uma arquitetura P2P, pois as mensagens são enviadas de um usuário para outro sem passar por um servidor intermediário. Entretanto, quando uma pessoa se cadastra para usar uma aplicação de mensagens instantâneas, o seu cadastro fica em um servidor central, e quando alguém deseja falar com essa pessoa o cliente da mesma procura o cadastro da outra no servidor central para verificar se está on-line Entendendo a comunicação entre processos Segundo Kurose e Ross (2006), no jargão de sistemas operacionais não se diz que são programas que se comunicam através da rede de computadores, mas sim processos. Os processos que estão em sistemas finais distintos comunicam-se através da troca de mensagens através da rede de computadores. Uma aplicação que trabalha em uma rede considera dois tipos de processos, um cliente e outro servidor. O processo que inicia ativamente a comunicação é chamado de cliente e o processo que espera uma requisição de forma passiva, vinda do processo cliente, é chamado processo servidor (KUROSSE e ROSS, 2006; COMER, 2007). Cabe dizer aqui que quando tratamos os processos como clientes e como servidores não estamos nos referindo aos termos cliente-servidor, tipo de arquitetura definida na seção Para exemplificar, em uma aplicação P2P quando um par A requere ao Par B o

65 55 envio de um arquivo qualquer, o Par A é chamado de cliente e o par B é chamado servidor, considerando o contexto dessa seção (KUROSE e ROSS, 2006). A troca de mensagens entre dois processos comumente utiliza uma interface com a rede que provê o envio e o recebimento das mensagens. Essa interface é chamada de Socket Sockets O socket é responsável por fazer a interface entre o processo da camada de aplicação e a camada de transporte. A camada de transporte por sua vez pode utilizar o protocolo TCP ou o UDP. Essa interface também é comumente denominada de Application Programming Interface (API Interface de Programa de Aplicação) entre a aplicação e a rede. Para entender melhor qual a função do socket pode-se fazer uma analogia com uma casa e sua porta. Quando um processo requer o envio de uma mensagem para outro processo em outro hospedeiro, o mesmo faz com que a mensagem seja empurrada porta a fora. Nesse processo é admitido que exista uma infra-estrutura (TCP ou UDP) de transporte do outro lado de sua porta que levará a mensagem pela rede até a porta do processo de destino. Quando a mensagem chega ao hospedeiro destinatário, a mensagem passa através da porta (socket) do processo receptor, que executa a ação sobre a mensagem (KUROSSE e ROSS, 2006; COMER, 2007). Até o momento foram discutidos os principais conceitos envolvidos na camada de aplicação e na próxima seção ( ) será apresentado um dos protocolos de aplicação mais conhecidos, o HTTP. Esse protocolo será apresentado com maiores detalhes, pois é o protocolo utilizado pelo Ntrip para encapsular as mensagens RTCM. O intuito é mostrar como as mensagens RTCM são alocadas dentro das mensagens HTTP HTTP O HTTP (Hyper Text Transfer Protocol Protocolo de Transferência de Hipertexto) é definido no Request for Comments 1945 (RFC1945 Requisição para Comentário) e no RFC2616. Esse protocolo é utilizado para comunicação entre browsers web e servidores web. O HTTP especifica como um cliente e um servidor podem estabelecer comunicação, qual a forma que o cliente requer dados do servidor, como o servidor responde a essa requisição e, por último, como a conexão é encerrada (HAROLD,

66 ). Para isso, o HTTP é implementado em dois softwares distintos: um cliente e outro servidor. Esses dois softwares são capazes de trocar informações entre dois sistemas finais, através da troca de mensagens no formato HTTP. O formato HTTP especifica a estrutura das mensagens e a maneira como o cliente e o servidor trocam essas mensagens. O protocolo da camada de transporte utilizado pelo HTTP é o TCP, ou seja, trata-se de uma aplicação orientada a conexão. Dizer que uma aplicação é orientada a conexão significa que os programas cliente e servidor da aplicação (que estão em sistemas finais diferentes), trocam mensagens de apresentação entre si antes de realizar efetivamente a transmissão dos dados desejados. E que procura garantir a transferência dos dados (KUROSSE e ROSS, 2006; HAROLD, 2005). A comunicação entre o cliente e o servidor inicia-se com a conexão TCP do cliente HTTP com o servidor. Em seguida, estabelecida a conexão, os processos do browser e do servidor acessam o TCP através de suas interfaces sockets. Como mencionado anteriormente, o HTTP não deve se preocupar com a integridade dos dados que são enviados ou recebidos respectivamente pelo cliente e pelo servidor, visto que esse protocolo utiliza o TCP na camada de transporte, que por sua vez deve garantir o envio e o recebimento dos dados. A seguir será apresentado o formato da mensagem de requisição e de resposta do HTTP. O HTTP é um dos protocolos de aplicação mais utilizados, principalmente para acessar dados na World Wide Web. Esse protocolo permite que se realize a transferência de diversos tipos de dados: textos simples, hipertextos, áudio, vídeo, etc (FOROZAN, 2006). Assim, é possível que esse protocolo de Internet transporte dados no formato RTCM, apresentado anteriormente. O formato básico de uma mensagem de requisição HTTP é apresentado na Figura 13.

67 57 Método E URL E Versão cr lf Nome do campo de cabeçalho E valor E fl M Nome do campo de cabeçalho E valor cr fl cr fl Linha de requisição Linha de cabeçalho Linha em branco Linha de entidade HTTP de requisição: Figura 13 Formato geral de uma mensagem de requisição HTTP. Fonte: Kurose e Ross (2006). A seguir são apresentados os detalhes de cada linha do formato geral Método esse campo pode assumir diferentes valores, dentre os quais estão o GET, POST e HEAD. Em sua maioria as mensagens de requisição utilizam o método GET. Um exemplo dessa utilização é quando uma um browser requisita um objeto. O método POST é utilizado quando o cliente quer passar alguma informação para o servidor. E o método HEAD por sua vez é utilizado para obter não o documento ou objeto em si, mas sim informações dos mesmos. Esses são alguns dos exemplos de métodos mais utilizados. Para mais informações sobre diferentes métodos consultar Kurose e Ross (2006) ou Forozan (2006); E (Espaço) espaço em branco que separa os campos da mensagem; URL o URL (Uniform Resource Locator Localização Uniforme de Recursos) é utilizado para identificar o endereço de um sistema final e o caminho onde está localizado um determinado objeto dentro de um sistema final. Esse padrão segue a estrutura da Figura 14. Protocolo :// host : porta / caminho Figura 14 Padrão URL. Um exemplo do padrão apresentado na Figura 14 é: O protocolo que aparece na Figura 14 diz respeito ao protocolo de aplicação utilizado, que no caso é o HTTP. O host diz respeito ao nome do computador em que está localizado a informação que se requisita. A

68 58 porta por sua vez é uma informação opcional e se o número da porta estiver incluído, ele deve ser utilizado. E por fim, o último campo de uma URL é o caminho, que identifica o local onde a informação ou arquivo solicitados estão dentro do servidor (FOROZAN, 2006); Versão o próprio nome desse campo é auto-explicativo e as versões mais utilizadas atualmente são: 0.9, 1.0 e 1.1; cr (carriage return) e fl (linefeed) utilizado no final de cada linha da mensagem para que se passe para a próxima linha; Cabeçalhos da mensagem esses campos das mensagens são utilizados na troca de informações adicionais entre o cliente e o servidor. Um cabeçalho pode conter mais de uma linha e cada linha é formada por um nome seguido de dois pontos, um espaço e o valor do cabeçalho (ver Figura 13 e Figura 16). Uma linha de cabeçalho pode ser de quatro tipos: cabeçalho geral, cabeçalho de operações do cliente (pedido), cabeçalho resposta e cabeçalho de entidade. Uma mensagem de pedido pode ter somente cabeçalhos: geral, de opção do cliente e entidade. Por sua vez a mensagem de resposta pode conter os cabeçalhos: geral, resposta e entidade (FOROZAN, 2006). A seguir será apresenta uma breve descrição de cada tipo de cabeçalho segundo Forozan (2006): Cabeçalho geral é responsável por fornecer informações genéricas sobre a mensagem e pode ser utilizado tanto para uma mensagem de pedido quanto para um mensagem de resposta; Cabeçalho de opções do cliente esse cabeçalho pode ser utilizado somente para mensagens de pedido. O cabeçalho de opções especifica a configuração e as informações do formato do documento do cliente; Cabeçalho de resposta como o próprio nome diz esse é somente um cabeçalho utilizado para mensagens de resposta. O mesmo determina a configuração do servidor e as informações especiais sobre o pedido. Cabeçalho de entidade contêm informações do corpo do documento. Esse cabeçalho é comumente utilizado em mensagens de resposta. No entanto, às vezes é utilizado em mensagens de pedido, que contêm corpo. Para melhor entender como é montada uma mensagem de requisição é apresentada a seguir (Figura 15) um exemplo adaptado, retirado de Kurose e Ross (2006):

69 59 Figura 15 Mensagem HTTP de requisição Fonte: Adaptado de Kurose e Ross (2006). Como se pode observar na Figura 15 a mensagem é escrita em ASCII de modo que pode ser facilmente lida. Essa mensagem tem 5 linhas, no entanto, ela pode ter muito mais que 5 linhas ou menos que 5 linhas. Como descrito anteriormente, essa mensagem utiliza um método de requisição GET, em seguida tem-se o caminho de onde se encontra o objeto no servidor e por fim a versão do formato HTTP. Após a primeira linha, as outras 4 linhas são de cabeçalho. O Host indica o servidor (hospedeiro) onde se encontra o objeto. A linha de cabeçalho Connection: close indica ao servidor que o mesmo feche a conexão após o envio do objeto. O cabeçalho User-agent: indica o tipo de browser que está fazendo a requisição ao servidor, que no caso é o Mozilla/4.0. E por fim o cabeçalho Accept-language: significa que o cliente deseja receber uma versão em francês do objeto, se este existir no servidor, caso contrário, o cliente receberá a versão default (KUROSE e ROSS, 2006). Essa mensagem não contém uma entidade a ser enviada, como a maioria das mensagens de requisição. Realizada a descrição da estrutura básica da mensagem de requisição, descreve-se agora a mensagem de resposta. A composição básica dessa mensagem é apresentada na Figura 16. GET /somedir/rtcm3.1 HTTP/1.1 Host: Connection: close User-agent: Mozilla/4.0 Accept-language: fr versão E código de estado E frase cr lf Nome do campo de cabeçalho: E valor cr fl M Nome do campo de cabeçalho: E valor cr fl cr fl Linha de Estado Linhas de cabeçalho Linha em branco Corpo da entidade Figura 16 Formato geral de uma mensagem de resposta HTTP. Fonte Kurose e Ross (2006).

70 60 A mensagem de resposta é construída por uma linha de estado, linhas de cabeçalho, uma linha em branco e quando necessário um corpo. As linhas de estado contem a versão da mensagem HTTP, um campo para o código do estado e uma mensagem de estado correspondente (frase), ver Figura 16. As linhas de cabeçalho já foram descritas acima. E o corpo do documento é onde efetivamente serão alocadas as informações que se quer transmitir do servidor para o cliente. A seguir são descritos os componentes da linha de estado da mensagem: Versão HTTP esse campo é o mesmo campo que o da mensagem de pedido; Código de estado é um campo de três dígitos e é responsável por indicar o resultado da requisição do cliente; Frase de estado é utilizado para explicar o código de estado na forma de texto. A seguir vamos dar alguns dos principais códigos e frases utilizados em mensagens de respostas (KUROSE e ROSS, 2006; FOROZAN, 2006): 200 OK - significa que a requisição foi bem-sucedida e a informação será entregue com a resposta; 301 Moved Permanently significa que o objeto requisitado foi movido para uma nova URL. E um novo URL deve ser especificado no cabeçalho da mensagem de resposta. Assim, o software do cliente recuperará automaticamente o novo URL; 400 Bad Request significa que o cliente usou uma sintaxe imprópria para fazer a requisição ao servidor. Ou seja, o servidor não pôde entender qual o objeto requerido; 404 Not Found o objeto requisitado não existe no servidor. Esse é um erro muito comum e pode indicar um link ruim ou um erro de tipo de URL; 505 HTTP Version Not Supported significa que a versão da mensagem HTTP requisitada pelo cliente não é compatível com a do servidor. Na Figura 17 é apresentado um exemplo de mensagem de resposta HTTP.

71 61 HTTP/ OK Connection: close Date: Thu, 03 Jul :00:15 GMT Server: Apache/ (Unix) Last-Modified: Sun, 5 May :23:24 GMT Content-Length: 6821 Content-Type: binary Linha em branco (mensagem RTCM3.1 ) Figura 17 Mensagem HTTP de resposta. Fonte: Adaptado de Kurose e Ross (2006). Do apresentado, pode-se considerar que primeira linha da Figura 17 é auto-explicativa. A segunda linha, Connection: close é utilizada pelo servidor para que o cliente saiba que a conexão TCP será fechada após o envio da mensagem. O cabeçalho Date: representa a hora e a data que a resposta HTTP foi criada e enviada pelo servidor. O cabeçalho Server: indica qual o servidor utilizado para gerar a mensagem. Last-Modified: indica a data da última modificação ou a hora em que o objeto foi criado. Já o cabeçalho Content-Length: representa o número de bytes do objeto que está sendo enviado. E por fim, o cabeçalho Content-Type: indica o tipo de arquivo que está sendo enviado no corpo da entidade Camada de Transporte A camada de transporte é responsável pela comunicação de um sistema final com outro sistema final de dois hospedeiros (hospedeiros podem ser: computadores, celulares, etc.). Essa camada recebe os dados de uma camada de aplicação, subdivide esses dados em frações que facilitam o transporte, anexa informações de controle a cada fração e as envia à camada de rede (DEITEL, 2005a). Existem dois protocolos associados à camada de transporte na Internet, que são o TCP e o UDP. O TCP é um serviço orientado a conexão, ou seja, esse protocolo provê um serviço de verificação da entrega garantida de mensagens da camada de aplicação ao destino, ou seja, ele faz a compatibilização das velocidades das mensagens do remetente e do receptor. O TCP também fragmenta as mensagens longas em segmentos mais curtos e fornece mecanismos de controle de congestionamento, de modo que uma origem regula sua velocidade de transmissão quando a rede está congestionada (KUROSE e ROSS, 2006).

72 62 O UDP proporciona um serviço não orientado à conexão para as suas aplicações. Esse protocolo não garante a entrega e nem a seqüência de dados enviadas do remetente ao receptor, a aplicação que o utiliza deve ficar responsável por isso. Todavia, o UDP apresenta uma conexão mais rápida por não realizar verificações de entrega como o TCP (KUROSE e ROSS, 2006). Atualmente, a maioria das aplicações da Internet utiliza o protocolo TCP por ser mais confiável e garantir a entrega dos dados, embora prejudique a velocidade da transmissão. O serviço UDP vem sendo utilizado em aplicações como as de multimídia que estão surgindo, telefone por Internet e videoconferência, pelo fato de dispor de maior velocidade na transmissão dos dados e considerando que tais aplicações são tolerantes a perda de dados. A Tabela 13 apresenta uma comparação entre os protocolos TCP e UDP. UDP Serviço sem conexão; nenhuma sessão é estabelecida entre os hosts. UDP não garante ou confirma a entrega ou seqüência os dados. Tabela 13 - Comparação entre UDP e TCP Os programas que usam UDP são responsáveis por oferecer a confiabilidade necessária ao transporte de dados. UDP é rápido, necessita de baixa sobrecarga e pode oferecer suporte à comunicação ponto a ponto e ponto a vários pontos. Fonte: Modificado de Kurose e Ross, TCP Serviço orientado por conexão; uma sessão é estabelecida entre os hosts. TCP garante a entrega através do uso de confirmações e entrega seqüenciada dos dados. Os programas que usam TCP têm garantia de transporte confiável de dados. TCP é mais lento, necessita de maior sobrecarga e pode oferecer suporte apenas à comunicação ponto a ponto Camada de Rede Os protocolos de camada de transporte da Internet (TCP ou UDP) de uma determinada máquina de origem passam um segmento de camada de transporte e um endereço de destino à camada de rede. A camada de rede da Internet é responsável pela movimentação, de uma máquina para a outra, de pacotes de camadas de rede conhecidos como datagramas. Datagramas são formados por segmentos, passados pela camada de

73 63 transporte para camada de rede, somados a cabeçalhos adicionados pela camada de rede. Isso funciona como se fosse uma pessoa que envia uma carta com um endereço de destinatário. A camada de rede então realiza o serviço de entrega do segmento à camada de transporte na máquina destinatária (KUROSE e ROSS, 2006). A camada de rede da Internet é composta por dois componentes principais. Um desses componentes define os campos no pacote que será enviado e o modo como os sistemas finais e como os roteadores agem nesses campos. Este é o famoso protocolo IP. O protocolo IP é único e todos os elementos que tem uma camada de rede devem executar esse protocolo. O outro componente é o protocolo de roteamento, que determina as rotas que os pacotes seguem entre as origens e os destinos. Pode-se fazer uma analogia como a determinação do melhor caminho para ir de um ponto a outro dentro de uma cidade. A Internet possui muitos protocolos de roteamento. Embora a camada de rede contenha a definição do datagrama IP e inúmeros protocolos de roteamento, ela é simplesmente denominada de camada IP (KUROSE e ROSS, 2006) Camada de enlace A camada de rede da Internet roteia um datagrama por meio de uma série de comutadores de pacotes, que são denominados por roteadores na Internet, entre a origem e o destino. O transporte de um pacote realizado pela camada de rede de um nó (sistema final ou comutador de pacotes) ao nó seguinte na rota depende dos serviços da camada de enlace. Especificamente, em cada nó, a camada de rede passa o datagrama para a camada de enlace, que o entrega, ao longo da rota, ao nó seguinte, no qual o datagrama é passado da camada de enlace para a de rede. Logo, pode-se dizer que essa camada é responsável por transformar um datagrama em uma representação adequada para o meio de transmissão específico e por enviar essa representação através do meio. A camada de enlace é responsável ainda por transformar novamente a representação no computador receptor em correntes de bits que possam ser interpretadas pelas três camadas superiores da pilha do TCP. Devido ao fato dos meios de transmissão serem entidades físicas, são suscetíveis a interferências que podem causar erros. A camada de enlace tenta detectar e, se possível, corrigir esses erros (DEITEL, 2005a). Os serviços realizados pela camada de enlace dependem do protocolo específico empregado no enlace. Alguns protocolos garantem a entrega garantida entre os

74 enlaces, ou seja, desde o nó transmissor, passando por um único enlace, até o nó receptor (KUROSE e ROSS, 2006) Camada física A camada física define como os dados das mensagens RTCM SC-104 versões 3.1 são transportados ao nível eletrônico e mecânico. Por exemplo: UHF, Modem de VHF, link de Satélite, cabo fixo, etc. Isto também é determinado pelo provedor do serviço, que define esta camada de forma apropriada para a aplicação (RTCM, 2007). Para o caso da presente pesquisa o transporte será realizado por meio da Internet. Dessa forma as dados serão transmitidos parte por cabos fixos (cabos da rede da Internet) e parte por comunicação sem fio como, por exemplo, conexões de serviços de telefonia celular. 4.2 Ntrip Nos últimos anos, com o desenvolvimento da Internet e conseqüentemente da comunicação via Internet, vem crescendo cada vez mais a utilização deste meio em aplicações GNSS, incluindo o DGPS (KECHINE, TIBERIUS e VAN DER MAREL, 2003; HADA et al, 1999; YAN, 2006). A Internet se apresenta como uma alternativa ou complemento aos links de rádio utilizados para o envio de correções diferenciais no DGPS. A transmissão e as operações realizadas com dados através da Internet são baseadas na padronização através de protocolos. São os protocolos que organizam o envio e o recebimento de informações dentro da Internet, como mencionando anteriormente. O protocolo Ntrip por usa vez utiliza o formato das mensagens HTTP para encapsular os dados RTCM e de forma lógica aproveita as camadas da Internet abaixo da camada de aplicação. Este protocolo é composto por três tipos de elementos funcionais denominados de NtripClient, NtripServer e NtripCaster (Figura 18).

75 65 NtripClient 1 NtripClient N Trans. HTTP NtripCaster Provedor do serviço de difusão via HTTP Trans. HTTP NtripServer 1 NtripServer N Estação Base 1 Estação Base N Figura 18 Distribuição de dados por Ntrip. O NtripServer é responsável por se comunicar com o receptor e enviar os dados do mesmo para o NtripCaster. Os dados são enviados no formato RTCM. O NtripClient por sua vez é responsável por acessar o NtripCaster e obter os dados para uma determinada aplicação. O NtripClient é utilizado em campo, por exemplo para que o usuário acesse os dados das estações de referência. O NtripCaster funciona como um servidor HTTP e os programas NtripClient e o NtripServer são baseados no princípio cliente/servidor, conforme o conceito clássico de comunicação via Internet (LENZ, 2004; WEBER, GEBHARD e KALAFUS, 2005). O processo servidor, programa em execução em um computador, é um provedor de um serviço oferecido a um processo cliente que o requisita. O NtripCaster é um software que recebe os dados dos NtripServers que são gerados pelas estações base. Vale dizer aqui, que as estações base são chamadas na literatura em inglês de NtripSource, quando se fala no conceito envolvido no Ntrip. Uma vez que o NtripCaster recebe os dados das bases ele é responsável por administrar e manusear dados de cada estação base, senhas de acesso dos NtripClients, e o acesso propriamente dito dos NtripClients ao NtripCaster (WEBER et al, 2006). O NtripCaster é baseado no software Icecast (para maiores destalhes sobre Icecast consulte desenvolvido utilizando o GNU (General Public License). O propósito do Icecast é replicar fontes de dados para até milhares ou mais simultaneos clientes (ex: os usuários das estações móveis no DGPSR) acessando poucas centenas de fontes (ex: as estações base GPS). A conecção de rede entre a fonte, o Icecast, e os clientes são baseadas no HTTP, TCP e IP. O servidor Icecast foi desenvolvido

76 66 originalmente para disseminar dados MP3 (Moving Picture Experts Group Audio Layer 3) codificados a uma taxa de transferência de 32 kbit/s até 128 kbit/s (WEBER et al, 2006). O NtripCaster foi implementado a partir de uma adaptação do Icecast, o qual suporta a disseminação dos dados GNSS a uma taxa de aproximadamente 0,5 até 5 kbit/s. O NtripCaster é capaz de disseminar dados como: correções DGNSS RTCM, correções RTCM para RTK, correções RTCA (Radio Technical Commission for Aviation Services) EGNOS e WAAS, dados brutos dos receptores, dados de orbitas ultra-rápidas dos satélites no formato SP3 (Standard Product 3) e dados no formato RINEX (WEBER et al, 2006). Para que o usuário possa acessar os dados em tempo real utilizando o NtripClient é necessário que o mesmo tenha a capacidade de acessar a Internet em campo. O acesso à infra-estrutura de comunicação disponibilizada pela Internet pode ser feito utilizando, por exemplo: celulares, Smartphones, PDAs (Personal Digital Assistants) e Laptops. Além disso, novos equipamentos GPS já se encontram disponíveis no mercado com a capacidade de se comunicar com outros equipamentos, por exemplo, com um celular via interface sem fio como o Bluetooth.

77 67 5 DADOS UTILIZADOS E METODOLOGIA EMPREGADA 5.1. Rede GNSS/SP Para alcançar os objetivos propostos serão utilizadas dados das estações de referência da rede GNSS implantada no oeste do estado de São Paulo (Rede GNSS/SP) (Figura 19). Figura 19 - Configuração da rede GNSS/SP. A Rede GNSS/SP foi desenvolvida com o intuito de ampliar o número de estações ativas no estado de São Paulo e proporcionar a infra-estrutura necessária para o desenvolvimento de pesquisas e aplicações dentro do contexto de posicionamento geodésico. É resultado de projetos FAPESP (Processos 2004/ e 2004/ ), desenvolvidos no Departamento de Cartografia da FCT/UNESP, além do projeto temático (Processo 2006/ ) que envolve a FCT/UNESP, USP-Poli, USP-Esalq e INPE- CPTEC. Com a configuração atual da Rede GNSS/SP podem ser realizados estudos atmosféricos, em especial o cálculo do atraso troposférico e do conteúdo total de elétrons (TEC), bem como pesquisas de monitoramento das velocidades das placas

78 68 tectônicas, estudo de séries temporais, georreferenciamento de imóveis rurais, levantamentos cadastrais, levantamentos topográficos, etc. Além disso, existe a possibilidade de utilizar os dados para propósitos operacionais como, por exemplo, no RTK em rede ou DGPS em rede (tempo real ou pós-processado), como é o caso dessa pesquisa. Mas, espera-se que em breve um número maior de estações seja disponibilizado no estado de São Paulo, o que irá beneficiar ainda mais tais estudos. No que se refere aos dados coletados pelos receptores da rede, estes são disponibilizados através da internet na página < para pósprocessamento. São disponibilizados arquivos RINEX a cada uma hora com intervalo de coleta de 1 segundo e arquivos RINEX a cada dia com intervalo de coleta de 15 segundos. Além disso, os dados de todas as estações da rede podem ser acessados em tempo real na internet através do protocolo Ntrip. Para mais informações sobre os equipamentos utilizados na rede, locais de implantação das estações, obtenção de dados, dentre outros consulte a página do GEGE (Grupo de Estudo em Geodésia Espacial) < Metodologia Empregada Para realizar o DGPSR foi utilizada a estrutura do NtripCaster do Laboratório de Geodésia Espacial (LGE) da Unesp. Este NtripCaster acessa todas as estações de referência da Rede GNSS/SP via NtripServer. Posteriormente o NtripCaster se encarrega de disseminar os dados, das estações conectadas, via Internet. Uma vez que os dados da rede são continuamente emitidos para a rede de Internet, qualquer usuário Ntrip poderá acessálos utilizando o NtripClient. No DGPS as correções são enviadas ao usuário, o qual as aplica às suas observações e realiza o posicionamento. No DGPSR é necessário interpolar as correções da rede para a posição aproximada do usuário (seção 2.3). Assim, devido a este fato o receptor móvel ou seu controlador deve ter a capacidade de calcular as correções para cada estação da rede e interpolá-las para sua posição aproximada. Neste projeto, o DGPSR foi realizado utilizando estações da rede GNSS/SP. O receptor móvel foi simulado também utilizando uma das estações da rede.

79 69 A Figura 20 apresenta o fluxo dos dados nessa aplicação. Como pode-se notar, os dados das estações de referência são enviados para o NtripCaster que por sua vez também utiliza a Internet para levar os dados até o usuário. Nessa pesquisa, como se utiliza uma das estações da rede como móvel, os dados da mesma também são transmitidos via NtripCaster e recebidos pelo BNC. Vale ressaltar que os dados da estação considerada como móvel são utilizados na geração da correção final. Est.de Refer. 2 Est. de Ref. 3 Internet Usuário NtripCaster e Computador Central Est. de Ref. 1 - envio das correções das estações para o computador central (CC) via NtripServer. - correções calculadas para cada estação da rede. - estações de referência da rede. - estações móveis com capacidade de processamento para interpolação. Figura 20 - DGPSR via Internet. Para o desenvolvimento do DGPSR foi utilizado uma adaptação do software Ntrip BNC (Figura 21) disponível no site do BKG. Este software tem a característica de baixar dados de diferentes estações simultaneamente em tempo real. Utilizando o código disponível deste software, adaptações e alterações foram realizadas. As alterações e adaptações foram realizadas nas seguintes bibliotecas: bncrinex, bncthread e bncwindows. Destas bibliotecas a mais utilizada foi a bncrinex, a partir da qual fez-se adaptações para realizar o DGPSR. Na biblioteca original bncrinex os dados são convertidos e escritos em

80 70 arquivos RINEX correspondentes a cada estação selecionada no mesmo. No entanto, nessa biblioteca os dados são gravados nos arquivos RINEX, assim que são recebidos, e logo em seguida são apagados das variáveis. Figura 21 - DGPSR via Internet. A partir do bncrinex foi construída a biblioteca dgpsr, na qual, implementou-se uma série de variáveis estáticas afim de armazenar simultaneamente dados de no mínimo uma época para cada estação utilizada no DGPSR. Além das observações, código C1 de cada estação, as correções e informações necessárias para o DGPSR são armazenadas em variáveis estáticas. Como parte das adaptações realizadas, introduziu-se na biblioteca dgpsr a chamada a uma biblioteca de leitura e interpolação das efemérides preditas IGU. Essa biblioteca foi desenvolvida pelo autor dessa dissertação em seu projeto de IC.

81 71 Uma vez implementada a leitura dos dados de observações de cada estação da rede e das coordenadas dos satélites realizou-se todos os cálculos necessários para a obtenção das correções interpoladas para a posição da estação escolhida como móvel. Em seguida, implementou-se o posicionamento por ponto utilizando as observáveis da estação móvel corrigidas, para obtenção das coordenadas determinadas utilizando o conceito de DGPSR, de acordo com a teoria apresentada no capítulo 2 dessa dissertação. O software BNC foi implementado em uma estrutura de orientação a objetos C++. O compilador utilizado é o gcc para Linux e o MinGw para Windows. Este software utiliza o conceito de Thread9 para realizar a obtenção dos dados de forma concorrente. Não convêm apresentar o conceito de Thread nesta pesquisa. No entanto, o mesmo será discutido nas considerações finais, devido ao cuidado que se deve ter ao realizar a implementação do DGPSR utilizando este tipo de estrutura em C++. Realizadas as implementações necessárias, procedeu-se a realização de experimentos utilizando o DGPSR. Tais experimentos são apresentados no capítulo 06. Nestes experimentos pretende-se avaliar o desempenho do DGPSR em diferentes configurações de redes com respeito a acurácia obtida e com relação a latência devido ao tempo de envio das correções via Internet. 9 Threds são unidades de concorrência conhecidas processos leves, pois compartilham a mesma área de código e de dados de um mesmo proce sso. De forma simplificada pode-se dizer que uma mesma área de código será solicitada para execução várias vezes ao mesmo tempo.

82 72 6 EXPERIMENTOS E ANÁLISE DOS RESULTADOS Para analisar a metodologia proposta nessa pesquisa foram realizados experimentos com diferentes configurações de estações, como segue: Duas configurações diferentes de redes de estações (uma com quatro estações de referência e outra com três estações ); Uma configuração com apenas duas estações de referência; Uma última configuração com apenas uma estação de referência. Foram empregadas nos testes cinco estações da rede GNSS/SP (Figura 19), que são: PPTE (Presidente Prudente), ILHA (Ilha Solteira), SJRP (São José do Rio Preto), LINS (Lins) e SPAR (Araçatuba). Dentre essas estações, a estação SPAR foi utilizada simulando um usuário do sistema (estação móvel). Portanto, seus dados foram baixados pelo BNC para serem utilizados como rover, mas na implementação do DGPSR os dados dessa estação não são considerados no cálculo das correções DGPSR. Inicialmente foi realizado o DGPSR utilizando todas as estações de referência selecionadas (PPTE, SJRP, ILHA e LINS), esta configuração foi denominada de R4. As demais configurações foram formadas retirando-se uma das estações de referência. Desta forma formaram-se 4 configurações diferentes que são apresentadas na Tabela 14. Tabela 14 Configuração das redes utilizadas nos experimentos. Configuração de rede Estações base utilizadas R1 LINS R2 LINS e SJRP R3 LINS, SJRP e ILHA R4 LINS, SJRP, ILHA e PPTE As informações de distância entre as estações de referência e a estação utilizada como móvel são apresentadas na Tabela 15.

83 73 Tabela 15 Distância entre as estações base e estação móvel Linha de Base Distância LINS-SPAR 90 km SJRP-SPAR 120 km ILHA-SPAR 126 km PPTE-SPAR 140 km Para uma melhor visualização da geometria das estações, a Figura 21 apresenta um croqui com as distâncias aproximadas entre as mesmas. ILHA SJRP 126 km 120 km 90 km 140 km LINS PPTE Figura 22 Configuração das estações utilizadas e comprimento das linhas de base. Os experimentos foram realizados com dados dos dias 02 e 03 de fevereiro de A taxa de atualização utilizada nos experimentos foi de 10 segundos. Para o dia 02 o início da coleta dos dados deu-se por volta das 10 horas e 40 minutos UTC e o término por volta de 22 horas e 30 minutos. Para o dia 03 o início dos experimentos foi as 14 horas e o término as 00 horas UTC. Apesar do horário de início e término dos dados serem diferentes, o que se buscou foi realizar o DGPSR englobando o horário do dia em que se tem maiores influências por parte da Ionosfera. Este horário está entre 12 e 15 horas locais (UTC - 3). A seguir são ilustrados os resultados obtidos para o dia 02 de fevereiro. Nos gráficos da Figura 22 são apresentadas as resultantes horizontais (RH) e resultantes

84 74 altimétricas (RA) das discrepâncias entre as coordenadas consideradas verdadeiras da estação SPAR e as coordenadas obtidas. Analisando os gráficos da Figura 22 é possível notar melhorias nos resultados apresentados pela configuração R4, configuração esta que é formada pelo maior número de estações de referência. Realizando um análise detalhada dos gráficos é possível ainda notar que a melhoria é mais significativa por volta das 16 horas UTC, que correspondem as 13 horas locais. Neste período do dia a atividade solar é maior, o que provoca variações mais intensas nos resultados devido aos efeitos da ionosfera. Assim, as melhorias podem ser notadas nitidamente em planimetria (RH) e também em altimetria (RA). É possível ainda observar que, como relatado na literatura sobre ionosfera, a componente altimétrica é a mais afetada e que no caso em que se utilizou um maior número de estações de referencia esse efeito foi significativamente reduzido nos períodos de maior influência da ionosfera, período este que se dá por volta das 16 UTC (13 horas locais). Os gráficos mostram ainda picos de magnitude bastante elevadas por volta das 16 horas UTC (13 horas locais) e que estes picos não tem correlação com as discrepâncias em planimetria para este mesmo período de tempo. Isso mostra que a influência significativa provocada pela ionosfera em um determinado intervalo de tempo provoca variações drásticas em altimetria, no entanto, essas variações em planimetria são mais suaves. Para este dia de testes os melhores resultados foram apresentados para a configuração com maior número de estações base (R4) e o pior para a configuração com apenas uma estação de referência (R1). Além das discrepâncias para componentes horizontais e altimétricas, apresentadas na Figura 23, foram gerados gráficos das latências (Figura 24) referentes aos envios dos dados de cada estação de referência. Para efeito de análise serão apresentados os gráficos gerados para cada estação de referência da configuração R4. Os demais resultados não serão apresentados pois foram similares.

85 75 Figura 23 Resultados do DGPSR para as 4 configurações adotadas dia 02 de fevereiro. Figura 24 Latência calculada para as quatro estações base utilizadas na configuração R4- dia 02.

86 76 Analisando os gráficos da Figura 24 pode-se notar duas séries de dados para cada estação, uma com latências com valores de aproximadamente 2 segundos, e outra com valores de aproximadamente 12 segundos. A série com valores próximos de 2 é a série que contém os valores reais de tempo transcorrido entre a emissão dos dados pela estação de referência, passando pelo NtripCaster e chegando até o computador onde os dados foram processados. Já a série que têm valores com aproximadamente 12 segundos é formada pelos valores de latência obtidos quando o dado da estação base não foi atualizado para a última época rastreada pelo receptor móvel. Ou seja, considere que a observação da estação móvel foi obtida as 12 horas 00 minutos e 00 segundos (t m ) e a última correção referente a estação PPTE, por exemplo, foi obtida a partir de dados rastreados as 11 horas 59 minutos e 50 segundos (t b ). Logo a latência de aproximadamente 12 segundos foi obtida da seguinte forma: t m - t b mais o intervalo de tempo de envio da estação base até a sua recepção na estação móvel, que para os experimentos em questão foram de aproximadamente 2 segundos. Analisando novamente os gráficos das figuras 22 e 23 conclui-se que as latências de envio das correções não influenciaram no resultados obtidos no DGPSR. Este fato se deve a baixa variabilidade das correções calculadas. Isso significa que as condições da Troposfera e da Ionosfera não se alteram significativamente em um curto período de tempo. Esta informação está de acordo com experimentos relatados na literatura sobre DGPS, veja Dal Poz et al. (2003), como já apresentado na seção 2.2. A seguir (Tabela 16) são apresentados os Erros Médios Quadráticos (EMQ) das discrepâncias cada configuração da rede referente ao experimentos do dia 02. Tabela 16 EMQ para os 4 configurações utilizadas dia 02. RMS Latências H A 3D PPTE ILHA SJRP LINS R4 0,34 0,67 0,75 9,52 8,73 8,51 11,98 R3 0,81 0,85 1,18-12,32 9,53 10,89 R2 0,48 0,91 1, ,5 19,62 R1 0,50 0,93 1, ,48 Como pode-se observar na Tabela 16, as médias das discrepâncias apresentadas resumem os resultados e comprovam que foram obtidas melhorias ao utilizar a configuração R4. A configuração R4 apresentou melhorias médias de 32% com relação a R1 para a resultante planimétrica e de 28% em altimetria. Já para a configuração R3 as melhorias em planimetria e em altimetria foram respectivamente 29% e 27%. E por fim, em relação a

87 77 configuração R2, foram obtidas as seguintes melhorias em planimetria e altimetria: 58% e 22%. A seguir serão apresentados os resultados obtidos para o dia 03 de fevereiro. O formato dos gráficos serão idênticos ao apresentados para o dia 02. Como pode-se observar na Figura 24, a configuração R4 apresentou os melhores resultados. Pode-se notar também que as maiores melhorias foram obtidas para os dados processados por volta das 16 hora UTC, ou seja 13 horas locais. Além da configuração R4, as configurações R3 e R2 também apresentaram melhores resultados que a configuração R1, configuração que considera apenas uma das estações de referência. Com relação a componente vertical pode-se aplicar a mesma explicação apresentada nos experimentos do dia 02/02/2010. Figura 25 - Resultados do DGPSR para as 4 configurações adotadas dia 03 de fevereiro.

88 78 Mais uma vez com o intuito de avalizar o efeito das variações provocadas pela latência apresenta-se os gráficos mostrando quais foram as latências calculadas para cada estação da rede utilizada na configuração R4. Figura 26 - Latência calculada para as quatro estações base utilizadas na configuração R4- dia 03. Novamente pode-se observar que não há correlação entre as latências calculadas (Figura 26) e as discrepâncias apresentadas nos resultado da configuração R4 (Figura 24), confirmando mais uma vez que a variabilidade dos dados em um curto período de tempo é insignificante. A seguir na Tabela 17 são apresentados os valores médios (M) de discrepâncias e os desvios padrão (DP) para cada configuração da rede referente ao experimentos do dia 03. Tabela 17 EMQ para os 4 configurações utilizadas dia 03. DGPSR Latências H A 3D PPTE ILHA SJRP LINS R4 0,45 1,04 1,13 20,28 16,50 21,29 20,27 R3 0,57 0,95 1,10-18,07 15,64 16,68 R2 0,64 1,13 1, ,18 21,21 R1 0,62 1,28 1, ,48 Analisando a Tabela 17 verifica-se que a configuração R4 apresentou melhorias médias de 28% com relação a R1 para a resultante planimétrica e de 19% em altimetria. Já

89 79 para a configuração R3 as melhorias em planimetria e em altimetria, com relação a configuração R1, foram respectivamente 30% e 08%. E por fim no que se refere a configuração R2, forma obtidas melhorias em planimetria e altimetria de: 21% e uma pequena degradação de 10%, quando comparadas a configuração R1. Pode-se notar que para este dia a altimetria da configuração R3 está melhor que a configuração R4. Para que se possa melhor visualizar os resultados obtidos, as médias dos EMQ s das discrepâncias são apresentadas graficamente na Figura 26. Figura 27 Erro Médio Quadrático das discrepâncias para o dia 02 e 03 de fevereiro. Como exposto na Figura 27 as discrepância horizontais não ultrapassaram 40 cm e as discrepâncias em altimetria estão abaixo de aproximadamente 1 m para a configuração R4. Assim, pode-se concluir que os resultados obtidos para o DGPSR em tempo real são similares ao resultados obtidos nos experimentos realizadas no projeto de Iniciação Cientifica do autor deste texto, com o DGPSR no modo pós-processado (DALBELO, 2005a; DALBELO, 2006b).