um protocolo para integraÇÃo de sistemas de comando e controle
TRANSCRIPT
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
1/85
MINISTÉRIO DA DEFESA
EXÉRCITO BRASILEIRO
DEPARTAMENTO DE CIÊNCIA E TECNOLOGIA
INSTITUTO MILITAR DE ENGENHARIA
CURSO DE MESTRADO EM SISTEMAS E COMPUTAÇÃO
PATRICK BAPTISTA AMARAL DE LARA
UM PROTOCOLO PARA INTEGRAÇÃO DE
SISTEMAS DE COMANDO E CONTROLE
Rio de Janeiro2014
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
2/85
INSTITUTO MILITAR DE ENGENHARIA
PATRICK BAPTISTA AMARAL DE LARA
UM PROTOCOLO PARA INTEGRAÇÃO DE
SISTEMAS DE COMANDO E CONTROLE
Dissertação de Mestrado apresentada aoCurso de Mestrado em Sistemas e Computação doInstituto Militar de Engenharia, como requisito
parcial para obtenção do título de Mestre emSistemas e Computação.
Orientador: Prof. Ricardo Choren Noya - D.Sc.
Rio de Janeiro
2014
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
3/85
2
c2014
INSTITUTO MILITAR DE ENGENHARIAPraça General Tibúrcio, 80 – Praia Vermelha
Rio de Janeiro – RJ CEP: 22290-270
Este exemplar é de propriedade do Instituto Militar de Engenharia, quepoderá incluí-lo em base de dados, armazenar em computador, microfilmar ouadotar qualquer forma de arquivamento.
É permitida a menção, reprodução parcial ou integral e a transmissão entrebibliotecas deste trabalho, sem modificação de seu texto, em qualquer meio que
esteja ou venha a ser fixado, para pesquisa acadêmica, comentários e citações, desdeque sem finalidade comercial e que seja feita a referência bibliográfica completa.
Os conceitos expressos neste trabalho são de responsabilidade do autor e doorientador.
355.33041 Lara, Patrick Baptista Amaral deL318pUm protocolo para integração de sistemas de comando e
controle / Patrick Baptista Amaral de Lara ; orientado porRicardo Choren – Rio de Janeiro: Instituto Militar de Engenharia,2014.
84p. : il.
Dissertação de Mestrado – Instituto Militar de Engenharia:Rio de Janeiro, 2014.
1. Curso de Sistemas e Computação – teses, dissertações. 2.Comando e Controle – sistemas de informação. I. Choren,Ricardo. II. Um Protocolo para Integração de Sistemas deComando e Controle. III. Instituto Militar de Engenharia.
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
4/85
3
INSTITUTO MILITAR DE ENGENHARIA
PATRICK BAPTISTA AMARAL DE LARA
UM PROTOCOLO PARA INTEGRAÇÃO DESISTEMAS DE COMANDO E CONTROLE
Dissertação de Mestrado apresentada ao Curso de Mestrado em Sistemas e
Computação do Instituto Militar de Engenharia, como requisito parcial para
obtenção do título de Mestre em Sistemas e Computação.
Orientador: Prof. Ricardo Choren Noya – D.Sc.
Aprovada em 05 de agosto de 2014 pela seguinte Banca Examinadora:
____________________________________________________________
Prof. Ricardo Choren Noya – D.Sc. do IME – Presidente
____________________________________________________________
Prof. Wallace Anacleto Pinheiro – D.Sc. do IME
____________________________________________________________
Prof. Eduardo Bezerra da Silva – D.Sc. do CEFET/RJ
Rio de Janeiro2014
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
5/85
4
Dedico este trabalho a minha Família.
Ele é fruto do apoio integral de vocês.
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
6/85
5
AGRADECIMENTOS
Aos professores Eduardo Bezerra da Silva e Wallace Anacleto Pinheiro por terem
aceitado participar de minha banca examinadora.
Em especial, ao meu orientador e professor Ricardo Choren Noya, pela atenção
constante e paciente orientação ao longo deste trabalho.
Aos professores Ten Cel Ronaldo Moreira Salles e Maria Claudia Reis Cavalcanti,
Coordenadores do Curso de Pós-Graduação em Sistemas e Computação do IME, por
acreditarem no meu interesse em concluir o curso, mesmo após imprevistos pessoais.
Ao Instituto Militar de Engenharia e a todos os professores e funcionários, que
tornaram possível a realização deste trabalho.
Ao Centro de Análise de Sistemas Navais e a todos os meus colegas de trabalho,
em especial: Comte. Aquino, Luciene Carvalho, Jorge Calvelli e Manoel Pedro Sá,
que me apoiaram incondicionalmente para a concretização deste trabalho.
Aos meus colegas de classe, Edgard Bernardo, Marcus Albert, Diego e Tanilson,
fiéis participantes dos nossos grupos de estudo da sala 2035. Conquistar e
compartilhar o conhecimento com vocês sempre será uma tarefa gratificante.
A Marinha do Brasil, por todas as oportunidades fornecidas para o meu
aprimoramento pessoal e profissional durante o transcurso de minha carreira militar.
Por fim, agradeço especialmente a minha família, pelo seu apoio incondicional.
Patrick Baptista Amaral de Lara
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
7/85
6
“Os que se encantam com a prática sem a ciência são como os timoneiros que entramno navio sem timão nem bússola, nunca tendo certeza do seu destino.”
Leonardo da Vinci
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
8/85
7
SUMÁRIO
LISTA DE ILUSTRAÇÕES....................................................................................................09
LISTA DE TABELAS.............................................................................................................10
LISTA DE ABREVIATURAS................................................................................................11
1 INTRODUÇÃO ............................................................................................................. 14
1.1 O Problema ............................................................................................................................... 16
1.2 Objetivos .................................................................................................................................... 17
1.3 Contribuições Esperadas ......................................................................................................... 18
1.4 Organização do Trabalho ........................................................................................................ 18
2 CONCEITOS BÁSICOS .............................................................................................. 19
2.1 Interoperabilidade de Sistemas .............................................................................................. 19
2.2 O Modelo JC3IEDM ................................................................................................................. 21
2.3 Arquitetura Orientada a Serviços .......................................................................................... 26
3 O PROTOCOLO PROPOSTO .................................................................................... 29
3.1 Requisitos para Interoperabilidade em Operações Conjuntas .......................................... 29
3.2 Primeiro Nível de Integração: Entidades do JC3IEDM ...................................................... 34
3.3 Segundo Nível de Integração: Troca de Mensagens ........................................................... 42
3.4 As Mensagens do Protocolo ................................................................................................... 43
4 PROVA DE CONCEITO ............................................................................................. 45
4.1 Transformação dos Dados dos SC2 Legados para o JC3IEDM ......................................... 46
4.2 Mensagem de Pedido da Posição de uma Unidade ............................................................ 47
4.3 Mensagem de Pedido da Posição de Unidades em uma área ........................................... 47
4.4 Fluxo da Mensagem de Requisição ....................................................................................... 52
4.5 Fluxo da Mensagem de Resposta ........................................................................................... 52
4.6 Roteiro para Implementação do Caso de Teste ................................................................... 53
4.7 Construção do banco de dados baseado no JC3IEDM ........................................................ 53
4.8 Construção dos Artefatos ........................................................................................................ 53
4.9 Construção do Cliente ............................................................................................................. 54
4.10 Construção do Console ........................................................................................................... 54
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
9/85
8
5 TRABALHOS RELACIONADOS ............................................................................. 56
5.1 Utilizando Serviços Web e SOA nas comunicações militares ............................................ 56
5.2 Método Alternativo de Desenvolvimento e Troca (ADEM) .............................................. 57
6 CONCLUSÃO ................................................................................................................ 60
6.1 Contribuições ............................................................................................................................ 61
6.2 Trabalhos Futuros .................................................................................................................... 61
7 REFERÊNCIAS BIBLIOGRÁFICAS ......................................................................... 63
8 APÊNDICES ................................................................................................................... 63
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
10/85
9
LISTA DE ILUSTRAÇÕES
FIG. 2.1 Entidades Independentes do JC3IEDM (MIP, 2012) ..................................................... 22
FIG. 2.2 Serviços automatizados oferecendo várias capacidades (ERL, 2009) ......................... 27
FIG. 3.1 Visão dos Casos de Uso no Controle de uma Operação Conjunta ............................. 30 FIG. 3.2 Entidades Selecionadas do JC3IEDM (LARA; CHOREN, 2014) ................................. 36
FIG. 3.3 Especificação de ACTION-LOCATION (MIP, 2012) .................................................... 37
FIG. 3.4 Especializações na Estrutura da Entidade LOCATION (MIP, 2012) .......................... 38
FIG. 3.5 Árvore da Entidade OBJECT-TYPE (MIP, 2012) ........................................................... 39
FIG. 3.6 Árvore da Entidade Independente OBJECT-ITEM (MIP, 2012) .................................. 40
FIG. 3.7 Especializações da Entidade REPORTING-DATA (MIP, 2012) .................................. 41
FIG. 3.8 Relacionamento entre Entidades Independentes Selecionadas .................................. 42
FIG. 4.1 Entidade ACOMPANHAMENTO (SIPLOM) ............................................................... 46
FIG. 4.2 Descrição do Protocolo ...................................................................................................... 52
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
11/85
10
LISTA DE TABELAS
TAB. 2.1 Requisitos para integração de sistemas. ........................................................................ 32
TAB. 5.1 Tabela Comparativa entre os Trabalhos Relacionados ............................................... 59
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
12/85
11
LISTA DE ABREVIATURAS
ADEM - Alternate Development and Exchange Method
C2 - Comando e Controle
C2S - Command and Control System
COI - Communities of Interest
DEM - Data Exchange Mechanism
FA - Forças Armadas
HTTP - HyperText Transfer Protocol
ICCRTS - International Command and Control Research and Technology Symposium
IDE -Integrated Development Environment
IP - Internet Protocol
JC3IEDM - Joint Consultation, Command and Control Information Exchange Data Model
MD - Ministério da Defesa
MEM - Message Exchange Mechanism
MIP - Multilateral Interoperability Programme
OMG - Object Management Group
OODA - Observe, Orient, Decide and Act OTAN - Organização do Tratado do Atlântico Norte
UML - Unified Modeling Language
RNF - Requisito Não Funcional
SC2 - Sistema de Comando e Controle
SIPLOM - Sistema de Planejamento Operacional Militar
SOA - Service Oriented Architecture
SOAP - Simple Object Access Protocol
XML - eXtensible Markup Language
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
13/85
12
RESUMO
O cenário de uma Operação Conjunta pode ser descrito como um ambiente deguerra heterogêneo, onde existe a necessidade de atualização de uma consciênciasituacional compartilhada, baseada em uma constante troca de informações entre as
unidades participantes. No ambiente das operações militares não é usual existir umagrande capacidade de processamento e uma infraestrutura de redes com banda larga,o que torna necessária a elaboração de um protocolo para troca de mensagens, queaborde especialmente estas restrições, baseado nas tecnologias de troca demensagens.
No âmbito de uma Operação Conjunta, torna-se necessário uma corretacoordenação, em tempo hábil, dos sistemas de consciência situacional existentes nosComandos de Força, a fim de permitir uma maior interoperabilidade. Essa integraçãodeve ser abordada em dois níveis, por meio de um modelo de dados consolidado,onde é utilizado o Joint Consultation, Command and Control Information Exchange Data
Model (JC3IEDM), e de um protocolo para troca de mensagens, que trata oencaminhamento de mensagens XML, utilizando SOAP, atendendo a requisitos deintegração. Nesse contexto, também é utilizada uma arquitetura orientada a serviços(SOA), que é considerada como adequada para a integração de Sistemas deComando e Controle (SC2s).
Este trabalho apresenta um modelo de protocolo para troca de mensagens entreos SC2 utilizados nas Operações Conjuntas, a fim de permitir a interoperabilidadeentre os sistemas de informação de comando e controle, utilizando o JC3IEDM, omodelo de dados para a interoperabilidade de SC2s desenvolvido pelo MultilateralInteroperability Programme (MIP).
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
14/85
13
ABSTRACT
A Joint Operation scenario can be described as a heterogeneous warenvironment, in which there is a need to update a shared situational awareness,based on a constant exchange of information between computer systems (the
participating units). For example, in an operation in the Brazilian Amazon, a militaryaircraft will not be able to accurately perform an Aerial Fire Support mission withoutknowing the position of all friendly units in the area. These units may be from theArmy or Navy or any other force. The force may have a system that indicates theposition of its units.
Under a Joint Operation, it becomes necessary proper coordination in a timelymanner, of existing situational awareness in Force Command systems, to allowgreater interoperability. This integration must be addressed on two levels, through aconsolidated data model, which is used Joint Consultation, Command and ControlInformation Exchange Data Model (JC3IEDM), and a protocol for message exchange,
which handles the routing of XML messages using SOAP, considering integrationrequirements. In this context, a service-oriented architecture (SOA), which isconsidered suitable for the integration of Command and Control Systems (SC2s) isalso used.
This study presents a model protocol for exchanging messages between SC2sused in Joint Operations, to allow interoperability between command and controlinformation systems, using JC3IEDM, the data model for interoperability of SC2sdeveloped by Multilateral Interoperability Programme (MIP).
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
15/85
14
1 INTRODUÇÃO
Nos diversos níveis decisórios, do político-estratégico ao tático, a capacidade
dos comandantes em tomarem decisões acertadas é fundamental para o êxito emsituações de crise ou conflito armado. Nesse processo de tomada de decisão, são
envolvidas as tarefas de obtenção de dados e a conquista e manutenção da
consciência situacional, a fim de permitir alcançar a decisão.
Uma Operação é um conjunto de combates e manobras de todas as espécies,
executados por forças terrestres, navais e/ou aéreas, em determinada região, ou
tendo em vista um objeto preciso. Operações conjuntas envolvem recursos de
mais de uma Força Armada e são planejadas no âmbito do MD. Já as operações
singulares são realizadas no âmbito de uma única Força Armada, usando seus
próprios recursos.
As operações conjuntas são caracterizadas conceitualmente nos diversos
manuais do Ministério da Defesa (MD) como aquelas que envolvem ponderáveis
meios de duas ou mais Forças (Marinha, Exército e Força Aérea), sob um
comando único (NEGRÃO, 2013). O manual de Doutrina de OperaçõesConjuntas (BRASIL, 2011), acrescentou a essa definição, a necessidade do
estabelecimento de um Estado-Maior Conjunto, formado por militares de duas
ou mais Forças.
O cenário de uma operação conjunta demanda uma constante atualização da
consciência situacional, que é a percepção dos elementos no meio existente em
um volume de tempo e espaço, a compreensão de seu significado, e a projeção
de seu status no futuro próximo (ENDSLEY, 1995). Por exemplo, uma operação
na Amazônia Continental brasileira pode ser realizada com sucesso satisfatório
sem a troca de dados entre os sistemas de comando e controle de todas as Forças
Armadas (FA) que estão atuando na região, como a Marinha, o Exército e a
Aeronáutica, porém, um Navio Patrulha não pode efetuar engajamentos em
alvos de superfície desconhecidos. Da mesma forma, uma aeronave de asa fixa,
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
16/85
15
por exemplo, não pode realizar Apoio de Fogo Aéreo sem saber a localização de
suas Forças Amigas.
Nesse contexto, o processo de Comando e Controle (C2) é fundamental para
o êxito das operações militares. Sendo uma atividade especializada, o processode C2 é de concepção sistêmica, e possui métodos, procedimentos, características
e vocabulário peculiares. Sistemas de Comando e Controle (SC2s) visam apoiar a
esfera decisória com informações úteis à tomada de decisão. Estes sistemas
apresentam informações sobre a área de operação em um nível de abstração
adequado à esfera decisória.
A rapidez da atualização das informações influencia na execução do
processo de C2, reduzindo o tempo necessário à tomada de decisão. Esta
redução é imprescindível no cenário atual, que possui áreas de operação
complexas. Os SC2s são ferramentas necessárias à aplicação de paradigmas
modernos de condução da guerra (TARANTI, 2012), tais como Network Centric
Warfare (NCW) (ALBERTS et al., 1999) ou o Power to Edge (ALBERTS, HAYES,
2003), sobre deixar o poder de decisão nos escalões inferiores, ficando os
escalões superiores apenas com o poder de veto das ações das esferas inferiores.
Estabelecer a interoperabilidade de sistemas é uma tarefa desafiadora
(TARANTI, 2012). Especificamente nos SC2s utilizados no âmbito de uma
operação conjunta, torna-se crítica a integração em tempo hábil nos Comandos
de Força, a fim de permitir uma maior interoperabilidade entre as unidades
operativas envolvidas, e no nível estratégico e operacional, que ocorra uma
adequada troca de informações entre os seus Comandantes. O desafio da
integração de sistemas é ainda maior nos SC2s, devido à necessidade de seatender a diversos requisitos não funcionais (RNFs), e ainda, de se prever uma
solução escalável, que permita inserir e alterar conceitos com um mínimo de
impacto e indisponibilidade (TARANTI, 2012).
Além de questões técnicas, os processos e conhecimentos diferentes entre os
atores envolvidos dificultam o estabelecimento de uma interoperabilidade no
domínio de SC2. Outrossim, esta situação ainda é agravada pelo fato de que as
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
17/85
16
instituições envolvidas não possuem os seus processos de C2 descritos e bem
definidos, encontrando-se em um nível de maturidade inicial sobre o tema, o
que dificulta a definição dos processos de integração de seus sistemas
(TARANTI, 2012).
O PROBLEMA
A integração de SC2s, que são já existentes nas FA e em operação, é uma
necessidade na área de desenvolvimento de sistemas de consciência situacional.
Cada SC2 de uma FA possui respectivamente um modelo de dados particular,
que atende as características típicas de cada ambiente de guerra. Esta falta de
padronização entre os diferentes modelos dificulta a troca de dados entre os
SC2s, pois não existe uma semântica universal entre os dados a serem
compartilhados, e não representa um modelo para intercâmbio de informações.
O estado-da-arte na integração de SC2s tem sido alcançado através do
desenvolvimento de serviços que consomem modelos de dados padronizados,
como o The Alternate Development and Exchange Method - ADEM (MIP, 2014) , que
fornece os meios para a troca da situação atual de uma operação utilizando asemântica do Joint Consultation, Command and Control Information Exchange Data
Model – JC3IEDM (MIP, 2012). O ADEM oferece um paradigma para o
intercâmbio de informações, e permite uma troca de informações simples e
extensível, permanecendo fiel ao modelo de dados JC3IEDM, onde se abre a
possibilidade de troca com as comunidades de interesse (COIs) que podem não
estar dispostos ou capazes de implementar a especificação DEM (MIP, 2012).
Entretanto o ADEM está focado na troca de informações da situação atual de
uma operação, não sendo possível a troca de informações de dados históricos. A
troca de informações sobre a situação atual de uma operação é um recurso
básico da COI do MIP, onde se pode realizar contribuições significativas para as
COIs parceiras. Diminuir a distância entre o MIP e as COIs parceiras é o que se
espera para melhorar a qualidade e o compartilhamento de informações durante
as missões realizadas em operações conjuntas.
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
18/85
17
O problema tratado neste trabalho é a integração de SC2s, em nível de troca
de mensagens, a fim de se obter a localização e a atualização da posição de
Acompanhamentos no SC2 de nível Operacional do Ministério da Defesa (MD),
em uma Operação Conjunta realizada pelo MD. Acompanhamentos são objetosonde existe um interesse militar ou civil envolvido para justificar que estes sejam
acompanhados. Podem ser classificados como meios operacionais, instalações ou
feições geográficas. Os meios operacionais representam as unidades de combate,
como por exemplo: as aeronaves, as tropas, as viaturas, os navios e os
submarinos. Os fatores fixos representam instalações que podem ser definidas
por objetos construídos, instalados ou criados para servir a um propósito
particular. As feições de controle são divididas em feições geográficas,
meteorológicas e elementos de controle.
OBJETIVOS
O objetivo deste trabalho é propor um modelo de protocolo para troca de
mensagens entre os sistemas de comando e controle (SC2) utilizados nas
Operações Conjuntas, baseando-se no modelo de dados para ainteroperabilidade de SC2 desenvolvido para a OTAN, através do Multilateral
Interoperability Programme ( MIP), um programa de interoperabilidade de SC2s
desenvolvidos pelos países membros da OTAN.
Além do objetivo geral apresentado, este trabalho possui o objetivo
específico de apresentar um protocolo de mensagens para a integração do SC2
de nível operacional do MD, através de uma arquitetura orientada a serviços
(SOA), e com a utilização de troca de mensagens com conteúdo no JC3IEDM.
Foram analisados os processos envolvidos em uma Operação Conjunta, e
através deles, foi realizado o levantamento das necessidades encontradas em
uma operação, onde foram dados como prioridade para o estudo da
interoperabilidade dos SC2, a definição dos serviços de Localização de Forças
Amigas e Atualização das Posições de Forças Amigas. Após esse estudo, foram
definidos como requisitos funcionais deste trabalho:
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
19/85
18
• Requisito Funcional no 1: o protocolo deverá permitir aos sistemas realizar
o pedido de localização de uma unidade específica conhecida.
• Requisito Funcional no 2: o protocolo deverá permitir aos sistemas realizar
o pedido das posições de unidades em uma área geográfica definida.
CONTRIBUIÇÕES ESPERADAS
As contribuições esperadas pelo trabalho são:
1) Apresentar um protocolo para integração de SC2, através de uma SOA, e
que utiliza o modelo de dados JC3IEDM no conteúdo de suas mensagens;
2) Propor uma infraestrutura SOA para apoiar a aplicação do protocolo; e
3) Apresentar um estudo de caso do barramento de comunicação.
Cabe salientar que os processos de transformação e cadastro das informações
das operações conjuntas em um banco de dados baseado neste modelo não faz
parte do escopo deste trabalho.
ORGANIZAÇÃO DO TRABALHO
A dissertação está estruturada da seguinte forma: no capítulo 2 sãoapresentados os conceitos básicos, com o referencial teórico necessário para o
entendimento deste trabalho, o capítulo 3 apresenta o Protocolo proposto,
discutindo também as hipóteses assumidas e suas restrições; o capítulo 4
apresenta o cenário de estudo e de emprego do protocolo, com o estudo de caso
de sua aplicação; no capítulo 5 são discutidas as vantagens e desvantagens da
solução apresentada e os trabalhos relacionados; e o capítulo 6 apresenta a
conclusão do trabalho, suas contribuições e sugestões de trabalhos futuros.
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
20/85
19
2 CONCEITOS BÁSICOS
INTEROPERABILIDADE DE SISTEMAS
Quanto mais organizações perseguem os benefícios do e-business, mais elasestão olhando para um processo chamado de integração empresarial, ou
Enterprise Integration (EI), como um facilitador técnico fundamental na
transformação de seus processos de negócios. Um cenário típico de EI envolve a
integração de aplicações empresariais. Por este processo, a organização vincula-
se previamente a sistemas separados e isolados para dar-lhes uma maior
alavancagem.
Empresas são tipicamente compostas por centenas, se não milhares, de
aplicações que são construídas, adquiridas de terceiros, parte de um sistema
legado, ou uma combinação destes, operando em vários níveis de plataformas de
sistemas operacionais diferentes. Não é raro encontrar uma empresa que possui
trinta Web sites diferentes, três instâncias de Sistemas de Gestão Empresarial
(SAP) e soluções departamentais incontáveis. Para apoiar os processos de
negócio comuns, e o compartilhamento de dados entre aplicações, essas
aplicações precisam ser integradas. A integração de aplicações precisa fornecer
de forma eficiente, confiável e segura, a troca de dados entre várias aplicações
empresariais (HOHPE; WOOLF, 2004).
A EI não é uma tarefa fácil. Por definição, a EI tem de lidar com múltiplas
aplicações sendo executadas em várias plataformas, e em locais diferentes.
Fornecedores de software oferecem Enterprise Application Integration (EAI) suites
que são multi-plataforma, utilizam integração entre linguagens, bem como coma capacidade de interagir com muitos pacotes de aplicações empresariais
populares. No entanto, esta estrutura técnica resolve apenas uma pequena
porção das complexidades de integração (HOHPE; WOOLF, 2004).
Os verdadeiros desafios da integração se estendem muito além das questões
técnicas e de negócios. Qualquer pessoa que tenha passado por uma
implementação de EAI pode atestar que as suas soluções são um componente
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
21/85
20
crítico de diversas estratégias empresariais de hoje, mas que tornam a vida do
pessoal da área de Tecnologia da Informação (TI) mais difícil, e não mais fácil. É
um longo caminho entre a visão de alto nível da empresa integrada (definida por
termos como o processamento direto e empresa ágil) e as implementações de“porcas e parafusos” (HOHPE; WOOLF, 2004).
As funções compartilhadas de uma empresa são muitas vezes referidas como
serviços. Um serviço é uma função bem definida, que é universalmente
disponível e responde as solicitações de “consumidores de serviços”. Uma vez
que uma empresa reúne uma coleção de serviços úteis, a gestão dos serviços
torna-se uma função crítica. Em primeiro lugar, a aplicação precisa de alguma
forma de serviço de diretório, que é uma lista centralizada de todos os serviços
disponíveis. Em segundo lugar, cada serviço deve descrever sua interface de tal
forma que uma aplicação possa “negociar” um contrato de comunicação com o
serviço. Essas duas funções, de descoberta de serviço e de negociação, são os
principais elementos que compõe uma arquitetura orientada a serviços (SOA).
SOA borra a linha entre integração e aplicações distribuídas. Uma nova
aplicação pode ser desenvolvida utilizando serviços remotos existentes que
podem ser fornecidos por outras aplicações. Portanto, chamar um serviço pode
ser considerado a integração entre as duas aplicações. No entanto, a maioria das
SOAs fornecem ferramentas que fazem a chamada a um serviço externo quase
tão simples como chamar um método local (deixando de lado as considerações
sobre o desempenho), então o processo de desenvolvimento de uma aplicação
em cima de uma SOA assemelha-se a construção de uma aplicação distribuída
(HOHPE; WOOLF, 2004).A partir desses conceitos sobre integração de sistemas foi escolhida uma
SOA que suportasse uma solução sem a interferência, ou com a menor
interferência possível, nos SC2 legados das FA.
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
22/85
21
O MODELO JC3IEDM
A interoperabilidade de dados requer um vocabulário semântico
rigorosamente definido, que é incorporado em um contexto estruturado. A
estrutura da informação é expressa em um modelo de dados, desenvolvido edocumentado, de acordo com uma metodologia já aceita. O modelo define os
elementos padrões de informação que formam a base para a interoperabilidade
entre os Sistemas de Informação de Comando e Controle (C2IS) automatizados,
que acomodam a estrutura de informação do modelo de dados.
A versão atual do modelo incorpora um desenvolvimento adicional e os
dados do Modelo de Referência Corporativa da OTAN (NATO Corporate
Reference Model). Como resultado, o seu escopo aumentou e o nome foi alterado
para Joint C3 (Consultation, Command, and Control) Information Exchange Data
Model (JC3IEDM).
O JC3IEDM tem a pretensão de representar o núcleo de todos os dados
identificados como informações para troca em um ambiente de comando e controle.
Para que isso ocorra, sua estrutura deve ser mantida genérica o suficiente para
acomodar os ambientes de ar, terra, mar e ambientes de operações conjuntas. Todosos objetos de interesse na esfera das operações são definidos e descritos de forma a
incluírem organizações, pessoas, equipamentos, instalações, características
geográficas, fenômenos meteorológicos, e medidas de controle militares (por
exemplo: as fronteiras). Os objetos de interesse são genéricos em termos de uma
classe ou de um tipo, e específicos em termos de um item identificado
individualmente. Todos os objetos do tipo object item devem ser classificados como
sendo de algum tipo. Como exemplo, um tanque específico que é identificado pelo no
de série WS62105B é um item do tipo Challenger (carro de combate pesado inglês).
Um objeto deve ter a capacidade de executar uma função ou de atingir um
fim. Assim, uma descrição da capacidade é necessária para dar significado ao
valor dos objetos na esfera das operações. A FIG. 2.1 apresenta as dezenove
entidades independentes do JC3IEDM.
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
23/85
22
FIG. 2.1 – Entidades Independentes do JC3IEDM (MIP, 2012)
ACTION: representa uma atividade ou a ocorrência de uma atividade,
que pode utilizar recursos, e pode ser concentrada contra um objetivo.
Representa a operação, ou tipo de operação com o qual a unidade está
envolvida ou está realizando. Exemplos: Ordem de Operação, Plano de
Operação, Ordem de Movimento, Plano de Movimento, Ordem de Tiro,
Plano de Tiro, Missão de Tiro, Apoio de Fogo Aéreo, Eventos (por
exemplo: aeronave desconhecida se aproximando) ou incidente (por
exemplo: ataque inimigo).
Papel no Modelo: dinâmica (“Como”, “o que”, ou “quando” algo está para
ser realizado, está sendo realizado, ou foi realizado).
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
24/85
23
ADDRESS: representa as informações precisas sobre a base da qual um
destino físico ou eletrônico pode ser acessado.
Papel no Modelo: fornece meios para gravar endereços postais e eletrônicos.
AFFILIATION: um país, nacionalidade, etnia, grupo funcional, grupo de
exercício, ou religião a que pertença, ou a uma filiação que possa ser atribuída.
Papel no Modelo: fornece meios para atribuir filiações para tipos de objetos
(OBJECT-TYPE) ou itens de objetos (OBJECT-ITEM).
CANDIDATE-TARGET-LIST: uma lista de objetos ou tipos de objetos do
campo de batalha selecionados que possuem potencial valor para destruição
ou exploração, nomeado por autoridade competente para consideração no
planejamento das atividades no campo de batalha.
Papel no Modelo: fornece informações para apoiar a entidade ACTION.
CAPABILITY: uma potencial capacidade ou habilidade para realizar um
trabalho, executar uma função ou cumprir uma missão, alcançar um objetivo,
ou fornecer um serviço.
Papel no Modelo: indica a capacidade esperada para os OBJECT-TYPE e a
capacidade atual para os OBJECT-ITEM.
COMPONENT-HEADER-CONTENT: representa um assunto introdutório de
valor que destina-se a identificar um elemento de um plano ou de uma ordem.
Papel no Modelo: utilizado em conjunto com especificações de plano ou ordem.
COMPONENT-TEXT-CONTENT: representa uma declaração textual de umassunto de valor substantivo.
Papel no Modelo: utilizado em conjunto com especificações de plano ou ordem.
CONTEXT: uma coleção de informações que fornece em sua totalidade as
circunstâncias, condições, ambiente, ou perspectiva para uma situação.
Papel no Modelo: múltiplas funções, incluindo agrupamento de informações.
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
25/85
24
RELATIVE-COORDINATE-SYSTEM: um frame retangular de referência
definida por uma origem, eixos x e y no plano horizontal, e um eixo z. O eixo
vertical z é normal ao plano xy com o sentido positivo determinado a partir da
regra da mão direita, quando o eixo x é rotacionado na direção do eixo y.
Papel no Modelo: apoio à entidade LOCATION especificando uma geometria
com posições relativas.
GROUP-CHARACTERISTIC: uma referência a um conjunto de
características que podem ser utilizadas para identificar um conjunto distinto
de objetos. Exemplos de características incluem faixa etária, doença, sexo,
língua e classificações para triagem. Papel no Modelo: suporta a contagem dos tipos de pessoas de acordo com as
características selecionadas.
LOCATION: é uma especificação de posição e geometria em relação a um
frame horizontal específico de referência e a uma distância vertical
medida a partir de um DATUM específico. Na parte selecionada do
modelo para este trabalho, LOCATION especifica a localização de umaUnidade de uma Força que está atuando na operação conjunta. Exemplos:
pontos, sequência de pontos, linha poligonal, círculo, retângulo, elipse,
área poligonal, esfera, bloco de espaço e cone. LOCATION especifica
localização e dimensionalidade.
Papel no Modelo: geoposicionamento de objetos e criação de áreas
(“Onde?”).
OBJECT-ITEM: representa um objeto individualmente identificado. Neste
trabalho, representa uma instância do OBJECT-TYPE, como exemplo, uma
Unidade específica, que está sendo empregada na operação conjunta.
Exemplos: uma pessoa específica, um item específico de material, uma
característica geográfica específica, uma medida de coordenação específica ou
uma unidade militar ou civil específica.
Papel no Modelo: identificar as coisas individualmente (“Quem?” e “O que?”).
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
26/85
25
OBJECT-TYPE: representa as classes individualmente identificadas de objetos
de significância militar ou civil. Na parte do modelo selecionada para este
trabalho, representa o tipo de Unidade que está sendo utilizado na operação
conjunta. Exemplos: tipo de pessoa (por exemplo: por posto), tipo de material(por exemplo: peça de artilharia autopropulsada), tipo de instalação (por
exemplo: aeroporto), tipo de característica (por exemplo: área de tiro restrita),
ou tipo de organização (por exemplo: Divisão de Blindados).
Papel no Modelo: identificar classes de coisas (“Quem?” e “O que?”).
PLAN-ORDER: um esquema planejado ou ordenado que foi trabalhado
previamente para a realização de um objetivo do nível operacional.Papel no Modelo: entidade de mais alto nível para a identificação de um
plano ou de uma ordem.
REFERENCE: representa a identificação do registro sobre uma informação.
Papel no Modelo: aponta para uma informação externa em apoio à entidade
REPORTING-DATA.
REPORTING-DATA: representação da fonte ou origem, qualidade e tempo
que se aplica aos dados reportados. Neste trabalho, representa a data e a hora
em que a posição da Unidade está sendo reportada.
Papel no Modelo: apoio à função de relatório.
RULE-OF-ENGAGEMENT: representa uma orientação obrigatória da forma
como uma determinada atividade deve ser executada.
Papel no Modelo: apoio à entidade ACTION.
SECURITY-CLASSIFICATION: representa classificações de segurança que
são aplicáveis a um recurso de informação no domínio da segurança da
informação classificada.
Papel no Modelo: em apoio às entidades CONTEXT, NETWORK-SERVICE e
REFERENCE.
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
27/85
26
VERTICAL-DISTANCE: especificação da altitude ou altura de um ponto, ou
como um nível medido em relação a um datum específico de referência, na
direção normal ao plano que é tangente ao elipsoide de revolução do WGS84.
Papel no Modelo: apoio à entidade LOCATION, especificando elevação ou altura.
ARQUITETURA ORIENTADA A SERVIÇOS
De acordo com Thomas Erl (2009), o cotidiano encontrado no mundo está
rodeado de serviços, que sempre foram algo trivial na história da civilização.
Qualquer pessoa que execute uma tarefa específica para apoiar outras pessoas
está fornecendo um serviço. Um grupo de pessoas que execute uma tarefacoletiva para apoiar uma tarefa maior também está prestando ou realizando um
serviço.
Um serviço pode fornecer uma coleção de capacidades. Elas são reunidas de
acordo com um contexto funcional estabelecido pelo serviço com o qual elas se
relacionam. Por exemplo, na FIG. 2.2, os serviços têm como contexto funcional a
entrega de produtos. Então, os conjuntos de capacidades associadas com o
processamento de produtos são fornecidos por esses serviços. Um serviço pode
funcionar como um contêiner de capacidades relacionadas. Ele é composto por
uma lógica projetada para executar essas capacidades e por um contrato de
serviços, que definem quais são as capacidades que estão disponíveis para a sua
utilização (ERL, 2009).
A orientação a serviços como um paradigma de design, como descrito por
Thomas Erl (2009), é uma abordagem de lógica de solução. Construindo uma
lógica distribuída, as abordagens de design circulam um teoria de engenharia de
software conhecida como separação de interesses (HÜRSCH; LOPES, 1995). Essa
teoria demonstra que um problema maior é resolvido quando for decomposto
em um conjunto de interesses menores, ou efetivamente de problemas menores.
A partir desta teoria, pode-se dividir a lógica do problema em capacidades, e ir
definindo cada capacidade para resolver um determinado interesse. As
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
28/85
27
capacidades que obtiverem um relacionamento entre si podem ser reunidas em
unidades de lógica.
FIG. 2.2 – Serviços automatizados oferecendo várias capacidades (ERL, 2009)
De acordo com Thomas Erl (2009), o benefício maior em tratar problemas
através desse tipo de solução é que várias unidades de lógicas podem ser
definidas para resolver situações de interesse imediato, e, ao mesmo tempo,
permanecerem agnósticas em relação ao problema maior a ser resolvido.
Esse tipo de solução também permite a reutilização das capacidades dentro
das unidades de lógica para resolver outros problemas diferentes. A lógica
distribuída possui diferentes paradigmas de design, porém o que diferencia a
orientação a serviços é a forma através da qual a separação de interesses é
realizada, e a maneira como ela modela as unidades de lógica. Ao se aplicar a
orientação a serviços em uma parte significativa do trabalho, o resultado pode
ser classificado como uma lógica orientada a serviços, e descrito em unidades
lógicas individuais, que tem como características, os serviços.
Utilizando-se a parte mais significativa do modelo de dados apresentado
anteriormente, juntamente com a tecnologia de Web Services, ou Serviços Web,
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
29/85
28
obteve-se uma sinergia entre os dados disponíveis e os serviços oferecidos por
provedores especializados. Os Serviços Web possibilitam forte desacoplamento
entre clientes e servidores, em virtude de suas características de independência
de plataforma e de linguagem de programação. Ao utilizar o XML (Extensible Markup Languague) para definições e intercâmbio de informações, os Serviços
Web também possibilitam uma forte definição das mensagens e serviços através
de documentos WSDL. E com a utilização do HTTP na camada de transporte, a
passagem das mensagens por firewalls é facilitada, sem a necessidade de uso de
portas específicas.
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
30/85
29
3 O PROTOCOLO PROPOSTO
Durante a elaboração do protocolo, a principal contribuição deste trabalho,
foi identificada a necessidade da abordagem de dois níveis de integração: em umnível mais baixo, o modelo de dados para interoperabilidade de SC2s, o
JC3IEDM, e em um nível mais alto, um grupo de mensagens necessário para a
localização de um Acompanhamento em uma operação conjunta. Também foram
identificados os serviços que são candidatos a fazer parte de um barramento de
comunicações, como integrantes da iniciativa de construção de uma Arquitetura
Orientada a Serviços (SOA), a fim de permitir a interoperabilidade entre os SC2s
Legados das FA e o SC2 de Nível Operacional do MD, independente da
linguagem e plataforma destes sistemas legados.
Os Serviços Web estão disponíveis no barramento para todos os SC2s, tanto
para os SC2s Legados das FA, como para o SC2 de Nível Operacional do MD. As
mensagens trocadas entre os Serviços Web e os SC2s estão formatadas em XML,
sendo transmitidas através do SOAP sobre o HTTP. Elas possuem o formato dos
dados dos Acompanhamentos baseado no padrão JC3IEDM.
REQUISITOS PARA INTEROPERABILIDADE EM OPERAÇÕES CONJUNTAS
O cenário de uma operação conjunta pode ser descrito como um ambiente de
guerra heterogêneo, onde existe a necessidade de consciência situacional
compartilhada, que é baseada em uma constante troca de informações entre as
unidades participantes. Com base na análise dos processos de negócio do
Processo de Planejamento Conjunto (PPC), foi possível identificar as interações
entre os atores: SC2 de Nível Operacional (MD) e os SC2s Legados (Forças
Componentes).
Essas interações correspondem ao intercâmbio de informação entre os SC2s
Legados (FA) e o SC2 de Nível Operacional (MD), que são necessárias para a
correta execução do processo de acompanhamento das operações conjuntas.
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
31/85
30
A FIG. 3.1 apresenta as interações entre estes atores, através dos casos de uso
levantados pela visão de negócios no controle de uma operação conjunta.
FIG. 3.1 - Visão dos Casos de Uso no Controle de uma Operação Conjunta
Com os Casos de Uso destacados é possível definir os Serviços que podem
ser disponibilizados para qualquer SC2 que vise a interoperabilidade de C2.
•
Consultar Acompanhamento: o SC2 de Nível Operacional utiliza osAcompanhamentos dos meios adjudicados às Operações. Esses
Acompanhamentos deverão ser recebidos dos SC2s das Forças Singulares.
• Consultar Localização do Acompanhamento: os Acompanhamentos
relacionados terão as suas localizações registradas continuamente a partir dos
SC2s das Forças Singulares, e o SC2 de Nível Operacional poderá recuperar essa
informação para o devido monitoramento da operação conjunta.
• Consultar Situação do Acompanhamento: o Acompanhamento
relacionado terá sua situação operacional registrada continuamente, a partir dos
SC2 das Forças Singulares, e o SC2 de Nível Operacional poderá recuperar essa
informação para o devido monitoramento da operação conjunta.
Com relação ao fluxo de informação nas transações ligadas ao processo de
comando e controle no nível operacional, foram levantados os dados para
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
32/85
31
localização de meios, sendo navios ou tropas, entre os SC2 das Forças
Singulares; e o SC2 de nível operacional.
A visão do Processo de Planejamento Conjunto, realizado no nível
operacional durante as Operações Conjuntas, estabelece as condições para aefetiva interoperabilidade entre os SC2s de nível operacional. Esta visão macro
do processo de Controle da Operação Planejada (COP), com enfoque nas
integrações entre os sistemas, apoia o processo do COP. Os subprocessos que
existem no COP são as atividades onde ocorrem as interações entre os SC2.
Cada SC2 de uma Força Componente possui respectivamente um modelo de
dados particular, que deverá ser transformado através de seu respectivo
componente adaptador para o modelo JC3IEDM. O SC2 de Nível Operacional
realiza consultas aos dados registrados, disponibilizando as informações para o
acompanhamento da operação conjunta.
O conceito de “Agilidade” pode ser definido como a habilidade para efetuar,
lidar e/ou explorar com sucesso alterações nas circunstâncias (ALBERTS, 2011).
A partir desse conceito, foi definido como Requisito Não Funcional (RNF) o
“Tempo de Resposta”, onde o protocolo deve “permitir realizar consultas ao
banco de dados em uma velocidade adequada ao andamento das operações
conjuntas”, sendo a velocidade ideal considerada como sendo inferior a 5
segundos, e definida como o tempo de espera de um sistema legado para receber
a resposta de um pedido de posição de uma unidade específica conhecida.
Também foi definido a partir do conceito de “Agilidade” o RNF de
“Frequência”, onde a frequência ideal considerada é a de “em tempo real”, e
sendo definida como a frequência de interações necessária entre as aplicações.De acordo com Wing Lam e Venky Shankararaman (LAM;
SHANKARARAMAN, 2004), os requisitos para integração de sistemas são
verificados através de uma lista de verificação, apresentada na TAB. 3.1.
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
33/85
32
TAB. 3.1 – Requisitos para integração de sistemas.
Tipo de
Requisito
Descrição Exemplos
Volume Volume de dados que precisaser trocado entre aplicações. 10.000 transações/hora, 120requisições/minuto, ou500Kbytes/segundo.
Tempo de Resposta Tempos de resposta mínimospara realização de tarefas dousuário tratadas pelaintegração de aplicações.
5 segundos.
Tamanho Tamanho do dado que aintegração entre aplicaçõesdeve tratar (relacionado aovolume).
Tamanho de Arquivo de até 10Mbytes.
Timeliness Urgência da comunicação ou
integração entre aplicações.
Tempo real, dentro de 2 segundos, ou
em até 2 horas.Padrão de Formato deDados
Formato dos dadostransferidos entre aplicações.
Suporta formato ebXML, formato EDIou lida com formato proprietário.
Handshaking protocol Adesão a um protocoloparticular em relação a trocade interações entreaplicações.
De acordo com RosettaNET PIP 2345,ou de acordo com uma sequenciaproprietária de troca de mensagens.
Infraestrutura de
Comunicação
Restrições da infraestrutura
de comunicações nas
aplicações a serem
integradas.
Mensagens SOAP em HTTP ou um
formato proprietário de mensagem
sobre IBM MQ messsaging.
Resiliência e Recuperação Resiliência da estrutura de
integração em caso de falhas.
Garantia da entrega de mensagens,
redundância e downtime menor do
que cinco por cento.
Frequência Frequência de interações
necessária entre aplicações.
Tempo real, ou em uma hora, a cada
hora.
Segurança Nível de segurança exigidoentre aplicações.
Autenticação por usuário e senha noHTTPS; mensagens não-
criptografadas, suporte a certificados
digitais para autenticação, autorização
e não-repúdio.
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
34/85
33
Para a abordagem do segundo nível de integração através do protocolo de
troca de mensagens, foi realizada uma análise da tabela de requisitos de
integração para verificar como os requisitos não funcionais afetariam a obtenção
de um nível satisfatório de consciência situacional em uma operação conjunta.Os Requisitos Não Funcionais (RNFs) foram analisados e definidos de maneira a
tentar garantir um intercâmbio de informações adequado entre os sistemas de
comando e controle em uma operação conjunta.
Através da análise do cenário de integração dos sistemas legados de C2 em
uma operação conjunta, foram levantados os requisitos não funcionais, que são
necessários para garantir uma troca de informações adequada entre os SC2s
legados. Com o objetivo de alcançar esse nível de consciência situacional
compartilhada, foram definidos os seguintes RNFs para o protocolo:
Tempo de Resposta – Este requisito refere-se ao tempo de resposta
mínimo para realização de tarefas do usuário, que serão tratadas pela
integração de aplicações. Este requisito não funcional está associado
diretamente com a urgência, e com a qualidade da informação a ser
requisitada pelo sistema. Quanto maior for o tempo de resposta,
menor será a precisão da informação recebida, e consequentemente
também será menor a sua relevância no cenário de nível operacional.
Como exemplo, neste trabalho foi considerado o tempo de resposta
máximo de 5.000 milissegundos, ou cinco segundos (5s), para a
resposta a uma solicitação de uma informação de um sistema legado.
Resiliência e Recuperação – Este requisito refere-se à resiliência daestrutura de integração em caso de falhas. Estes requisitos não
funcionais afetam diretamente a flexibilidade e a tolerância a falhas na
estrutura de integração. Quando maior a sua redundância, maior
também será a garantia de entrega da mensagem. Como exemplo,
neste trabalho foi considerado como requisito não funcional a garantia
de que cada mensagem será entregue pelo menos uma vez.
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
35/85
34
Frequência – Este requisito refere-se à frequência de interações
necessária entre as aplicações que estão sendo integradas. Este
requisito não funcional de integração afeta diretamente o andamento
de uma operação conjunta, pois a frequência com que os dados serãorecebidos influencia diretamente na velocidade do andamento das
ações em uma operação conjunta. Como exemplo, neste trabalho a
frequência em tempo real foi considerada como necessária para os
Serviços do tipo Request/Response, e para os Serviços do tipo
Publish/Subscribe, poderia ser definido um intervalo de frequência.
Tamanho – Este requisito refere-se ao tamanho do dado que a
integração entre aplicações deverá tratar, e está relacionado
diretamente ao volume de informações a ser tratado. Este requisito
não funcional afetará diretamente a capacidade de troca de dados
entre sistemas legados, e define a estrutura física de integração.
Quanto maior o tamanho do arquivo enviado através do protocolo,
maior também será o tempo de processamento (overhead) para o
tratamento das mensagens no barramento de comunicação. Como
exemplo, neste trabalho foi considerado a troca de arquivos com um
tamanho de até dez megabytes (10MB). Este requisito deveria ser
configurado através de um Proxy, e está diretamente relacionado com
a infraestrutura física do local de operação do barramento.
PRIMEIRO NÍVEL DE INTEGRAÇÃO: ENTIDADES DO JC3IEDMO JC3IEDM é um modelo de dados para troca de informações utilizado por
diversos países em operações conjuntas. Ele é produzido pelo Conselho de
Administração MIP-NATO (MNMB) e ratificado sob o NATO STANAG 5525. O
JC3IEDM é um padrão documentado para um modelo de dados para o
compartilhamento de informações de C2.
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
36/85
35
O objetivo global do JC3IEDM é “permitir a interoperabilidade internacional
de sistemas de informação de C2 em todos os níveis de comando, ou no nível
mais baixo possível, a fim de apoiar as operações multinacionais, incluindo as da
OTAN, combinadas e conjuntas, e o avanço da digitalização na arenainternacional” (MIP, 2012).
De acordo com a documentação do JC3IEDM, este objetivo é perseguido
“especificando o conjunto mínimo de dados que precisam ser trocados em
coligação ou operações multinacionais. Cada nação, agência ou comunidade de
interesse é livre para expandir o seu próprio dicionário de dados para acomodar
as suas necessidades de troca de informações adicionais com o entendimento de
que as especificações adicionadas serão válidas para a nação, agência
participante ou comunidade de interesse. Qualquer adição considerada de
interesse geral pode ser apresentada como uma proposta de mudança no
controle de configuração para ser analisada e considerada para inclusão na
próxima versão da especificação” (MIP, 2012).
O JC3IEDM pretende representar o núcleo dos dados identificados para
troca em múltiplas áreas funcionais e várias exibições dos requisitos. Para isso,
estabelece uma abordagem comum para descrever as informações a serem
trocadas em um ambiente de comando e controle.
Quando se trata de uma operação conjunta, as informações são
compartilhadas pelas Forças Singulares para uso da cadeia de comando, e
devem ser tratadas, ratificadas e publicadas para a segurança e efetividade
destas operações.
Apesar de independentes, as Forças Singulares devem fornecer os dadosnuma linguagem padronizada, que permita a interpretação e organização das
informações a serem consumidas pelo nível decisório na cadeia de comando.
A opção pelo JC3IEDM deve-se à sua maturidade e ao seu amplo uso por
diversos países para comunicação de operações conjuntas. Desenvolvido pelo
MIP da OTAN, guarda características relacionais e hierárquicas em seu modelo,
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
37/85
36
definindo antecipadamente tipologias e relacionamentos dos itens utilizados nas
operações.
Os objetos de interesse das operações são pré-definidos por tipos (OBJECT-
TYPE), que determinam as características iniciais dos objetos (OBJECT-ITEM),nomenclatura utilizada para definir os Acompanhamentos empregados nas
Operações (ACTION). Em derivação, foram criadas árvores lógicas para tipo
(OBJECT-TYPE) e objeto (OBJECT-ITEM), que propagam as hierarquias de forma
a definir as características e associações dos itens da operação em curso.
Das dezenove entidades independentes existentes no modelo apresentadas
na FIG. 2.1, foram selecionadas para utilização, no primeiro nível de integração,
as cinco entidades que estão relacionadas diretamente com a localização de um
Acompanhamento em uma operação conjunta. Esta simplificação foi necessária
para alcançar um nível aceitável de complexidade de implantação do modelo,
pois a sua utilização completa é considerada demasiadamente complexa e
custosa, pois resulta em mensagens de tamanho muito grande para interoperar
nos SC2s. Este recorte mantém o modelo flexível e suficiente para permitir a
interoperabilidade entre os SC2 Legados em cenários de operações conjuntas. A
FIG. 3.2 apresenta o diagrama das entidades selecionadas do JC3IEDM.
FIG. 3.2 - Entidades Selecionadas do JC3IEDM (LARA; CHOREN, 2014)
A partir deste extrato do JC3IEDM, apresentado na FIG. 3.2, identificam-se
alguns conceitos sobre as entidades selecionadas.
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
38/85
37
As entidades principais do modelo de dados, e seus respectivos significados,
conforme definidos pelo MIP (2012), são:
ACTION: representa uma atividade ou a ocorrência de uma atividade,
que pode utilizar recursos, e pode ser concentrada contra um objetivo. Naparte selecionada do modelo ela representa a operação, ou tipo de
operação com o qual a unidade está envolvida ou está realizando.
Exemplos: Ordem de Operação, Plano de Operação, Ordem de
Movimento, Plano de Movimento, Ordem de Tiro, Plano de Tiro, Missão
de Tiro, Apoio de Fogo Aéreo, Eventos (por exemplo: aeronave
desconhecida se aproximando) ou incidente (por exemplo: ataque
inimigo).
Papel no Modelo: dinâmica (“Como”, “o que”, ou “quando” algo está para
ser realizado, está sendo realizado, ou foi realizado).
FIG. 3.3 – Especificação de ACTION-LOCATION (MIP, 2012)
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
39/85
38
LOCATION: é uma especificação de posição e geometria em relação a um
frame horizontal específico de referência e a uma distância vertical
medida a partir de um DATUM específico. Na parte selecionada do
modelo para este trabalho, LOCATION especifica a localização de umaUnidade de uma Força que está atuando na operação conjunta. Exemplos:
pontos, sequência de pontos, linha poligonal, círculo, retângulo, elipse,
área poligonal, esfera, bloco de espaço e cone. LOCATION especifica
localização e dimensionalidade.
Papel no modelo: geoposicionamento de objetos e criação de áreas (“onde?”).
FIG. 3.4 – Especializações na Estrutura da Entidade LOCATION (MIP, 2012)
OBJECT-TYPE: representa as classes individualmente identificadas de objetos
de significância militar ou civil. Na parte do modelo selecionada para este
trabalho, representa o tipo de Unidade que está sendo utilizado na operação
conjunta. Exemplos: tipo de pessoa (por exemplo: por posto), tipo de material
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
40/85
39
(por exemplo: peça de artilharia autopropulsada), tipo de instalação (por
exemplo: aeroporto), tipo de característica (por exemplo: área de tiro restrita),
ou tipo de organização (por exemplo: Divisão de Blindados).
Papel no Modelo: identificar classes de coisas (“Quem?” e “O que?”).
A FIG. 3.5 apresenta a árvore com as especializações da entidade OBJECT-TYPE.
FIG. 3.5 – Árvore da Entidade OBJECT-TYPE (MIP, 2012)
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
41/85
40
OBJECT-ITEM: representa um objeto individualmente identificado. Neste
trabalho, representa uma instância do OBJECT-TYPE, como exemplo, uma
Unidade específica, que está sendo empregada na operação conjunta.
Exemplos: uma pessoa específica, um item específico de material, umacaracterística geográfica específica, uma medida de coordenação específica ou
uma unidade militar ou civil específica.
Papel no Modelo: identificar as coisas individualmente (“Quem?” e “O que?”).
FIG. 3.6 – Árvore da Entidade Independente OBJECT-ITEM (MIP, 2012)
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
42/85
41
REPORTING-DATA: é a especificação da fonte ou origem, qualidade e
tempo que se aplica aos dados reportados. Neste trabalho, representa a data e
a hora em que a posição da Unidade está sendo reportada.
Papel no Modelo: apoio à função de relatório.
FIG. 3.7 – Especializações da Entidade REPORTING-DATA (MIP, 2012)
A FIG. 3.8 apresenta o relacionamento entre as entidades indepentes
selecionadas do JC3IEDM, através das quais conseguimos obter a localização de
um objeto, o seu tipo, e a date e a hora em que aquela localização foi reportada.
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
43/85
42
FIG. 3.8 – Relacionamento entre Entidades Independentes Selecionadas
SEGUNDO NÍVEL DE INTEGRAÇÃO: TROCA DE MENSAGENS
O protocolo proposto conta com um Serviço Web chamado de
“PositionReportWS”, que permite consultar a localização de Unidades em uma
operação através de dois métodos distintos. A classe PositionReport produz oserviço através do emprego de anotações em Java nas operações dos métodos
unitPosition e unitsInlatlongs.
O método unitPosition do serviço “PositionReportWS” permite localizar uma
Unidade através do fornecimento de sua identificação . A sua localização é
informada pelo método através de coordenadas geográficas.
O método unitsInlatlongs do serviço “PositionReportWS” permite informar
quais Unidades encontram-se dentro de uma determinada área retangular,
informada através de dois pontos, e retorna a característica e localização das
Unidades que estão na área desejada.
O serviço “PositionReportWS” também conta com um atributo chamado de
“Entrega de Mensagem Confiável”, que garante a entrega de mensagens através
do WS-ReliableMessaging, atributo disponível nos Serviços Web de segunda
geração que utilizam essa garantia física de que as mensagens serão trocadas.
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
44/85
43
AS MENSAGENS DO PROTOCOLO
As mensagens do protocolo foram divididas em dois grupos: Mensagens de
Pedido de Posição e mensagens de Resposta para um Pedido de Posição. As
mensagens de Pedido de Posição por sua vez foram divididas em dos tipos:Mensagem de Pedido de Posição de uma Unidade, e Mensagem de Pedido de
Posição de Unidades em uma Área. Segue abaixo a descrição das mensagens:
a) Mensagem de Pedido de Posição de uma Unidade: através dessa
mensagem é possível conhecer e manter atualizada a posição de uma
determinada unidade, ou objeto de interesse (Acompanhamento), através
do pedido de sua posição geográfica. Através destas mensagens
consegue-se acompanhar os diversos meios de uma operação conjunta,
tanto um navio navegando na área de operação, quanto uma tropa
progredindo no terreno. Sua especificação mais formalizada, no formato
EBNF, encontra-se no Apêndice I. Na mensagem de solicitação, além de
seu cabeçalho, onde é dada a informação sobre para qual serviço é aquela
solicitação (ex: PositionReportWS), no corpo da mensagem é fornecida a
informação sobre qual o objeto de interesse deseja-se obter a localização:
- Número Identificador do Objeto;
b) Mensagem de Pedido de Posição de Unidades em uma Área: através
desta mensagem é possível conhecer e manter atualizadas as posições dos
das unidades, ou objetos de interesse (Acompanhamentos), através de
pedidos de suas posições em uma área geográfica específica. Através
destas mensagens consegue-se verificar quais são as unidades que estão
localizadas em uma determinada área de operação, e também manter as
informações sobre suas localizações atualizadas naquela área geográfica,
possibilitando uma maior interoperabilidade entre os SC2 das Forças. Sua
especificação mais formalizada, no formato EBNF, encontra-se no
Apêndice I. Na mensagem de solicitação, além de seu cabeçalho, onde é
dada a informação sobre para qual serviço é aquela solicitação (ex:
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
45/85
44
unitsInLatLongRequest), no corpo da mensagem são fornecidas as
informações sobre a área que se deseja localizar os objetos de interesse:
- Coordenada Geográfica de Latitude do Sudoeste (SW) da área;
- Coordenada Geográfica de Latitude do Nordeste (NE) da área;
- Coordenada Geográfica de Longitude do SW da área; e
- Coordenada Geográfica de Longitude do NE da área desejada.
c) Mensagem de Resposta para um Pedido de Posição: através das
mensagens de resposta, observa-se a informação fornecida através do
Serviço solicitado pela mensagem de Pedido de Posição. Estes dados são
as posições das unidades, ou objetos de interesse (acompanhamentos),solicitadas pelas mensagens que foram enviadas aos Serviços Web. Suas
especificações mais formalizadas, no formato EBNF, encontram-se no
Apêndice I. Na mensagem de resposta, além de seu cabeçalho, onde é
dada a informação de qual serviço é aquela resposta (ex:
unitsInLatLongResponse), no corpo da mensagem são fornecidas as
informações sobre o objeto de interesse, ou acompanhamento, solicitado:
- Abreviatura do Acompanhamento ou Objeto de Interesse;
- Número Identificador do Objeto;
- Coordenada Geográfica de latitude do Objeto;
- Coordenada Geográfica de longitude do Objeto;
- Nome do Objeto de Interesse; e
- Hora em que o Objeto foi reportado.
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
46/85
45
4 PROVA DE CONCEITO
Este capítulo demonstra como é realizado o fluxo das mensagens utilizando
o protocolo de troca de mensagens do barramento de comunicação, onde asinformações são disponibilizadas através de Serviços Web que estão disponíveis
para os SC2 Legados fornecerem dados para o SC2 de nível operacional do MD.
Para que estes dados estejam disponíveis é necessária uma transformação para o
modelo de dados JC3IEDM, que está fora do escopo deste trabalho.
O trabalho foi desenvolvido como um modelo para troca de mensagens em
um sistema de C2 para simular a troca de informações entre SC2, onde foi
verificado qual o tipo de informação que o sistema de origem necessitaria. Após
essa fase inicial do trabalho, foi elaborado um modelo para a troca de mensagens
do sistema de origem até o sistema de destino, através de um barramento, onde
ocorre fisicamente o roteamento das mesmas, desde como chegar ao seu destino,
como receber a mensagem, e verificar o que foi recuperado de informações,
elaborando as mensagens de resposta para o sistema de origem. Esta troca de
mensagens é realizada através de uma arquitetura orientada a serviços (SOA), eutiliza a tecnologia de Serviços Web.
Este capítulo descreve um exemplo em que dois SC2 Legados estão
fornecendo informações para o SC2 de nível operacional do MD, o SIPLOM,
através de um barramento de comunicação. Os SC2 Legados possuem
informações sobre a posição atual de unidades das FA que serão consultados
pelo SIPLOM, e estão representados na arquitetura de alto nível como SC2
Legados ligados diretamente ao barramento de comunicação. O C2 em Combate,
do Exército Brasileiro, e o SISNC2 da Marinha do Brasil são exemplos de SC2
Legados, que possuem seus próprios modelos de dados para armazenamento e
intercâmbio de informações em suas arquiteturas internas.
O problema de transformação desses modelos de dados proprietários para o
padrão JC3IEDM de forma automatizada está fora do escopo deste trabalho.
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
47/85
46
Atráves da utilização da tecnologia de Serviços Web foi possível realizar o
intercâmbio de informações com um grande nível de desacomplamento entre os
SC2, pois a tecnologia envolvendo a comunicação possui as características de ser
independente da linguagem de programação utilizada em cada sistema, etambém de ser independente das plataformas e dos sistemas operacionais com
que irá se comunicar. Serviços Web estão disponíveis para serem utilizados por
todos os SC2, e o SIPLOM consulta a posicão de unidades através de um Serviço
Web chamado de PositionReportWS.
TRANSFORMAÇÃO DOS DADOS DOS SC2 LEGADOS PARA O JC3IEDM
A transformação dos dados dos SC2 Legados para o JC3IEDM se dará
através do mapeamento das suas entidades que são utilizadas nos serviços que
foram construídos e disponibilizados no barramento de comunicação. Como
exemplo, no SIPLOM, o SC2 de nível operacional do MD, existe a entidade
ACOMPANHAMENTO que sendo mapeada para o padrão JC3IEDM, observa-se
a sua relação direta com a entidade OBJECT-ITEM.
FIG. 4.1 – Entidade ACOMPANHAMENTO (SIPLOM)
Na versão 4.0 do SIPLOM existem diversos tipos de Acompanhamento que
devem ser mapeados para o padrão JC3IEDM antes da efetiva troca de
mensagens entre os SC2 legados: Meios (navios, tropas e aeronaves); Instalações
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
48/85
47
(portos, aeródromos, cidades e vias); e Feições de Controle (áreas inseridas no
sistema para controle do andamento da operação).
No JC3IEDM, existe o atributo object-type-category-code, que possui
códigos que são correspondentes aos tipos de acompanhamento pré-definidosno SIPLOM. Os dados precisam ser cadastrados anteriormente nos SC2s legados.
As seguintes categorias de acompanhamento devem ser mapeadas para o
JC3IEDM (object-type-category-code) para possibilitar a troca de informações:
a) Meios;
b) Instalações; e
c) Feições Geográficas.
Dessa forma, assim como deverá ser especificado um CATEGORY-CODE
para cada tipo de Acompanhamento correspondente no SIPLOM, deverão ser
especificados identificadores para o military-organization-type-id do JC3IEDM
que identifiquem as Forças Singulares de modo único, no contexto de uma
operação conjunta, para garantir a interoperabilidade dos SC2s legados das FA.
MENSAGEM DE PEDIDO DA POSIÇÃO DE UMA UNIDADEO protocolo trata a mensagem de Pedido de Posição de uma Unidade
específica com as seguintes regras de execução: a solicitação da posição de uma
Unidade conhecida é realizada através do número de identificação do objeto,
que deve ser único para cada Acompanhamento cadastrado no barramento de
comunicação.
MENSAGEM DE PEDIDO DA POSIÇÃO DE UNIDADES EM UMA ÁREA
O protocolo trata a mensagem de Pedido de Posição de Unidades em uma
Área com as seguintes regras de execução: a solicitação da posição de Unidades
em uma determinada área será realizada através de dois pontos geográficos, que
servem para definir os vértices sudoeste e nordeste da área retangular desejada.
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
49/85
48
A) MENSAGEM DE REQUISIÇÃO
Como exemplo de parâmetros enviados, apresenta-se 2 pontos geográficos:
- Ponto1: Lat1=50 e Long1=40 (Ponto Sudoeste de uma área retangular); e
- Ponto2: Lat2=100 e Long2=100 (Ponto Nordeste de uma área retangular).
O método unitsInLatLongRequest do Serviço Web PositionReportWS receberá
esses dois pontos como parâmetros, e fará a comparação com as latitudes e
longitudes dos objetos que estão no banco de dados baseado no JC3IEDM.
Através das tags em negrito da mensagem XML, observa-se no exemplo da
mensagem de Localização de Acompanhamentos em uma Área, o Serviço Web e
o seu método que foram solicitados, e os parâmetros enviados para esse método.
http://localhost:8080/jc3-svc/PositionReportWS
http://ws.svc.jc3.example/SvcWsUnitPosition/ unitsInLatLongRequest
uuid:73cc64de-8daf-45d6-8b8c-40564fd6dce7
...
http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id=5598fb43-f857-44cb-9492-30515e4e0942
http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id=5598fb43-f857-44cb-9492-30515e4e0942
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
50/85
49
50
100
40
100
B) MENSAGEM DE RESPOSTA
Através das tags em negrito da mensagem XML, observa-se no exemplo da
mensagem de Resposta da Localização de Acompanhamentos em uma Área, os
dados fornecidos através da resposta do Serviço.
http://ws.svc.jc3.example/SvcWsUnitPosition/ unitsInLatLongResponse
uuid:dbdbe21f-b84d-4ae4-848d-e4ffade834ba
uuid:73cc64de-8daf-45d6-8b8c-40564fd6dce7
...
http://docs.oasis-open.org/ws-rx/wsmc/200702/anonymous?id=5598fb43-f857-44cb-9492-30515e4e0942
UIE5 ATB
1010
55.000000
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
51/85
50
70.000000
Unidentified AntiTank Battery 5
12:00:00
reported
UIE9 FA
1017
50.200000
89.000000
Unidentified FA Battalion 9
12:00:00
reported
No exemplo da mensagem de resposta, o Serviço Web PositionReportWS
retornou dois objetos do banco de dados baseado no JC3IEDM que estão
localizados dentro da área retangular definida pelos pontos 1 e 2. Os dados
informados são relativos às seguintes Unidades cadastradas no banco de dados:
Objeto 1010
a) Abreviatura: UIE5 ATB;
b)
Nome: Unidentified AntiTank Battery 5 ;
c) Posição: latitude 55º00’00”N e longitude 70º00’00”W; e
d) Localização reportada às 12h00m.
Objeto 1017
a) Abreviatura: UIE9 FA ;
b) Nome: Unidentified FA Battalion 9 ;
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
52/85
51
c) Posição: latitude 55º12’00”N e longitude 89º00’00”W; e
d) Localização reportada às 12h00m.
A mensagem de pedido de posição é enviada de um “cliente” para o ServiçoWeb chamado de PositionReportWS. Entende-se como “cliente”, qualquer sistema
legado solicitante que irá consumir a informação, conforme apresenta a FIG. 4.2.
No início do funcionamento do protocolo de troca de mensagens é realizada
uma solicitação de ativação do WS-ReliableMessaging, que permite que as
mensagens SOAP possam ser entregues de forma confiável. Nessa solicitação
também é enviada a Identificação da Mensagem (UUID). Após o envio dessa
mensagem de solicitação do WS-ReliableMessaging, o “servidor” envia uma
resposta para o “cliente” com a mensagem de aceitação, que confirma,
implicitamente, que o WS-ReliableMessaging é suportado pelo Serviço Web.
Em seguida, é enviada outra mensagem do “servidor” para o “cliente”, com
a resposta à solicitação do Serviço Web, onde é realizado o início da
conversação, e enviado o endereço do Serviço Web PositionReportWS.
As tags das mensagens XML que dizem respeito apenas ao SOAP e ao XML,
que não possuem relevância para as informações que estão sendo transmitidas, e
nem para os requisitos não funcionais abordados pelo protocolo de integração,
foram suprimidas do texto e substituídas por três pontos (...), a fim de facilitar o
entendimento das mensagens que estão sendo transmitidas entre os sistemas.
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
53/85
52
FIG. 4.2 – Descrição do Protocolo
FLUXO DA MENSAGEM DE REQUISIÇÃO
Após a conversação inicial é enviada a mensagem do “cliente” para o
“servidor”, com a solicitação do Serviço Web PositionReportWS, enviando os
parâmetros de latitude e longitude para o Serviço. As palavras “cliente” e
“servidor” são apresentadas no texto entre aspas, pois este papel se altera de
acordo com o sentido em que está ocorrendo o fluxo das mensagens.
FLUXO DA MENSAGEM DE RESPOSTA
Após a mensagem de solicitação do Serviço Web PostionReportWS
informando os seus parâmetros, é enviada uma mensagem do “servidor” para o
“cliente”, com a resposta sobre a solicitação efetuada. Essa é apenas uma
mensagem inicial de aceitação do Serviço, que é recebida pelo “cliente”.
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
54/85
53
Logo após a confirmação da aceitação do serviço, finalmente é enviada a
mensagem do “servidor” para o “cliente” com a resposta da solicitação realizada
ao serviço PositionReportWS.
O método unitsInLatLongResponse do Serviço Web PositionReportWS retornaquais são os objetos que estão dentro da área definida pelos pontos geográficos 1
e 2 (Lat1 e Long1; Lat2 e Long2), e as suas respectivas localizações reportadas,
conforme estão representadas no banco de dados baseado em JC3IEDM.
ROTEIRO PARA IMPLEMENTAÇÃO DO CASO DE TESTE
Esta seção apresenta um breve roteiro para a construção do exemplo
descrito. Para facilitar a implementação do exemplo utilizado de caso de teste, os
seguintes softwares são considerados como pré-requisitos:
PostgreSQL Tools (pgAdmin III); e
NetBeans IDE 7.4, com o servidor de aplicação Glassfish 3.
CONSTRUÇÃO DO BANCO DE DADOS BASEADO NO JC3IEDM
A construção do banco de dados baseado no JC3IEDM foi realizada atravésdo PostgreSQL, com o nome do banco de dados chamado de “jc3iedm”. Foi
realizada a importação de dados de um banco baseado no JC3IEDM pré-
existente, através do arquivo “JC3IEDM.sql 1 ”. Este é um banco de dados
concebido para simulação, com dados sintéticos existentes de acordo com o
modelo do JC3IEDM. O Multilateral Interoperability Programme disponibiliza em
sua documentação sobre o JC3IEDM um script para criação de um banco de
dados baseado em JC3IEDM, porém sem conter dados populados.
CONSTRUÇÃO DOS ARTEFATOS
A construção dos artefatos foi realizada através da ferramenta NetBeans IDE
7.4, com o servidor de aplicação Glassfish 3 também instalado. A sequência de
construção foi seguida conforme descrito nas próximas subseções.
1 “JC3IEDM.sql” é um script do Multilateral Interoperability Programme, disponibilizado na página: https://mipsite.lsec.dnd.ca.
-
8/17/2019 UM PROTOCOLO PARA INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE
55/85
54
A) ARTEFATO DAO
A construção do Data Acess Object (DAO) foi realizada através do NetBeans
7.4, onde foi criado o artefato “ jc3-entities”. Este artefato realiza o mapeamento
das entidades do banco JC3IEDM em classes Java, para que as informações do
banco possam ser processadas.
A classe “VWUnitPosition.java” foi criada para facilitar o uso do JC3IEDM,
criando uma visão mais intuitiva do JC3IEDM, ou seja, uma view mais simples.
B) ARTEFATO DO SERVIÇO
A construção do artefato do serviço (artefato “SVC”) foi realizada através do
NetBeans 7.4, onde foi criado o artefato “ jc3-svc”. A classe PositionReport produz
o serviço através do emprego de anotações em Java nas operações dos métodos
unitPosition e unitsInlatlongs. Após ser implantado no Servidor, o artefato foi
exposto como um Serviço Web para consumo.
Dentro do artefato “jc3-svc”, em sua pasta denominada “Web Services”,
dentro do serviço “PositionReportWS” foi implementada a Entrega de
Mensagem Confiável, como um atributo do Serviço Web. Neste momento o
Serviço está pronto, faltando apenas o “cliente” para consumi-lo.
A descrição do Serviço Web (WSDL) está disponível no endereço:
“http://localhost:8080/jc3-svc/PostionReportWS?WSDL ”.
CONSTRUÇÃO DO CLIENTE
A construção do “cliente” do serviço foi realizada através do NetBeans 7.4,
onde foi criado o artefato “jc3-ws-cli”. Foi realizada a geração de um artefato
Java para clientes do serviço a partir do WSDL do serviço.
CONSTRUÇÃO DO CONSOLE
O “console” representa o “solicitante” do serviço, equivalente ao SC2
Legado. A construção do “console” também foi realizada através do NetBeans
-
8/17/