um protocolo para integraÇÃo de sistemas de comando e controle

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


2/85



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


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.


4/85

3



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


5/85

4

Dedico este trabalho a minha Família.

Ele é fruto do apoio integral de vocês.


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


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/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


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


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


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


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


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).


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).


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,


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


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.


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:


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.


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


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.


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.


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).


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.


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?”).


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.


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


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,


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.


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.


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


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.


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.


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.


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.


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,


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.


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)


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


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)


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)


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.


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.


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:


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.


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.


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


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.


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



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

...


UIE5 ATB

1010

55.000000


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 ;


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.


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”.


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.


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

um protocolo para integraÇÃo de sistemas de comando e controle

Documents