Universidade Federal do Rio de Janeiro

Escola Politcnica
MBA em Engenharia de Computao e Sistemas
Implementao de uma arquitetura SOA para
interoperabilidade entre sistemas de Comando e Controle
Autor:

Orientador:

Examinador:

Examinador:

Examinador:

Examinador:

Examinador:

_________________________________________________
Jorge Eduardo Calvelli
_________________________________________________
Prof. Flvio Luis de Mello, DSc.
_________________________________________________
Prof. Edilberto Strauss, PhD
_________________________________________________
Prof. Claudio Luiz Latta de Souza, MSc
_________________________________________________
Prof. Manoel Villas Bas Jnior, MSc
_________________________________________________
Prof. Noberto Ribeiro Bellas, MSc
_________________________________________________
Prof. Paulo Fernando Peixoto da Costa Fazzioni, MSc
MBCA
Maro de 2016
i

UNIVERSIDADE FEDERAL DO RIO DE JANEIRO

Escola Politcnica Departamento de Eletrnica e de Computao

MBA em Engenharia de Computao e Sistemas

Centro de Tecnologia, bloco H, sala H-217, Cidade Universitria

Rio de Janeiro RJ

CEP 21949-900

Este exemplar de propriedade da Universidade Federal do Rio de Janeiro, que

poder inclu-lo em base de dados, armazenar em computador, microfilmar ou adotar

qualquer forma de arquivamento.

permitida a meno, reproduo parcial ou integral e a transmisso entre

bibliotecas deste trabalho, sem modificao de seu texto, em qualquer meio que esteja
ou venha a ser fixado, para pesquisa acadmica, comentrios e citaes, desde que sem
finalidade comercial e que seja feita a referncia bibliogrfica completa.

Os conceitos expressos neste trabalho so de responsabilidade do(s) autor(es).

ii

DEDICATRIA
A minha famlia, meu alicerce, que me incentiva e me ajuda a seguir em frente.

iii

AGRADECIMENTO
A minha famlia, pelo apoio e compreenso.

Aos meus amigos do trabalho: Toms Aquino Botelho, Patrick Lara, Manuel S

e Simione Campelo, que me ajudaram de forma inestimvel, esclarecendo dvidas

tcnicas e de negcio, ampliando meus conhecimentos.

Ao meu orientador Flvio Luis de Mello, pela pacincia e apoio, fatores

fundamentais, sem os quais minha tarefa teria sido muito mais difcil.

iv

Resumo
A dificuldade de integrao de dados entre sistemas informatizados de Comando

e Controle (C2) um problema atual, que afeta o setor militar de muitas naes,

incluindo o Brasil. A integrao deve levar em considerao no apenas os sistemas,

mas deve considerar tambm a existncia de processos associados operacionalizao

da troca de dados e sobre como os mesmos so usados ou descartados. A adoo de uma

Arquitetura Orientada a Servios (SOA) prov uma boa soluo para integrao de
sistemas heterogneos, possibilitando o desacoplamento entre esses sistemas e
facilitando a troca de mensagens entre eles. O presente trabalho apresenta o projeto

piloto de implementao de uma arquitetura SOA para prover uma soluo de

interoperabilidade entre Sistemas de Comando e Controle das Foras Armadas em

operaes conjuntas baseada no modelo dados Joint Consultation, Command and

Control Information Exchange Data Model (JC3IEDM). No decorrer do ano de 2015,

foram construdos o prottipo do barramento de comunicao e os simuladores dos

sistemas de C2, com os quais, juntamente com o Sistema Naval de Comando e Controle
(SISNC2), foi possvel executar os testes de exequibilidade, demonstrando a viabilidade
do projeto. Diante das tecnologias analisadas, percebe-se a necessidade de um

aprofundamento no estudo da BML em funo das limitaes do ADEM e se vislumbra

uma possvel contribuio para integrao de servios de segurana pblica, defesa civil
e sade pblica.

Palavras-Chave: Comando e Controle, interoperabilidade, SOA, JC3IEDM, ADEM,

BML

ABSTRACT
Data integration between Command and Control (C2) information systems is a

modern difficult problem that affects military sector in many nations, Brazil including.

To achieve Integration it should be taken into consideration not only computer systems,

but it should also consider the existence of processes associated to the data exchange
operation and how they are used or discarded. Adopting a Service Oriented Architecture

(SOA) provides a good solution for heterogeneous systems integration, enabling the
decoupling and facilitating message exchanging between them. The present work

presentes the pilot project for implementing a SOA architectureto provide a solution to
interoperability between systems of Command and Control of the Armed Forces in joint

operations based on the data model Joint Consultation, Command and Control

Information Exchange Data Model (JC3IEDM). During the year of 2015, were built the
prototype of the communication bus and C2 Systems simulators, with which, along with

the Naval Command and Control System (SISNC2), it was possible to perform the
feasibility tests, demonstrating the viability of the project. Among the analyzed

technologies, we found out the need for a deeper study of BML according to ADEM
limitations and glimpsed a possible contribution to public security services integration,
civil defense and public health.

Key-words: Command and Control, interoperability, SOA, JC3IEDM, ADEM, BML

vi

SIGLAS
ADEM - Alternate Development and Exchange Method
BBS - BML Base Services
BML - Battle Management Language
BPM - Business Process Management
BPMS - Business Process Management System
C-BML - Coalition Battle Management Language
C2 - Comando e Controle
CASNAV - Centro de Anlises de Sistemas Navais
CDAS - Common Data Access Services
COP - Controle da Operao Planejada
DCS - Domain Configured Service
DEM - Data Exchange Mechanism
EAI - Enterprise Application Integration
EB - Exrcito Brasileiro
ESB - Enterprise Service Bus
FA - Fora Armada
FAB - Fora Area Brasileira
Fcte - Fora Componente
FFAA - Foras Armadas
FS - Fora Sigular
HE - Hipoteses de Emprego
HTTP - Hyper Text Transfer Protocol
IBML - Integrated BML
InterC2 - Interoperabilidade de Comando e Controle
JC3IEDM - Joint Consultation, Command and Control Information Exchange Data
Model
JSON - Javascript Object Notation
MB - Marinha do Brasil
MD - Ministrio da Defesa do Brasil
MIP - Multilateral Interoperability Program
OpCj - Operao Conjunta
OpSing - Operao Singular
PPC - Processo de Planejamento Conjunto
Rest - Representational State Transfer
SIPLOM - Sistema de Planejamento Operacional Militar
SISMC2 - Sistema Militar de C2
SISNC2 - Sistema Naval de Comando e Controle
SISO - Simulation Interoperability Standards Organization
SOA - Arquitetura Orientada a Servios
SOAP - Simple Object Access Protocol
STIC2 - Sistemas de Tecnologia da Informao para C2
UDDI - Universal Description, Discovery and Integration
URI - Uniform Resource Identifier
WSDL - Web Services Description Language
XML - Extensible Markup Language

vii

Sumrio
INTRODUO .............................................................................................................. 1
1.1 TEMA .................................................................................................................... 1
1.2 JUSTIFICATIVA ...................................................................................................... 1
1.3 DELIMITAO ....................................................................................................... 3
1.4 OBJETIVO .............................................................................................................. 3
1.5 METODOLOGIA ..................................................................................................... 4
1.6 DESCRIO ........................................................................................................... 4

COMANDO E CONTROLE E A INTEROPERABILIDADE .................................. 5

2.1 COMANDO E CONTROLE ........................................................................................ 5
2.2 INTEROPERABILIDADE ........................................................................................... 9
2.3 SISTEMAS E FRAMEWORKS EXISTENTES .............................................................. 11
2.3.1 - JC3IEDM ......................................................................................................... 11
2.3.2 - ADEM ............................................................................................................. 15
2.3.3 - BML................................................................................................................. 17
2.3.4 WISE-SBML................................................................................................... 22
2.3.5 SITAWARE COALITION GATEWAY ................................................................... 23
2.4 PARMETROS DE INTEROPERABILIDADE ENTRE SISTEMAS DE C2 ....................... 25

ARQUITETURA ORIENTADA A SERVIOS (SOA) ........................................... 27

3.1 CONCEITOS ......................................................................................................... 27

3.2 PRINCPIOS .......................................................................................................... 29
3.3 TECNOLOGIA USADA .......................................................................................... 31
3.4 GOVERNANA ..................................................................................................... 34

PROPOSTA DE SOLUO ....................................................................................... 38

4.1 ARQUITETURA DO BARRAMENTO........................................................................ 40

4.2 A INTERFACE DE COMUNICAO ........................................................................ 42
4.3 EXEMPLIFICANDO O PROCESSO DE TROCA DE MENSAGENS .................................. 46

CONCLUSO............................................................................................................... 54

5.1 CONCLUSO ........................................................................................................ 54

5.2 TRABALHOS FUTUROS ......................................................................................... 54

BIBLIOGRAFIA .......................................................................................................... 56

viii

Lista de Figuras

Figura 2.1 - Ciclo OODA ................................................................................................. 8

Figura 2.2- Evoluo da Interoperabilidade ..................................................................... 9
Figura 2.3- Modelo simplificado do JC3IEDM ............................................................. 14
Figura 2.4 - Intercmbio de informaes MIP x no MIP ............................................. 16
Figura 2.5 - Arquitetura JBML Viso Geral............................................................... 19
Figura 2.6 - Matriz produtor / consumidor C-BML ...................................................... 20
Figura 2.7 - Arquitetura Wise-SBML............................................................................ 23
Figura 2.8 Tecnologias que compe o SitaWare ........................................................ 24
Figura 3.1- Relao fornecedor x consumidor [26] ........................................................ 28
Figura 3.2 Princpios de SOA [28] .............................................................................. 31
Figura 3.3- Smbolos usados para representar um componente [25] ............................. 32
Figura 3.4 Arquitetura Web Service [25] ..................................................................... 32
Figura 4.1 Interoperabilidade entre sistemas de C2 .................................................... 39
Figura 4.2- Diagrama de Arquitetura e Ativos de Software ........................................... 41
Figura 4.3- Mensagem de Registro de Objeto de Interesse ............................................ 45
Figura 4.4 - Diagrama de Sequncia OpCj ..................................................................... 45
Figura 4.5 Processos iniciais do barramento ............................................................... 46
Figura 4.6 XML para cadastro da operao ................................................................ 47
Figura 4.7 XML de cadastro de objeto de interesse .................................................... 48
Figura 4.8 XML de adjudicao de objeto de interesse a operao ............................ 49
Figura 4.9 Processo de troca de mensagens durante a operao ................................. 50
Figura 4.10 XML de registro de localizao ............................................................... 51
Figura 4.11 XML de registro de situao operacional ................................................ 52
Figura 4.12 XML de registro de hostilidade................................................................ 53

ix

Lista de Tabelas
Tabela 2.1- Entidades independentes do JC3IEDM [10] ............................................... 12
Tabela 2.2- Mtricas tcnicas para soluo de interoperabilidade [8] ........................... 25

Captulo 1
Introduo
1.1 Tema
Este trabalho trata sobre a interoperabilidade de Sistemas de Comando e

Controle. Neste sentido, o problema a ser resolvido isolar a heterogeneidade dos

diversos sistemas empregando uma arquitetura orientada a servios.

1.2 Justificativa
A evoluo tecnolgica e a complexidade geopoltica aumentaram as

dificuldades para realizao de misses militares, em especial Operaes Conjuntas e

Multinacionais, requerendo alta capacidade de interoperabilidade entre as foras

envolvidas. Um dos desafios a serem enfrentados nesse cenrio a identificao e a

adoo

de

tcnicas,

ferramentas

prticas

que

permitam

aperfeioar

compartilhamento da informao, visando acelerar dinmica na tomada de deciso.

A complexidade dos conflitos contemporneos no admite o emprego isolado de

uma nica FA (Fora Armada) em campanhas. Assim sendo, a combinao dos meios e

a convergncia de esforos tornam-se indispensveis para que seja obtido o mximo

rendimento das foras disponveis, tendo sempre como referncia as HE (Hipteses de
Emprego) que podem ocorrer no Pas [1].

Atualmente as misses so, simultaneamente, mais complexas e mais dinmicas,

o que requer a capacidade e esforo coletivos das vrias organizaes, a fim de se obter

o sucesso. Este requisito para a montagem de um conjunto diversificado de recursos e

organizaes em uma coalizo efetiva acompanhado por reduo das janelas de

oportunidade de resposta. Em fim, as abordagens tradicionais de Comando e Controle

no esto altura do desafio, de forma simplificada, elas no tm a agilidade necessria
para o sculo XXI [7].

Comando e Controle (C2) uma atividade fundamental para o xito das

operaes militares em todos os escales de comando. Como atividade especializada,

sua execuo se baseia em uma concepo sistmica, com mtodos, procedimentos,

caractersticas e vocabulrio que lhe so peculiares. O C2 vincula e permeia todas as

atividades operacionais e de apoio, sincronizando-as e permitindo ao comandante

adquirir e manter o indispensvel nvel de conscincia situacional para a tomada de
decises adequadas s circunstncias do ambiente operacional, para a expedio de
ordens e para o controle de sua execuo [2].

Para o sucesso das operaes so fatores indispensveis uma unidade de

comando no mais alto escalo, uma mentalidade militar unificadas nos diversos nveis
de comando e a capacidade de interoperabilidade entre as Foras empregadas. Assim, a
necessidade de troca e compartilhamento de informao entre os diversos sistemas de

C2 de cada uma das FFAA, em operaes conjuntas, um indicador para a integrao

destes sistemas nas operaes. Para ser atendido em suas necessidades de
acompanhamento e planejamento, o comandante da operao precisa de informaes

dos diversos sistemas de C2 das FFAA envolvidas na ao, que devem estar
consolidadas em uma viso nica.

Felizmente, os avanos nas tecnologias de informao criaram um novo espao

no qual os indivduos e as organizaes podem operar. Esses indivduos e organizaes

que aprenderam a aproveitar as oportunidades oferecidas pela operao neste novo

espao tm percebido uma significativa vantagem competitiva sobre aqueles que tm

ignorado estas oportunidades [7].

Dentre as diversas abordagens disponveis, a adoo de uma Arquitetura

Orientada a Servios (SOA) prov uma boa soluo para integrao de sistemas
heterogneos, j que prev um baixo acoplamento entre sistemas, que necessitaro de
poucas modificaes para interagirem uns com os outros.

No ambiente militar, apesar da existncia de aspectos comuns entre cada uma

das FFAA, estas possuem caractersticas especficas ligadas a sua esfera de atuao que
as diferenciam entre si. Essas caractersticas de negcio levam a que sistemas

desenvolvidos para atender as necessidades de uma FA especfica apresentem

necessidades de informaes e funcionalidades diferentes de outro sistema desenvolvido
para outra FA.

O paradigma SOA, por proporcionar flexibilidade, escalabilidade e tolerncia a

falhas, fruto de um baixo acoplamento, apresenta-se como alternativa para cenrios

descritos anteriormente, onde os sistemas diversos, desenvolvidos em diversas

2

tecnologias, precisam atender, conjuntamente, a demanda de informao dos Centros de

Comando e Controle.

Por fim, o conhecimento dos processos de negcio permite uma melhor

definio da soluo tecnolgica a ser construda. O mapeamento destes processos

permite orientar a definio do portflio de servios da soluo SOA e ajudar a garantir

que a soluo corresponda a demanda apresentada, fazendo o elo entre as necessidades
da organizao e a TI.

1.3 Delimitao
Neste trabalho abordada a questo da necessidade do compartilhamento de

informao entre sistemas de comando e controle do seguimento militar, a partir da

viso da soluo em desenvolvimento para o Ministrio da Defesa do Brasil. So
apresentados os conceitos, sendo os principais, Comando e Controle, Interoperabilidade,

Arquitetura Orientada a Servios, JC3IEDM (modelo de dados para interoperabilidade

de sistemas) e ADEM (mtodo de intercmbio de dados), necessrios para compreender
a soluo.

A proposta apresentada visa a interoperabilidade de sistemas de comando e

controle das Foras Armadas, no entanto, olhando a questo segurana de uma forma

mais ampla, o sucesso na implementao da soluo possibilitar que sistemas de outras

agncias governamentais, tais como Polcia Federal, Polcia Militar e Defesa Civil,
tambm possam ser integrados no futuro, o que viria a proporcionar uma viso de

segurana pblica nacional muito mais precisa. Da mesma forma, a experincia obtida

tambm poder ser aproveitada para integrao de sistemas ligados a Defesa Civil e
Segurana Pblica de forma a prover solues mais eficientes na resposta a crises.

1.4 Objetivo
O objetivo do presente trabalho apresentar uma proposta de soluo que

permita uma melhor integrao entre os sistemas C2 da Marinha, do Exrcito e da Fora

Area e o Sistema de C2 do Ministrio da Defesa. Neste sentido, os objetivos
especficos so:

Apresentar a aplicao da Arquitetura Orientada a Servios (SOA) e

demais componentes arquiteturais propostos para a soluo do problema;

Apresentar os modelos e mtodos de intercmbio de informaes

aplicveis a interoperabilidade de sistemas de comando e controle.
3

1.5 Metodologia
A metodologia para elaborao deste trabalho deu-se atravs de levantamentos

de informaes em livros e artigos publicados em sites da Internet especializados no

tema tratado. O autor valeu-se, tambm, da experincia com o desenvolvimento do

projeto de Interoperabilidade de Comando e Controle, desenvolvido para o Ministrio

da Defesa do Brasil pelo Centro de Anlise de Sistemas Navais da Marinha do Brasil.

1.6 Descrio
O trabalho ser organizado da maneira a seguir.

No Captulo 2 ser apresentada a conceituao de Comando e Controle (C2) e

interoperabilidade, bem como ferramentas, frameworks e sistemas identificados durante

a pesquisa.

No Captulo 3 ser apresentada a conceituao de Arquitetura Orientada a

Servios (SOA).

No Captulo 4 ser feito um estudo, apresentando a soluo proposta para o

problema de integrao entre os sistemas de comando e controle das diversas FA

componentes de uma operao conjunta.

No Captulo 5 sero apresentadas as concluses obtidas a partir do estudo

realizado.

Captulo 2
Comando e Controle e a
Interoperabilidade

Neste captulo sero abordados conceitos de Comando e Controle (C2) e

Interoperabilidade, que fundamentam a necessidade da proposta de soluo apresentada.

2.1 Comando e Controle

Comando e Controle (C2) a cincia e a arte que trata do funcionamento de uma

cadeia de comando, envolvendo, basicamente, uma autoridade legitimamente investida,

processos decisrios e recursos [2].

Cada um desses componentes bsicos possuem caractesticas especficas, onde:

a) A autoridade legitimamente investida, apoiada por uma organizao da qual

emanam as decises que materializam o exerccio do comando e para onde

fluem as informaes necessrias ao exerccio do controle;

b) A sistemtica de um processo decisrio, que permite a formulao de ordens,

estabelece o fluxo de informaes e assegura mecanismos destinados

garantia do cumprimento pleno das ordens; e

c) A estrutura, ou recursos, incluindo pessoal, equipamento, doutrina e

tecnologia necessrios para a autoridade acompanhar o desenvolvimento das
operaes.

No que tange a rea militar, trata-se de uma atividade de importncia decisiva

para o xito das operaes em todos os escales de comando, baseando-se em uma

concepo sistmica, com mtodos, procedimentos, caractersticas e vocabulrio que lhe

so peculiares.

Dessa forma, pode-se entender C2 como uma disciplina que rege o

funcionamento de uma cadeia de comando, onde um comandante exercita a autoridade e

direo sobre as foras sob seu comando de forma a obter xito em suas aes.
5

Finalmente, pode-se dizer que C2 um meio de criao de valor, como uma

misso, por exemplo, que trata da concentrao de esforos de pessoas, organizaes,

recursos e informaes, para a realizao de alguma tarefa, objetivo ou meta [7].

Alm da definio j apresentada, outro conceito importante o de Sistema de

C2, que descrito como o conjunto de recursos necessrios para o comandate planejar,

dirigir e controlar as aes. Esse conceito composto por trs componentes: o Sistema
Militar de C2 - SISMC2 (instalaes, equipamentos, comunicaes, doutrinas,

procedimentos e pessoal), Sistemas de Tecnologia da Informao para C2 - STIC2 e

coordenao.

O Sistema de C2 responde a princpios que so pressupostos a serem observados

no decorrer do planejamento e execuo de suas atividades. Os comandantes podero

atribuir maior ou menor grau de importncia a esses princpios em funo da situao
operacional. Os princpios so:

a) Unidade de Comando: responder a necessidade da convergncia de esforos

necessria para o sucesso da misso. Compreende as idias bsicas de cadeia de

comando bem definida, comunicao segura e confivel entre as foras

empregadas na operao, doutrina operacional bem compreendida, treinamento,

acompanhamento das aes planejadas e ordens emanadas de um nico
comandante;

b) Simplicidade: atender aos requisitos para o qual foi concebido, evidenciando a

concepo e o emprego racional dos meios disponibilizados para a operao;

c) Segurana: negar ou dificultar o acesso no autorizado s informaes das foras

amigas, restringindo a liberdade de ao do oponente para ataques aos pontos

sensveis do sistema de C2;

d) Flexibilidade: ser capaz de ser reconfigurado com agilidade de forma a atender

as mudanas que venham a ocorrer na operao. Dever ter a capacidade

introduzir produtos e conceitos derivados de inovaes tecnolgicas, alm de

adequar-se s condies impostas por reestruturaes administrativas ou s

alteraes nos quadros poltico e estratgico;

e) Confiabilidade: capacidade de proporcionar credibilidade a seus usurios, de

sobrevivncia e manuteno da eficcia, quando exposto a eventos
desestabilizadores provenientes do ambiente operacional, de danos internos ou
de casos fortuitos;

f) Continuidade: poder operar ininterruptamente. O seu planejamento dever

sempre contemplar a utilizao de redundncia de meios e enlaces;
6

g) Agilidade: proporcionar rapidez ao processo decisrio. Possibilitar o acesso

imediato s informaes de interesse por todos os escales de comando;

h) Amplitude: Os meios empregados para o apoio de C2 devem se estender por

toda a rea de atuao; e

i) Integrao: Um sistema de C2 de um determinado escalo no isolado; faz

parte do sistema do escalo superior e abrange os sistemas dos escales
subordinados; e deve ter a capacidade de compartilhar informaes com foras
de mesmo nvel.

No que se refere aos STIC2, estes devem permitir que um grande volume de

informao seja disponibilizado aos diversos nveis da cadeia de comando, o que

permite aumentar a concincia situacional em que se encontram as foras componentes

da operao e, em consequncia, ajudar o comandante a tomar as decises necessrias

para o andamento das aes.

Conscincia situacional a percepo do ambiente operacional em que se atua

no decorrer do cumprimento da misso [2]. A conscincia situacional ser melhor

quanto mais apurada for a percepo da realidade operacional das aes, o que

alcanado atravs da disponibilidade da informao e impactar diretamente no ciclo de

tomada de decises.

O ciclo OODA [2], tambm conhecido como ciclo de Boyd [42], um dos

modelos aplicveis ao C2, segundo o qual qualquer ao integrante de um processo

decisrio parte de uma de suas quatro fases: Observar, Orientar-se, Decidir e Agir
(OODA).

Figura 2.1 - Ciclo OODA

Fonte: Ministrio da Defesa/Brasil [2]

O ciclo OODA, Figura 2.1, um processo contnuo onde suas fases ocorrero

em paralelo. O comandante receber as informaes, formar sua conscincia

situacional e tomar decises sobre as operaes futuras, enquanto operaes correntes

sero executadas por meio de aes dos escales subordinados.

Os comandantes das foras oponentes tambm executam o ciclo OODA, com

isso as decises de um comandante acabam influenciando as decises do comandante

oponente, j que quem completar o ciclo antes do adversrio influencia o cenrio a

partir do qual as decises do outro lado so tomadas. Quanto menor a durao deste
ciclo, mais gil o processo decisrio [2].

No entanto, a efetividade do ciclo OODA no ser garantida apenas pela sua

velocidade. A qualidade da informao ter importncia singular, pois se a percepo do

ambiente for falsa, inadequada ou incompleta, se as informaes forem analisadas

incorretamente, ou se as aes implementadas no corresponderem deciso tomada, o
ciclo no afetar o ambiente de acordo com a inteno do comandante [2].

Portanto, a percepo das informaes e do ambiente torna-se mais prxima da

realidade, medida que os ciclos estejam apoiados em processos e estruturas eficientes

e seguros [2].

2.2 Interoperabilidade
A Doutrina Para o Sistema Militar de Comando e Controle [2] d

interoperabilidade a seguinte definio:

a capacidade de os sistemas, unidades ou foras de

intercambiarem servios ou informaes ou aceit-los de outros sistemas,

unidades ou foras e, tambm, de empregar esses servios ou informaes,

sem o comprometimento de suas funcionalidades.

Para que a interoperabilidade possa ser vista de forma mais abrangente, deve

compreender, alm do nvel tcnico, o nvel organizacional, como pode ser observado
na figura a seguir.

Figura 2.2- Evoluo da Interoperabilidade

Fonte: Ministrio da Defesa/Brasil[2]

Na Figura 2.2, pode ser observada a convergncia dos nveis organizacional e

tcnico, constituindo a interoperabilidade de forma precisa, no que tange os sistemas de

C2.

A interoperabilidade constitui-se tambm da soma de integrao de sistemas,

integrao de redes, troca de dados entre sistemas e definio de tecnologia,

9

considerando, tambm, a existncia de um legado de sistemas, de plataformas de

hardware e software instaladas.

Alm dos aspectos tcnicos apresentados, processos e cultura organizacional

devem ser gerenciados para maximizar oportunidades de troca e reuso de informaes.

A meta deve ser o funcionamento cooperativo entre os diversos sistemas, respeitando

normas, polticas e padres estabelecidos[16].

A fim de alcanar a plena interoperabilidade, necessrio que cada sistema

tenha um entendimento comum sobre a semntica dos dados trocados[15], unificando e

padronizando conceitos entre eles.

Em uma perspectiva histrica, trs diferentes paradigmas para troca de

informaes so considerados no contexto de defesa: Military Messaging, Common

Data Models e Tatical Data Links [15].

O paradigma Military Messaging remonta aos primeiros dias dos equipamentos

de teletipo quando os padres de protocolo como ACP127 foram desenvolvidos para a

camada de protocolo. Com o surgimento de padres comerciais, tais como X.400, o

mercado de defesa adotou esta norma e estendeu-a para formar ACP123 /

STANAG4406. Muitos pases tm ou esto em processo de desenvolvimento de
sistemas que so compatveis com Military Messaging. Assim, historicamente Military

Messaging foi originalmente baseada em princpios de comunicao clara entre as

pessoas, em vez de sistemas, mas posteriormente tambm foi utilizada automaticamente
entre sistemas[15].

Tatical Data Links (TDLs) tm sido usados por muitos anos para o intercmbio

de funcionalidades C2 ttico, bem como para o intercmbio de informaes sobre a

conscincia situacional quase em tempo real[15]. TDLs utilizam terminais constitudos

basicamente por rdios que transmitem informaes aos outros sistemas que participam

do mesmo grupo na rede. Assim, usando TDLs no h registro histrico sobre o que

aconteceu, o que faz sentido quando a informao mais recente a nica informao
relevante[15].

O terceiro paradigma, Common Data Models, passa pela adoo do modelo de

dados Joint Consultation, Command and Control Information Exchange Data Model

(JC3IEDM), desenvolvido pelo frum multinacional Multilateral Interoperability

Program (MIP) e adotado pela OTAN com o objetivo de viabilizar a integrao entre
sistemas de C2[15]. Este trabalho se concentra no estudo deste paradigma.

Apesar do JC3IEDM fornecer um modelo de dados, estabelecendo uma

semntica comum, necessrio um mecanismo de intercmbio de dados que permita a

10

efetiva utilizao deste modelo padro entre os sistemas de C2 envolvidos. As

especificaes Alternate Development and Exchange Method (ADEM) e Battle

Management Language (BML) so alternativas que fornecem os mecanismos

necessrios e sero apresentados no decorrer deste trabalho.

2.3 Sistemas e frameworks existentes

Para a efetivao da interoperabilidade necessria adoo de propostas

arquiteturais, tecnologias e padres que permitam a conexo entre os sistemas.

Como padro principal para o estabelecimento de uma linguagem comum, no

que tange a atividade de comando e controle, a adoo do JC3IEDM permite um

entendimento sobre a semntica das informaes, visando unificar e padronizar

conceitos entre os diversos sistemas envolvidos. Complementando o JC3IEDM, as
especificaes ADEM e BML fornecem os mecanismos de troca de dados necessrios.

Ainda, dois frameworks apresentam propostas de soluo para as necessidades

dos sistemas de C2: o SitaWare, desenvolvido pela empresa Systematic Software

Engineering[15], e o Wise-SBML, um BML Server baseado no SAAB Widely

Integrated Systems Environment (WISE) um framework produzido pela SAAB Defense
Systems[17].

2.3.1 - JC3IEDM
O modelo JC3IEDM representa a viso de alto nvel da informao em termos

de conceitos gerais, como aes, organizaes, material, pessoal, recursos, instalaes,

locais e afins, representados em entidades. As propriedades, ou caractersticas, dessas

entidades so referidas como atributos, que tornaro explcitos os dados a serem
gravados para cada conceito de interesse.

A edio do JC3IEDM 3.1.4, datada de fevereiro de 2012 [10], tratada neste

estudo, contm 292 entidades. Toda a estrutura gerada a partir de 19 entidades

independentes, isto , as entidades cujas identificaes no dependem de qualquer outra
entidade. Todas as outras entidades so entidades dependentes.

A seguir so apresentadas as entidades independentes e a funo geral de cada

uma delas [10].

11

Entidade

ACTION

ADDRESS

AFFILIATION
CANDIDATETARGET-LIST
CAPABILITY
COMPONENTHEADER-CONTENT
COMPONENT-TEXTCONTENT
CONTEXT
RELATIVECOORDINATESYSTEM
GROUPCHARACTERISTIC

LOCATION

OBJECT-ITEM

Tabela 2.1- Entidades independentes do JC3IEDM [10]

Definio
Uma atividade, ou a ocorrncia de uma atividade,
que possa utilizar recursos e pode ser focada contra
um objetivo. Exemplos so ordem de operao,
plano de operao, ordem de movimentao, o
plano de deslocamento, ordem fogo, plano de fogo,
misso fogo, misso de apoio areo aproximado,
pedido de logstica, evento (por exemplo, entrada
aeronaves desconhecido), ou incidente (por
exemplo, ataque inimigo).

Regra

Informaes precisas sobre um endereo fsico ou

eletrnico pode ser acessado.

Prov meios para registrar

endereos postais e eletrnicos.

Uma especificao de um pas, nacionalidade, grupo

etnico, grupo funcional, grupo de exerccio, ou
religio a que pertena ou fidelidade pode ser
atribuda.
Uma lista de objetos selecionados no campo de
batalha, ou tipos que tm valor potencial de
destruio ou explorao, nomeados por autoridade
competente para a considerao no planejamento
das atividades de batalha.
A capacidade potencial para realizar um trabalho,
executar uma funo ou misso, alcanar um
objetivo ou fornecer um servio.
Assunto introdutrio destinado a identificar um
elemento de um plano ou ordem.
Uma declarao textual do assunto principal.
Uma coleo de informaes que fornece, em sua
totalidade, as circunstncias, condies, meio
ambiente ou perspectiva para uma situao.
Uma moldura retangular de referncia definida por
uma origem, eixos x e y em relao ao plano
horizontal, e um eixo z. O eixo vertical z
perpendicular ao plano xy com sentido positivo
determinada a partir da regra da mo direita,
quando o eixo x rodado na direco do eixo y.
Uma referncia a um conjunto de caractersticas
que podem ser usadas para a identificao de um
conjunto distinto de objetos. Exemplos de
caractersticas incluem faixa etria, doena, sexo,
lngua e classificao de triagem.
Uma especificao de posio e geometria com
relao a uma determinada estrutura horizontal de
referncia e uma distncia vertical medida de um
determinado ponto de referncia. Os exemplos so,
seqncia de pontos, linhas poligonais, crculo,
retngulo, elipse, fan area, rea poligonal, esfera,
bloco do espao e o cone. LOCATION especifica
localizao e dimensionalidade.
Um objeto identificado individualmente, que tem
um significado militar ou civil. Exemplos so uma
pessoa especfica, um item de material especfico,
uma caracterstica geogrfica especfica, uma
coordenada geogrfica especfica ou uma unidade
especfica.

12

Dinmica (como, o qu, quando

algo est a ser feito, est sendo
feito, ou foi feito).

Fornece meios para atribuir

filiaes para tipos ou objetos.
Informao para apoiar uma
ACTION.
Indicao da capacidade
esperada para tipos de objetos e
capacidade real de um objeto.
Utilizado em conjunto com as
especificaes de planos e
ordens.
Utilizado em conjunto com as
especificaes de planos e
ordens.
Mltiplas funes incluindo
agrupamento de informaes.

Suporte localizao para

especificar geometria relativa.
Suporta a contagem dos tipos de
pessoas de acordo com
caractersticas selecionadas.

Geoposicionamento de objetos e
criao de formas.

Identifica as coisas
individualmente (Quem e O
Que).

OBJECT-TYPE

PLAN-ORDER
REFERENCE

Identificao de um registo de informao.

REPORTING-DATA
RULE-OFENGAGEMENT
SECURITYCLASSIFICATION
VERTICALDISTANCE

Uma classe de objetos identificada individualmente,

que tem um significado militar ou civil. So
exemplos um tipo de pessoa (por exemplo,
classificao), um tipo de material (por exemplo,
obus motorizado), um tipo de instalao (por
exemplo, aeroporto), um tipo de recurso (por
exemplo, uma rea de fogo restrita), ou um tipo de
organizao (por exemplo, a diviso blindada).
Um esquema planejado ou ordenado trabalhado
previamente para a realizao de um objetivo
operacional.
Especificao da fonte, a qualidade e o tempo que se
aplica aos dados comunicados.
Especificao de orientao obrigatria para a
forma como uma determinada atividade dever ser
executada.
Classificao de segurana aplicvel a um recurso
de informao dentro do domnio de informaes
classificadas.
Uma especificao da altitude ou a altura de um
ponto ou um nvel conforme medido em relao a
um dado de referncia especificado na direo
normal ao plano que tangente ao elipside de
revoluo WGS84.

Identifica uma classe de coisas

(Quem e O Que).
A entidade de alto nvel para a
identificao de um plano ou
ordem.
Aponta para uma informao
externa em apoio do
REPORTING-DATA.
O suporte para a funo de
reporte.
Suporte para ACTION.
Suporte a CONTEXT,
NETWORK-SERVICE
e REFERENCE
Suporte para o LOCATION na
especificao altitude ou altura.

As 19 entidades independentes e seus relacionamentos so apresentados no

modelo de dados a seguir. Um ponto no final de uma linha indica "muitos". Os

relacionamentos mostrados no diagrama so ou muitos-para-muitos (linha slida com
dois pontos) ou no-identificado um-para-muitos (linha a tracejado).

13

Figura 2.3- Modelo simplificado do JC3IEDM

O modelo apresentado est no padro IDEF1X[43], um mtodo para a

concepo de bancos de dados relacionais com uma sintaxe concebida para suportar as
construes semnticas necessrias no desenvolvimento de um esquema conceitual, que

permite o uso de relacionamentos muitos-para-muitos s a nvel conceitual em

diagramas explicativos. Entretanto, o modelo de dados completo deve substituir os

relacionamentos muitos-para-muitos por estruturas adequadas que admitem apenas

relacionamentos um-para-muitos. A resoluo dos relacionamentos muitos-para-muitos

levar a estruturas complexas, cujo resultado ser o modelo JC3IEDM final, com suas
292 tabelas.

Para o contexto das operaes realizadas em conjunto pelas naes que adotam o

modelo JC3IEDM, o MIP definiu o Data Exchange Mechanism (DEM), que especifica
como atravs de conexo ponto-a-ponto entre os sistemas de informao de C2 dessas
14

naes, devem ser realizadas replicao de banco de dados e trocas de mensagens.

Obviamente, a complexidade inerente do modelo JC3IEDM e suas diversas regras de

negcio, tornam a implentao do DEM em um nvel de dificuldade muito grande.

De forma a contornar os problemas de implementao do DEM, o MIP elaborou

a especificao ADEM, que define um mtodo de intercmbio de dados focado na

Situao Corrente, utilizando a semntica do JC3IEDM e que oferece uma mudana de

paradigma para troca de informaes.

2.3.2 - ADEM
A especificao Alternate Development and Exchange Method (ADEM)

complementar a especificao do MIP DEM, oferecendo meio de intercmbio

alternativo ou complementar para aqueles sistemas em que no prtico, ou desejvel,

implementar uma soluo MIP DEM completa [14].

Destacam-se os principais benefcios do ADEM:

Melhorar a distribuio de informao no C2 para um conjunto mais vasto

de potenciais parceiros de misso1. A melhora no compartilhamento de
informaes equivale a melhora na tomada de deciso e a eficcia por uma
comunidade C2 maior;
Demonstrar a flexibilidade do JC3IEDM; e

Encorajar a contribuio tcnica de parceiros externos envolvidos no

programa MIP.

Com o ADEM, possvel realizar o intercmbio de informaes de forma

simples e extensvel, usando padres abertos, facilitando a comunicao com as

Comunidade de Interesse (COI do ingls Communities of Interest), que podem no estar

dispostas, ou serem capazes, de implementar a especificao do MIP DEM. A

expectativa preencher a lacuna existente entre a comunidade MIP e os COIs, de forma

a melhorar o compartilhamento de informao entre os parceiros de misso.

O ADEM tem como proposta, disponibilizar vrios padres de intercmbio de

dados, utilizando tecnologias comumente empregadas pelos desenvolvedores de

sistema, incluindo, mas no se limitando a: Publish / Subscribe, Request / Response,

Compartilhamento de Arquivos, Servios de Dados Distribudos (DDS), Web Services
e etc.

Como parceiros de misso podem ser includos, mas no esto limitados a, os parceiros militares
sujeitos a diferentes nveis de segurana, o pessoal de emergncia civil (polcia, bombeiros, etc.) e as
agncias de segurana, ONGs, outros rgos governamentais e etc.
1

15

A simplificao da troca de informaes pelo ADEM concentra-se em pequenas

estruturas discretas de informao, que tm valor operacional (ou seja, objetos de

batalha, eventos e associaes entre eles). Este conjunto de estruturas de informao no

finito, podendo o parceiro COI estender essas estruturas de informao com contedo
especfico.

Figura 2.4 - Intercmbio de informaes MIP x no MIP

Fonte: ADEM CONOPS [14]

Na figura 2.4 exemplificado como as informaes de C2 so trocados entre

sistemas baseados nas especificaes MIP e outros sistemas parceiros no MIP. Nessa

representao, o prestador de informaes MIP tambm implementa um mecanismo de

intercmbio ADEM para alm da sua implementao MIP DEM, de forma a interoperar
com outros sistemas da COI.

16

O ADEM subdivido em seis grupos de especificaes nas quais as aplicaes

que adotam o modelo devem ser embasar. So elas:

a) Intercmbio de Informaes, que so documentos que fornecem uma viso

tcnica geral, importante para entender o restante da especificao, explorando
cenrios especficos de intercmbio de informaes.

b) Conjunto de Capacidade, que define o conjunto de informaes conhecidas que

podem ser trocadas usando as especificaes ADEM. Esto agrupadas nos

seguintes conjuntos de recursos: Capacidades de viso, Capacidade dos objetos
do campo de batalha, Capacidade de Eventos, Capacidade de Tarefas e
Capacidade de Relatrio de objetos mnimo.

c) XML Schemas, que so definies de estruturas de dados, em arquivos XSD, que

representam os documentos do conjunto de capacidades dos objetos do campo

de batalha. Cada mensagem, comunicada via especificao ADEM, dever

basear-se na estrutura definida em um destes arquivos de esquema.

d) Padres de intercmbio, que descrevem como documentos podem ser trocados.

Como existem casos em que um nico mecanismo de intercmbio no

suficiente, vrios padres esto definidos. Na verso atual da especificao

ADEM, so definidos os seguintes padres de intercmbio para uso pelos

desenvolvedores: publish / subscribe, request / response, arquivos e baixa

largura de banda.

e) Definies de Web Services, arquivos WSDL que contm as especificaes

tcnicas dos padres de intercmbio que so implementados usando web

services.

f) Especificao de teste, que fornecem a capacidade de medir o grau em que um

sistema capaz de definir, compartilhar, consumir e exibir informaes usando

as especificaes tcnicas ADEM.

2.3.3 - BML
A Battle Management Language (BML), e suas vrias extenses, destinam-se a

facilitar a interoperabilidade entre sistemas de Comando e Controle (C2) e sistemas de

Simulao (C2-SIM), fornecendo um formato comum para a troca de informaes, tais

como ordens e relatrios. A abordagem proposta pela BML a utilizao de um

middleware para troca de arquivos no padro Extensible Markup Language (XML)

junto com a tecnologia WebServices [21].

17

A BML comeou a ser desenvolvida durante os trabalhos do Simulation-to-C4I

Interoperability Overarching Integrated Product Team (SIMCI OIPT), patrocinado pelo

Exrcito dos EUA, cujo objetivo era mostrar a viabilidade da definio de uma

linguagem clara, sem ambigidades, com base em manuais e que capturava a doutrina
militar [19].

Importante notar que a BML no foi concebida como uma soluo

exclusivamente tcnica, mas como uma abordagem para apoiar as necessidades e

exigncias do combatente operacional [22]. Assim, pode-se considerar a BML como
uma especificao de referncia que originou diversas extenses, onde se destacam
XBML, JBML e C-BML(Full e Light).

A eXtensible Battle Management Language (XBML) foi desenvolvida a partir

do trabalho iniciado com a BML, com a misso de adicionar a capacidade para atender

operaes Conjuntas e Combinadas/Coalizo BML. Um de seus fundamentos era a

utilizao de tecnologias Web para a interoperabilidade entre sistemas, sendo seus dois

objetivos principais: (1) usar a tecnologia Service Oriented Architecture (SOA) para a
troca de informaes entre as interfaces dos sistemas e (2) usar o Command and Control
Information Exchange Data Model (C2IEDM, uma verso anterior do JC3IEDM ) do

MIP como uma base para representar as informaes a serem trocadas entre os sistemas
[19].

A implementao da Joint BML (JBML) foi o passo seguinte a XBML, tendo

como particular interesse a semntica por trs do vocabulrio de C2 comum para

intercmbio de dados, proporcionado pelo MIP, independente de sistema. Com isso

expandiu-se para a arena de operaes conjuntas, incluindo os domnios terra, ar e mar,

bem como a guerrilha urbana. O JBML alcanou progresso tcnico considervel,

criando um esquema WebService revisado, com base em gramtica formal e projetado
para facilitar a expanso para outros domnios militares [22].

18

Figura 2.5 - Arquitetura JBML Viso Geral

Fonte [22]

A figura 2.5 apresenta uma viso geral da arquitetura de WebServices do JBML,

onde so identificadas as principais camadas da arquitetura.

A camanda mais alta, BML Domain Configured Service (DCS), representa a

linguagem de domnio especfico na forma de um esquema baseado em gramtica que

utilizado atravs da implementao do WebServices. O esquema define o DCS em

termos dos BML Base Services (BBS), camada mdia que representa os grupos de
elementos de informao que especificam objetos de informao de interesse, como as

5Ws (quem - who, o qu - what, onde - where, quando - when, porqu - why) e outras
construes de interesse [22].

J a camada mais baixa, que representa a troca de informao de elementos de

informao e que normalmente escondida do usurio, a BML Common Data Access

Services (CDAS) [22].

A Integrated BML (IBML IBML09), desenvolvida em 2009, foi uma primeira

tentativa de padronizar BML. A IBML09 tambm a base para uma verso estendida

desenvolvida no Instituto Fraunhofer (FKIE) [23]. Trata-se de uma coleo de produtos

e especificaes comuns e integradas que servem como uma base comum para o
desenvolvimento e produo de processos de C2 avanados, incluindo ordens, relatrios
e capacidades geoespaciais entre as partes interessadas.
19

A C-BML (Coalition Battle Management Language) uma linguagem no ambgua

para descrever a inteno do comandante em operaes simuladas ou reais. Ela define

um formato digital para as informaes de C2, tais como ordens, planos, relatrios e
solicitaes. Em um formato digital, as informaes de C2 podem ser facilmente
processadas por sistemas de C2, sistemas de simulao ou interfaces a foras
automatizadas (por exemplo, sistemas robticos).

A Simulation Interoperability

Standards Organization (SISO)2 desenvolveu a C-BML como uma representao

padronizada para operaes conjuntas, combinadas e de coalizo, de acordo com

requisitos de C2 e de sistemas de simulao, com base em um modelo de referncia

comum (por exemplo, o MIP-JC3IEDM).

A figura 2.6 apresenta um conjunto de possveis relacionamentos produtor /

consumidor C-BML, representando uma viso de diversas reas de interoperabilidade.

Figura 2.6 - Matriz produtor / consumidor C-BML

Fonte [24]

Caractersticas da C-BML que devem ser observadas [24]:

Interface Comum: um dos impulsos da C-BML a necessidade de uma

interface comum entre os sistemas de C2, de simulao e robticos. Isso

permite que o usurio operacional interaja com um sistema de C2 e

O Simulation Interoperability Standards Organization (SISO) uma organizao internacional dedicada
promoo da modelagem e simulao de interoperabilidade (https://www.sisostds.org/Home.aspx).
2

20

aplique os mesmos procedimentos em um contexto operacional real, em

um exerccio de treinamento ou para misso de ensaio. Ela permite a um

nico sistema de C2 trocar informaes com mltiplos sistemas de

simulao sem a necessidade de diferentes interfaces cada sistema de

simulao.

Expressividade: A definio e especificao de C-BML deve permitir a

expresso de todas as aes relevantes a serem realizadas pelo
recebimento de unidades de fora (reais ou simuladas) e sistemas

robticos (por exemplo, tarefa, relatrios). Em particular, ele deve ser

capaz de expressar uma ordem operacional e dar suporte para os

relatrios militares e mensagens tticas.

Ausncia de ambiguidade: A natureza no ambgua de expresses C-

BML permitir a construo de representaes matemticas ou mquinas

de informao tais como tarefas e ordens, de tal forma que as simulaes
ou foras robticas possam processar de forma automatizada. Isto

implica a utilizao de uma gramtica formal e requer uma anlise

significativa, a fim de apoiar conceitos como a inteno de comando e

estado-final desejado.

Interpretvel (parseable): Expresses C-BML devem ser capazes de

serem transferidas atravs de sistemas de informao, sem interveno
humana, a fim de permitir a transferncia direta e automtica de dados

entre sistemas de C2, simulao e robticos. Isso vai ajudar a eliminar

situaes que envolvam transferncia manual de dados, onde o operador

tem de assimilar e transferir informaes de um sistema para outro. Da

mesma forma, isso vai permitir a eliminao gradual dos operadores de
simulador que so necessrios para suportar cenrios de treinamento,

transferindo manualmente ordens para a simulao. Estes processos so

ambos lentos e sujeitos a erros.

Usabilidade: A linguagem C-BML deve ser fcil de usar. Deve ser

simples para construir expresses vlidas e fcil de aprender a usar a

interface para a troca de mensagem. A linguagem deve possibilitar uma

entrada fcil e rpida para especificao de uma ordem e / ou a
apresentao de um relatrio. A C-BML baseada no JC3IEDM como

um modelo de dados subjacente, mas no deve exigir que todos os

21

usurios C-BML (por exemplo, desenvolvedores) sejam especialistas

JC3IEDM.

Um BML Server permite a conexo de sistemas ou aplicaes em um ambiente

comum e cria um fluxo de informao entre eles, independentemente da arquitectura,

das normas e protocolos de comunicao, dando suporte a interoperabilidade atravs do
uso da BML e seus diversos dialetos.

A primeira gerao de BML Server foi implementada inteiramente em Java /

JAXB e provia WebServices baseados em SOAP[19].

A segunda gerao de BML Server foi escrita em Java e implementada em JBoss

(4.2.3). Esta verso foi conhecida como Scripted BML (SBML). Nesta verso,
processamento e mapeamento especficos para o modelo JC3IEDM eram providos por
uma linguagem de script conhecida como CSL [19].

2.3.4 WISE-SBML
O WISE-SBML, terceira gerao de servidor BML, baseado na soluo SAAB

Widely Integrated Systems Environment (WISE), um framework produzido pela SAAB

Sistemas de Defesa. A implementao BML desenvolvida em C ++ e executada sob
WISE em um servidor Windows 7[19].

As principais funcionalidades do WISE-SBML so caracterizadas pela recepo

e validao de documentos BML, traduo entre diferentes dialetos BML, distribuio

de documentos para os assinantes, processamento de consultas de documentos recebidos

anteriormente que tenham sido guardados no servidor e o registo de documentos BML

recebido durante uma sesso de simulao, repassando-as com sincronizao de
tempo[20].

O servidor suporta WebServices RESTFul, recebendo documentos XML no

formato BML, em um dos quatro dialetos previstos. Os documentos BML de sada so

publicados usando o protocolo STOMP (Simple Text Oriented Messaging Protocol),

para os clientes que tenham assinado o servio, caracterizando assim a utilizao do

padro arquitetural publishsubscribe[20].

A figura 2.7 apresenta a arquitetura de um servidor WISE-SBML.

22

Figura 2.7 - Arquitetura Wise-SBML

Fonte [20]

O servidor WISE-SBML fornece suporte aos seguintes dialetos BML[19]:

IBML 2009;

C-BML Light, e

IBML Fraunhofer-FKIE Variant;

C-BML Full.

2.3.5 SitaWare Coalition Gateway

O SitaWare Coalition Gateway faz parte de uma famlia de software de C2

criados pela empresa dinamarquesa Systematic Software Engineering. Trata-se de um

hub de interoperabilidade que conecta diversas solues C2. Como apresentado na

figura 2.5, o SitaWare contempla vrios padres de comunicao de dados, permitindo a
troca de informaes entre sistemas desenvolvidos em diferentes tecnologias.

23

Figura 2.8 Tecnologias que compe o SitaWare

Fonte: https://systematic.com/

No conjunto de tecnologias apresentadas na figura 2.8, possvel destacar o

suporte ao JC3IEDM. Como o SitaWare segue os princpios SOA, a adoo desta

soluo, facilita a integrao com diferentes sistemas especialistas e sistemas legados.

A robustez da proposta da soluo foi posta a prova durante as operaes da

coalizao internacional no Afeganisto, ISAF (Fora Internacional de Assistncia

Segurana). Participaram desta operao 43 naes, sendo 28 membros da OTAN, que
utilizam diferentes solues de sistemas de C2. Foram aplicados os modelos C2IEDM

(MIP Baseline 2, j descontinuado) e o JC3IEDM (MIP Baseline 3, tratado neste

trabalho). O sucesso da interoperabilidade com base nesses padres foi demonstrado a

partir da atualizao dinmica da conscincia situacional ttica, que pde ser facilmente
24

compartilhado entre o sistema de C2 do Reino Unido e os sistemas C2 dos parceiros de

coalizo [18].

2.4 Parmetros de Interoperabilidade entre Sistemas de C2

Na conceituao de Comando e Controle foram apresentados os princpios de

unidade

de

comando,

simplicidade,

segurana,

flexibilidade,

confiabilidade,

continuidade, agilidade, amplitude e integrao. O conjunto destes conceitos forma a

base para a construo da conscincia situacional conjunta, da operao em curso, por
parte do comandante.

Levando-se em considerao, tambm, o ciclo OODA, conclui-se que esses

princpios

ajudam

definir

os

requisitos

interoperabilidade em comando e controle.

funcionais

necessrios

para

A soluo de interoperabilidade deve atender a requisitos no-funcionais para

dar o suporte necessrio ao processo de obteno e compartilhamento da conscincia

situacional. Esses requisitos, que tambm representam mtricas a serem observadas,

podem ser vistos na tabela 2.2.

Tabela 2.2- Mtricas tcnicas para soluo de interoperabilidade [8]

Tipo de Requisito

Volume

Tempo de Resposta

Tamanho
Timeliness
Padro de Formato de Dados
Handshaking protocol
Infraestrutura de Comunicao

Descrio

Volume de dados que

precisa ser trocado entre
aplicaes.
Tempos de resposta
mnimos para realizao de
tarefas do usurio tratadas
pela integrao de
aplicaes.
Tamanho do dado que a
integrao entre aplicaes
deve tratar (relacionado ao
volume).
Urgncia da comunicao
ou integrao entre
aplicaes.
Formato dos dados
transferidos entre
aplicaes.
Adeso a um protocolo
particular em relao a
troca de interaes entre
aplicaes.
Restries da infraestrutura
de comunicaes nas
aplicaes a serem
integradas.

25

Exemplos

10.000 transaes/hora, 120

requisies/minuto, ou
500Kbytes/segundo.
5 segundos.

Tamanho de Arquivo de at
10Mbytes.
Tempo real, dentro de 2
segundos, ou em at 2 horas.
Suporta formato ebXML,
formato EDI ou lida com
formato proprietrio.
De acordo com RosettaNET
PIP 2345, ou de acordo com
uma sequencia proprietria de
troca de mensagens.
Mensagens SOAP em HTTP
ou um formato proprietrio de
mensagem sobre IBM MQ
messsaging.

Resilincia e Recuperao

Frequncia
Segurana

Resilincia da estrutura de

Garantia da entrega de

falhas.

downtime menor do que

integrao em caso de

mensagens, redundncia e
cinco por cento.

Frequncia de interaes

Tempo real, ou em uma hora,

Nvel de segurana exigido

Autenticao por usurio e

necessria entre aplicaes.

entre aplicaes.

a cada hora.

senha no HTTPS; mensagens

no-criptografadas, suporte a
certificados digitais para

autenticao, autorizao e
no-repdio.

26

Captulo 3
Arquitetura Orientada a Servios (SOA)
Neste captulo ser apresentado o conhecimento terico necessrio a

compreenso bsica de uma Arquitetura Orientada a Servios (SOA). Esse

conhecimento permitir visualizar de que forma uma soluo elaborada a partir dos

conceitos de SOA pode ajudar a atingir o objetivo pretendido para a integrao dos
sistemas de comando e controle.

3.1 Conceitos

A Arquitetura Orientada a Servios (SOA do ingls Service-Oriented

Architecture) possui diversas definies, mas um ponto principal a compreenso de

que um estilo de arquitetura de software cujo princpio fundamental prega que as

funcionalidades implementadas pelas aplicaes devem ser disponibilizadas na forma

de servios.

Como uma definio formal, pode-se citar que SOA uma forma de

desenvolvimento de sistemas distribudos em que os componentes de sistema so

servios autnomos, executando em computadores geograficamente distribudos. O

suporte comunicao desses servios baseado em padres de protocolo tais como
XML, SOAP e WSDL, o que permite a conexo destes no importando sua forma de

implementao, independentemente da adoo de linguagem ou tecnologias

especificadas. Assim, os sistemas de software podem ser construdos pela composio
de servios locais e servios externos de provedores diferentes, com interao perfeita
entre os servios no sistema [39].

De forma a conceituar servio, pode-se dizer que os servios nos rodeiam em

nosso cotidiano, sendo algo trivial na histria da civilizao. Qualquer atividade

executada por uma pessoa, ou grupo de pessoas, em apoio outra atividade, ou uma

funo de negcio de uma empresa, representa um servio prestado ou fornecido [5].

Assim, nesse processo possvel estabelecer uma relao fornecedor x consumidor.

Essa relao uma das principais caractersticas da arquitetura SOA, onde
27

funcionalidades de sistemas diversos so organizados de forma lgica a fim de

proverem recursos como servios.

A Figura 3.1 ilustra a relao fornecedor x consumidor. O fornecedor do servio

aquele que implementa e tem domnio sobre um servio; o registro de servio um

repositrio onde fornecedores de servio podem registrar seus servios para que eles

sejam localizados pelos consumidores; e o consumidor do servio aquele que localiza

um servio e o executa. O contrato a especificao do servio que possui as
informaes necessrias para que o consumidor possa localiz-lo e invoc-lo [26].

Figura 3.1- Relao fornecedor x consumidor [26]

Ainda, segundo Erl [5], um servio pode fornecer uma coleo de capacidades,

que so reunidas de acordo com um contexto funcional estabelecido pelo servio com o
qual elas se relacionam. Funcionando como um container de capacidades, ser

composto pela lgica de execuo das capacidades e por contratos de servios, que
definem quais capacidades estaro disponveis para utilizao.

A capacidade de servio no tem implicaes sobre a forma como um servio

implementado, mas este conceito pode ser particularmente til durante a fase de
modelagem de servios quando o desenho fsico de um servio ainda no foi
determinado [5].

28

3.2 Princpios
a) Contrato de servio padronizado (Standardized Service Contract)

O contrato o artefato principal da arquitetura de um servio e expressa seus

propsitos e capacidades [5], provendo as restries tcnicas, requisitos e informaes

do servio publicado. Pode ser descrito atravs de um conjunto de documentos, por

exemplo, WSDL, quando falamos de Web Services baseados em SOAP [27].
b) Baixo acoplamento de servio (Service Loose Coupling)

O acoplamento refere-se a uma conexo ou relacionamento entre dois elementos.

Este princpio enfatiza a reduo da dependncia entre o contrato de servio, sua

implementao e os consumidores do servio[5].

O princpio do Baixo Acoplamento de Servio permite que o design e a lgica

de um servio possam evoluir independentemente de sua implementao, ao mesmo

tempo em que garante a interoperabilidade bsica com consumidores que se utilizam

das capacidades do servio [5].

c) Abstrao de Servio (Service Abstraction)

O princpio de Abstrao de Servio enfatiza a necessidade de no deixar

pblica informaes sobre um servio que no sejam absolutamente necessrias para

quem efetivamente usar esse servio [5].

A abstrao fundamental para manter um baixo nvel de acoplamento e tem um

papel significativo na composio de servios [5].

d) Capacidade de reuso de servio (Service Reusability)

O princpio da capacidade de reuso de servio enfatiza o posicionamento de

servios, como recursos corporativos com contextos funcionais agnsticos [5].

Priorizar a reutilizao implica em um cuidado maior com os demais princpios.

Um servio ser mais reutilizvel na medida em que tiver menor acoplamento, maior
abstrao, autonomia e suporte a composio [27].

e) Autonomia de servio (Service Autonomy)

Este princpio suporta o grau em que outros princpios de design podem ser

efetivamente realizados em ambientes reais de produo, favorecendo caractersticas de

29

design que aumentam a confiabilidade e a capacidade de prever o comportamento de

um servio [5].

Manter um servio autnomo permite que ele possa atuar de forma

independente. Ou seja, sem qualquer necessidade de aprovao ou acompanhamento.

Quanto maior for a autonomia de um servio quanto a seu ambiente, mais fcil ser sua
manuteno e evoluo [27].

f) Independncia de estado do servio (Service Statelessness)

Excessivas informaes de estado podem comprometer a disponibilidade de um

servio e minar seu potencial de escabilidade. Idealmente, os servios devem ser

projetados para manterem informaes de estado apenas quando estas forem necessrias
[5].

g) Descoberta de servio (Service Discoverability)

O princpio de Descoberta de Servio prev o suporte a descoberta o que implica

na capacidade de determinar quais requisitos precisamos atender para poder utilizar um

servio que exista em um inventrio. Nesse sentido, os servios devem prover metainformao suficiente para que possam ser efetivamente descobertos e interpretados
[27].

h) Composio de servios (Service Composability)

A capacidade de compor efetivamente os servios um requisito crucial para

alcanar alguns dos objetivos mais fundamentais da computao orientada a servios

[5].

Servios devem ser participantes eficazes de composio, independentemente do

tamanho e da complexidade da composio. A capacidade de combinar as capacidades

de diferentes servios para resolver problemas maiores um dos fundamentos do SOA e

da computao distribuda [27].

A Figura 3.2 apresenta um resumo dos princpios de arquitetura orientada a

servios, mencionados anteriormente, e suas implicaes.

30

Figura 3.2 Princpios de SOA [28]

No tocante a interoperabilidade, um item que pode parecer ausente no conjunto

de princpio apresentados princpio segundo o qual os servios so interoperveis. A

razo de a interoperabilidade no aparecer como um princpio especfico decorre do fato

de que esta fundamental a cada um dos princpios que foram descritos. Portanto, em
relao a computao orientada a servios, afirmar que os servios devem ser
interoperveis quase to bsico como afirmar que os servios devem existir. Cada um
dos oito princpios suporta ou contribui para a interoperabilidade de alguma maneira
[5].

3.3 Tecnologia Usada

importante ter a viso da SOA como um modelo arquitetural que neutro para

qualquer plataforma. Os servios so disponibilizados em uma rede de computadores

(Internet ou Intranets), comunicando-se atravs de padres abertos. A maior parte das

implementaes de SOA se utiliza de Web Services. Entretanto, uma implementao de
SOA pode se utilizar de qualquer tecnologia web.
31

Segundo Thomas Erl [25], os servios podem ser construdos usando os padres

tecnlgicos tais como Componentes, Web Service e REST Service [25].

a) Servios como componentes

Um componente um programa de software concebido para ser parte de um

sistema distribudo. Ele fornece uma interface tcnica comparvel a uma interface de
programao de aplicativo tradicional (API), atravs do qual ele expe as capacidades

pblicas como mtodos, permitindo assim que seja explicitamente invocado por outros
programas [25].

Figura 3.3- Smbolos usados para representar um componente [25]

Na Figura 3.3, o smbolo no lado esquerdo um componente genrico que pode

ou no ter sido concebido como um servio, ao passo que o smbolo direita est
explicitamente marcado para indicar que foi concebido como um servio [25].
b) Servios como Web Services

Um Web Service um componente de soluo lgica que fornece um contrato

tcnico, fisicamente dissociado, que consiste em uma definio WSDL e uma ou mais

definies XML Schema, e tambm possveis expresses WS-Policy. O contrato do

Web Service expe recursos pblicos como operaes, estabelecendo uma interface
tcnica, mas sem qualquer ligao com um framework de comunicaes proprietrio
[25].

Figura 3.4 Arquitetura Web Service [25]

32

A figura 3.4 ilustra uma tpica arquitetura Web Service que contm um contrato

de servio, um componente e uma lgica de processamento de mensagens composta por

agentes event-driven, de acordo com o padro de servio Service Agent [25].

O protocolo mais comumente utilizado nas implementaes dos Web Services

Simple Object Access Protocol (SOAP).

SOAP um protocolo que utiliza a linguagem Web Services Description

Language (WSDL), baseada em XML, para descrever funcionalidades oferecidas por

um Web Service. O SOAP prov um padro bsico de comunicao, no qual cada

operao representada por seu terminal, descrito no documento XML enviado na
requisio, ao invs de um mtodo Hyper Text Transfer Protocol (HTTP) [29].

Completando as ferramentas base dos Web Services, a especificao Universal

Description, Discovery and Integration (UDDI) tem como objetivo descrever, descobrir
e integrar Web Services.

c) Servios REST

Representational State Transfer (REST) fornece um meio de construo de

sistemas distribudos baseados na noo de recursos. Servios REST (ou servios

RESTful) so programas leves que so projetados com nfase na simplicidade,

escalabilidade e facilidade de uso. Servios REST podem ser moldados pela aplicao
dos princpios de orientao a servios [25].

Por se tratar de uma abstrao dos princpios que compe a World Wide Web

(WWW), o REST se caracteriza pela escalabilidade, onde os servios fornecidos so

identificados por um Uniform Resource Identifier (URI), a partir da utilizao de

mtodos HTTP 1.0: GET, POST, DELETE e PUT. Um URI uma forma uniforme de
identificao de recursos em rede, sendo o seu tipo mais conhecido o Uniform Resource
Location (URL) [29].

Por fim, diferentemente do protocolo SOAP, o REST se trata de um modelo

arquitetural, com isso o retorno das chamadas pode ser formatado conforme os

requisitos da aplicao, por exemplo, utilizando Javascript Object Notation (JSON) ao

invs de XML [29].

Alm dos padres tecnolgicos citados, vale destacar mais duas tecnologias

aplicveis a arquitetura SOA: Enterprise Service Bus (ESB) e Business Process

Management System (BPMS).

33

d) Enterprise Service Bus (ESB)

Um Enterprise Service Bus (ESB) um middleware que tem o objetivo de

facilitar a integrao de sistemas. Geralmente um ESB possui as seguintes

funcionalidades: prover segurana, prover transparncia de localizao, transformar

mensagens, rotear e monitorar as mensagens, gerenciar os servios, entre outros [26].

Existem diversos produtos de ESB disponveis no mercado atualmente dos mais

diversos fornecedores, muitos destes com background do mercado de Enterprise

Application Integration (EAI). Existem, tambm, solues open source tais como Mule,
ServiceMix (adotado na soluo apresentada neste trabalho), OpenESB e JBossESB .
e) Business Process Management System (BPMS)

Como um servio pode representar uma funo de negcio dentro de uma

organizao, estes podem ser orquestrados representando fluxos de execuo dos

processos de negcio [26].

As ferramentas de BPMS fornecem os recursos necessrios que permitem a

execuo, controle e o monitoramento dos fluxos de processo [26].

De forma geral, uma ferramenta de BPMS possui como caractersticas bsica:

Ferramenta para modelagem e desenho do processo;

Orquestrao de Web Services e

Mecanismo de execuo do processo;

Interface de workflow para usurios.

3.4 Governana

A ltima seo deste captulo trata da governana, que uma das chaves de

sucesso na implementao de uma arquitetura SOA em uma organizao.

A governana SOA est relacionada s iniciativas que visam aumentar a

qualidade total de SOA, promovendo controle em ambientes complexos, no estando

relacionada s atividades ligadas construo dos servios.

Governana tambm est relacionada a pessoas, processos e produtos, onde:

Pessoas Para se certificar que as responsabilidades esto sendo

direcionadas corretamente, e que as pessoas estejam recebendo o devido

suporte para adquirir o conhecimento e habilidades necessrias [30].

Processos Para definir se os processos certos esto sendo aplicados

para garantir a qualidade e monitoramento dos servios [30].
34

Produtos Para cadastrar os requisitos dos servios e sua documentao;

Templates para serem usados na documentao dos servios tambm

recaem sobre essa categoria [30].

Na abordagem proposta por Schepers e Kratz [30], para que uma boa

governana SOA possa ser alcanada, seis processos devem ser executados: Estabelecer
a viso SOA, Criar a organizao SOA, Gerenciamento do portflio de servios,
Gerenciamento do ciclo de vida de servios, Execuo dos princpios e Gerenciamento
do Nvel de Servios.

Os primeiros dois processos mantm o foco no negcio. Os trs processos

seguintes dizem respeito ao foco dos arquitetos: gerenciamento do portflio de servios,

gerenciamento do ciclo de vida dos servios e o gerenciamento do nvel dos servios. O
ltimo processo, gerenciamento do nvel dos servios, de domnio do administrador
do sistema [30].

a) Estabelecer a viso SOA

Durante o ciclo de vida da governana, o primeiro passo da iterao estipular

objetivos SOA a longo prazo ou revisar os objetivos existentes. Esse processo no s

determina a perspectiva SOA na organizao como tambm define os objetivos para a

iterao corrente dentro do ciclo de vida. A viso SOA um produto das reas de
negcio e TI, onde o alinhamento conduzido pelo arquiteto.
b) Criar a organizao SOA

Nessa etapa do processo, os papis e responsabilidades da governana SOA so

definidos. Muitas vezes isso leva a iniciao de um tipo de comit que deve ser

composto pelos responsveis pela governana; De analistas de negcio a profissionais

de TI, o comit decide como o ciclo de vida de governana SOA ser implementado.

Para a execuo da iterao corrente do ciclo de vida, as pessoas certas precisam

estar no lugar certo. Isso pode requerer, no somente um treinamento extra, como

tambm contratao ou investimento em desenvolvedores. O comit de governana

deve ajudar na adoo dos princpios SOA, defendendo-os dentro da organizao e
impondo seus padres.

c) Gerenciamento do portflio de servios

O consenso deve ser atingido junto com os representantes de negcio sobre

quais servios devero ser desenvolvidos. O arquiteto deve mostrar argumentos tcnicos
35

contra argumentos de negcio em se desenvolver servios especficos. Ao se envolver

no gerenciamento do portflio de servios desde o incio, o arquiteto deve ser capaz de
apontar os servios que so candidatos reutilizao e ento encaminh-los para serem

desenvolvidos primeiro. Um roadmap de servios, listando os servios atuais e os

planejados, possivelmente o produto do gerenciamento de portflio de servios.
d) Gerenciamento do ciclo de vida de servios

Esse processo tem o objetivo de implementar, atualizar e retirar servios da

corporao. O gerenciamento do ciclo de vida no deve estar associado a projetos, mas

algo a ser conduzido pelo comit de governana SOA, que gerencia as mudanas no

ambiente SOA. Essas mudanas esto relacionadas ao conceito de reutilizao de

servios e execuo de regras de negcio por toda a empresa. No comit de governana

SOA os arquitetos devem ajudar a garantir que todos os servios estejam sendo

direcionados ao ciclo de vida de gerenciamento, para evitar a existncia de servios no

gerenciados.

e) Execuo dos princpios

Esse processo se preocupa com os princpios de design e execuo. Por

exemplo, o arquiteto precisa garantir que as pessoas estejam disponibilizando seus

servios em um repositrio, para que estes possam ser gerenciados e reutilizados. Os

arquitetos tambm precisam prestar ateno nos princpios aplicados em tempo de

design. Princpios em tempo de design so padres utilizados para o desenvolvimento
de servios, e geralmente assumem um modelo de melhores prticas. Ao contrrio dos

princpios em tempo de execuo, os princpios em tempo de design geralmente no

podem ser monitorados automaticamente. Portanto, desenvolvedores precisam estar

convencidos de que eles devem aderir aos padres. Arquitetos devem rever a entrega
dos novos servios para a corporao, e nesse momento, a verificao da correta adoo
das definies uma importante atividade a ser cumprida.
f) Gerenciamento do Nvel de Servios

Se comparado a outras aplicaes, SOA requer um gerenciamento diferente de

outras arquiteturas de TI, devido a granularidade dos seus servios. A flexibilidade em

relao ao consumo dos servios requer um bom entendimento de seu nvel de

granularidade por parte de seus consumidores. Gerenciamento de servios uma

atividade do administrador do sistema, porm os arquitetos devem prestar ateno em

36

sua granularidade a fim de argumentar com a equipe de negcio quando um

determinado nvel ainda til para os usurios do negcio. Geralmente, ao revisar a
utilizao dos servios (possivelmente com uma ferramenta de registry), as
possibilidades de reutilizao podem aparecer.

37

Captulo 4
Proposta de Soluo
Em 2014 o Centro de Anlises de Sistemas Navais (CASNAV) deu incio a

projeto de Interoperabilidade de Comando e Controle (InterC2) para o Ministrio da

Defesa do Brasil (MD), cujo o objetivo prover a interoperabilidade entre os sistemas

de C2 das foras armadas e o Sistema de Planejamento Operacional Militar (SIPLOM),

sistema de C2 do MD [41].

A primeira etapa realizada no projeto foi a anlise e o mapeamento do processo

de C2 nas Operaes Conjuntas (OpCj), envolvendo as trs etapas do Processo de

Planejamento Conjunto (PPC) - Exame de Situao; Elaborao de Planos e Ordens e

Controle da Operao Planejada (COP) - como parte dos estudos necessrios

implementao do barramento de comunicao SOA, alvo do projeto InterC2.

A partir dos processos levantados usando a tcnica Business Process

Management (BPM) e, com foco na etapa do COP, ficaram estabelecidas as etapas do

projeto para levantar os requisitos, realizar a modelagem e construir uma primeira

verso do Barramento de Comunicao, que demonstrou a possibilidade de estabelecer

um servio de troca de dados com o Sistema Naval de Comando e Controle (SISNC2).

A escolha do SISNC2 foi baseada na proximidade das equipes de

desenvolvimento, ambas no Rio de Janeiro, e na diferena de tecnologia. O SISNC2,

desenvolvido em DELPHI, foi capaz de se conectar ao Barramento, construdo com

tecnologia Java. Essa caracterstica de distintas tecnologias se conectarem aumenta a

possibilidade de conexo futura com os sistemas de C2 do Exrcito Brasileiro (EB) e da

Fora Area Brasileira (FAB), mesmo que sejam construdos com tecnologia distinta,
ratificando a correta escolha de SOA para o Barramento. A Figura 4.1 apresenta o
diagrama esquemtico da interoperabilidade visualizada entre os diversos sistemas de
C2.

38

Figura 4.1 Interoperabilidade entre sistemas de C2

No ano de 2015 foram realizados os testes de cadastramento e a troca de dados

de posio dos meios, fatores fixos e feies de controle, empregados em uma operao

conjunta, bem como a atualizao da hostilidade e da situao operacional dos meios e

instalaes.

O Barramento de Comunicao com tecnologia SOA um sistema intermedirio

(middleware) baseado no JC3IEDM que permite a troca de dados automtica entre

sistemas por meio de mensagens ADEM. O seu funcionamento eficaz depende da

construo de interfaces em cada um desses sistemas, para que eles se comuniquem com
o Barramento, enviando e recebendo informaes dos servios disponibilizados.

O sucesso do projeto dar continuidade ao processo de interligao e

interoperabilidade entre os centros de C2 que compem o Sistema Militar de Comando

e Controle (SISMC2), conforme consta na Poltica do SISMC2 [4].

Nas Operaes Conjuntas (OpCj) j ocorre a integrao das etapas de

Elaborao de Planos e Ordens e do COP na prtica. Essa integrao precisa ser

acompanhada pela interoperabilidade entre os sistemas de C2 das FS e o SIPLOM.

Finalmente, a construo do Barramento de Comunicao contribui para o

atendimento de uma das capacidades desejadas para as Foras Armadas, constante na

Estratgia Nacional de Defesa [3], que possui como uma de suas diretrizes a
Interoperabilidade nas OpCj.

39

4.1 Arquitetura do Barramento

De modo a garantir a interoperabilidade presente e futura, a arquitetura do

INTERC2 segue padres de entidades com autoridade normativa. Dentre esses,

podemos destacar:

MIP: JC3IEDM e ADEM; e

W3C e OASIS: XML, XSD, WSDL.

A tecnologia na qual est baseada a implementao da camada central da

arquitetura do Barramento Java. As principais justificativas para essa escolha so a sua

maturidade, portabilidade, ausncia de custo de licenciamento (baixo custo de

aquisio) e disponibilidade de mltiplos fornecedores.

O modelo de operao do software do Barramento, eminentemente baseado em

intercmbio de informao por meio de troca de mensagens, determina a sua forma de

organizao. Essa organizao favorece ao padro arquitetural de um processamento em

estgios encadeados [31]. Mensagens so recebidas pelo sistema, verificadas,

processadas e encaminhadas ao destinatrio. Essa forma de organizao condiz com a

Arquitetura Orientada a Servios.

O fundamento da SOA o desacoplamento entre as partes que se comunicam,

permitindo flexibilidade para adaptao a novos requisitos ou integrao a novos

sistemas [32]. Essa modalidade de arquitetura o alicerce do Barramento.

De modo a no incorrer em custo de implementao da infraestrutura, o projeto

INTERC2 adotou um Barramento de Servios Corporativo (Enterprise Service Bus

ESB) com base em SOA. A equipe do projeto INTERC2 realizou uma anlise
comparativa entre seis produtos ESB de software livre e decidiu empregar o Apache
ServiceMix [33]. O ServiceMix formado, principalmente, por quatro projetos Apache:

Karaf a plataforma OSGi [9], ActiveMQ os componentes de mensageria, CXF os

componentes WS-*, e Camel Domain Specific Language (DSL) e componentes de
integrao.

Esses mdulos realizam as funes de comunicao webservices, filas para

mensagens, acesso e transformao de dados. O padro OSGi, facilita a implementao

de componentes versionados com interfaces bem definidas e dependncias explcitas. A

possibilidade de coexistncia de componentes em verses distintas torna possvel tanto
a evoluo dos componentes quanto das interfaces de servios.

Os artefatos finais, especficos ao mbito do Barramento, constituem

componentes OSGi. A configurao e integrao destes componentes ocorre por meio

40

de blueprints XML que fazem referncia a webservices, filas e componentes de

persistncia. Os componentes favoreceram o emprego da linguagem DSL Apache

Camel para sua implementao. As vantagens do uso da DSL so clareza e facilidade

para implementao das regras de C2. Os casos de maior complexidade foram
codificados em Java.

O diagrama de arquitetura da Figura 4.2 apresenta uma viso funcional em

mdulos com os ativos de software utilizados.

Os webservices do Barramento, baseados no ADEM, so descritos em WSDL e

empregam a API Java JAX-WS para servios. H servios de solicitao e resposta que
podem ser tratados em portas distintas. Os webservices empregam nas mensagens

objetos ADEM normatizados, com algumas extenses especficas aos sistemas de C2 do

MD.

Figura 4.2- Diagrama de Arquitetura e Ativos de Software

Todas as mensagens do Barramento so mapeadas e persistidas em um banco de

dados baseado no JC3IEDM. O JC3IEDM inteiramente relacional, motivo pelo qual

emprega-se um SGBD relacional para sua implementao. O SGBD escolhido foi o

PostgreSQL [35].

41

O SO utilizado o CentOS [36], uma distribuio estvel e livre do Linux para

projetos corporativos.

De modo a garantir o baixo acoplamento entre os mdulos, a tolerncia a falhas

e o processamento estvel durante um perodo de intercmbio intenso, o Barramento

emprega filas de mensagens persistentes do tipo Java Message Service (JMS) [37]. O
JMS uma interface de programao de aplicaes (API) na plataforma Java Enterprise
Edition (Java EE), para middleware orientado mensagens. Por meio da API JMS, duas
ou mais aplicaes podem se comunicar por mensagens.

O fator de segurana para a arquitetura est presente em todas as camadas,

havendo destaque para o aspecto de comunicao do Barramento. A segurana ponto a

ponto das Mquinas Virtuais (VM) realizada pelo firewall j presente no kernel do
Sistema Operacional Linux. A possibilidade de conexo ocorre apenas nos endereos de

IP conhecidos e nas portas autorizadas. Os firewalls esto baseados no Apache HTTP

Server, configurado em modalidade proxy.

A separao das funes por camadas permite que o Barramento adote a

virtualizao, onde mltiplas VM podem ser especializadas por funo. Esse arranjo

permite, se necessrio, que seja adotado clustering de servios. A verso 1.0 do

Barramento emprega uma VM para dados, uma para integrao e outra para
monitoramento.

O monitoramento dos servios e da situao operacional das outras VM est

centrado no Zabbix [38]. O Zabbix o software para aplicaes corporativas, projetado

para o monitoramento em tempo real de mtricas coletadas a partir de servidores,
mquinas virtuais e dispositivos de rede, sendo de licena Open Source.

4.2 A Interface de Comunicao

Com o objetivo de divulgar a forma de conexo entre os sistemas foi publicada,

em maro de 2015, a interface para intercmbio de dados do Barramento de

Comunicao entre o sistema de C2 do Ministrio da Defesa e os sistemas de C2 das

Foras Singulares (FS), visando interoperabilidade, com enfoque no levantamento de

necessidades

de

informaes

operacional/estratgico.

para

tomada

de

deciso,

nos

nveis

O ADEM decompe o JC3IEDM, mantendo a sua semntica em pequenas

mensagens discretas que podem ser utilizadas individualmente ou agregadas,

permitindo a troca de um conjunto mnimo de informaes. Cada uma das mensagens

discretas completa em si e no depende de informaes previamente trocadas ou

42

fornecidas no futuro. Assim, as informaes das mensagens ADEM so atemporais e

podem ser mapeadas em entidades JC3IEDM.

Como exemplo, uma mensagem que tramita informao sobre uma Unidade

(Unit), inclui informao sobre as seguintes entidades JC3IEDM:

UNIT

UNIT-TYPE
LOCATION

ORGANISATION-STATUS

OBJECT-ITEM-HOSTILITY
OBJECT-ITEM

OBJECT-TYPE

AFFILIATION-GEOPOLITICAL
REPORTING-DATA

REPORTING-DATA-ABSOLUTE-TIMING
SECURITY-CLASSIFICATION

O subconjunto de mensagens ADEM escolhido para a atual verso do

Barramento de Comunicao permite ao SIPLOM receber informaes dos sistemas de

C2 das FS sobre a Unidade e seu tipo (UNIT e UNIT-TYPE), a localizao

(LOCATION), hostilidade (OBJECT-ITEM-HOSTILITY) e a situao operacional

(ORGANISATION-STATUS) dos objetos de interesse empregados nas OpCj.

As mensagens transmitidas pelos sistemas de C2 das FS e recebidas pelo

barramento adotam os esquemas XML (XSD) padronizados pelo ADEM na verso

1.0.2. Esses esquemas representam o modelo segundo o qual as informaes devero ser

codificadas como mensagens XML. Essas mensagens sero dirigidas para os Servios
Web. Os esquemas XML so disponibilizados como arquivos individuais.

Mensagens vlidas so registradas no arquivo de Log, as informaes

necessrias so armazenadas no Banco de Dados do Barramento e retransmitidas para o

SIPLOM. Mensagens invlidas geram um recibo de no conformidade que ser
devolvido para o sistema de C2 de cada FS.

Como j mencionado, o ADEM utiliza a semntica do JC3IEDM, porm, devido

a sua natureza informacional, cujo objetivo o intercmbio da situao corrente, alguns

tipos de objetos definidos pelo JC3IEDM no so contemplados pela especificao do

ADEM. Como a possibilidade de extenses prevista na especificao do ADEM, esse

recurso utilizado, garantindo, assim, a troca de informaes adaptada realidade
brasileira.

43

A comunicao entre o Barramento e os sistemas de C2 padronizada por

contratos de servios baseados em documentos no formato WSDL. Os WSDL

empregados pelo Barramento esto baseados no mtodo ADEM, do mesmo modo que
os esquemas XML das mensagens. Os documentos WSDL so disponibilizados

individualmente para cada uma das Foras e para os sistemas de C2 do MD. A

modalidade de conversao empregada a Request/Response.
FS:

H quatro endpoints (pontos de entrada para um servio), especficos para cada

a) O Endpoint de Operaes, onde o sistema de C2 do MD informa sobre as

Operaes Conjuntas e os sistemas de C2 Foras informam sobre as Operaes

Singulares;

b) O Endpoint de Objetos de Interesse, onde realizado o registro para

identificao e uso

posterior do objeto;

c) O Endpoint de Associao, onde realizada a adjudicao do Objeto de

Interesse Operao; e

d) O Endpoint de Atualizao, onde realizada a atualizao dos Objetos de

Interesse.

O sistema de C2 de cada FS possui o mesmo conjunto de servios, porm

apresentado em um nmero de IP e uma Porta, distintos, por questes de Segurana da

Informao.

A figura 4.3 apresenta o Barramento em execuo, mostrando uma tela com

informaes de uma mensagem na fila JMS.

Destaca-se no cabealho, logo na primeira linha, a origem da mensagem (source

= MB), indicando que foi gerada pelo SISNC2 e, logo na linha seguinte, o servidor
hospedeiro da fila JMS (localhost). Ainda no cabealho, na quarta linha, pode-se ler o
tipo do meio como navio de superfcie (SurfaceVessel).

Mais abaixo, no corpo da mensagem, l-se a entidade ReportingDatetime,

indicando o data-hora. A seguir, vrias tag iniciando com <jc3:, mostrando o nome do
meio (Fragata Constituio), a hostilidade (amigo FR), e o estado operacional do meio

(operacional OPR). Em seguida aparece o indicativo de casco (F42) e, logo abaixo, a

nacionalidade BRA, indicando ser um meio do Brasil.

44

Figura 4.3- Mensagem de Registro de Objeto de Interesse

Na figura 4.4 apresenta-se o diagrama de sequncia para a troca de mensagens

em uma OpCj. Inicialmente o Barramento informa o perodo da Operao para os

sistemas de C2 das FS. A partir desse momento as FS iniciam o cadastramento dos
meios (Objetos de Interesse) que sero empregados (adjudicados) na Operao Militar.

Ao incio da OpCj esses meios passam a ser acompanhados e podem ser realizadas

atualizaes nos seus atributos, particularmente, na posio geogrfica do objeto que

passa a ser chamado de Acompanhamento.

Figura 4.4 - Diagrama de Sequncia OpCj

45

4.3 Processos iniciais

O processo apresentado na Figura 4.5 representa os passos iniciais para a

operacionalizao da interoperabilidade atravs do barramento. Esta figura est dividida

em trs camadas, onde: a camada superior identifica o SIPLOM, que o sistema de C2

do MD. A camada intermediria identifica o barramento e os servios que sero

utilizados no incio da operao. A ltima camada, mais abaixo, representa os sistemas

de C2 das Foras.

Figura 4.5 Processos iniciais do barramento

Os processos envolvidos no incio da operao tambm so apresentados na

Figura 4.5, so eles: 1.1 Cadastrar Operao Conjunta, 1.2 Cadastrar Objeto de Interesse
e 1.3 Adjudicar Objeto a Operao.

4.3.1 - Processo 1.1 Cadastrar Operao Conjunta

Como passo inicial para a operao, realizado o registro da operao conjunta

no barramento, a partir do SIPLOM. Neste momento os sistemas de C2 das Foras sero

notificados do incio da Operao Conjunta, podendo, ento, iniciar a troca de dados.
46

O servio Operao Conjunta, ilustrado na camada intermediaria da Figura 4.5,

indica que os dados da Operao Conjunta sero registrados na entidade ActionTask, do

banco de dados JC3IEDM ligado ao barramento.

Na Figura 4.6 apresentada a mensagem enviada ao barramento para o registro

da Operao Conjunta. Essa mensagem um arquivo XML que respeita a especificao

do ADEM. Podem-se destacar algumas informaes mais relevantes:

O identificador da Operao Conjunta, representado pelo atributo uri,

que

tem

como

a0dcc3d06f01, e

contedo

urn:uuid:02b04074-a60b-47c2-91ac-

O nome da Operao Conjunta, representado pelo atributo NameTxt, que

tem o contedo INCURSEX 2006.

Figura 4.6 XML para cadastro da operao

4.3.2 - Processo 1.2 Cadastrar Objeto de Interesse

As Foras registram, no barramento, seus meios ou Objetos de Interesse, que

podero ser integrados a operao em algum momento da linha do tempo da mesma.

Assim, ao receber a notificao do Objeto de Interesse, o SIPLOM toma conhecimento

dos meios disponveis e o MD poder realizar o planejamento da operao juntamente

com as Foras.

O servio Objeto de Interesse, ilustrado na camada intermediaria da Figura 4.5,

indica que os dados do objeto de interesse, dependendo de seu tipo, sero registrados
47

em uma das entidades Facilities, ControlFeatures, Material ou Unit, do banco de

dados JC3IEDM ligado ao barramento.

Na Figura 4.7 apresentada a mensagem enviada ao barramento para o registro

do Objeto de Interesse. Essa mensagem um arquivo XML que respeita a especificao

do ADEM. Podem-se destacar algumas informaes mais relevantes:

O identificador do meio, representado pelo atributo uri, que tem como

contedo urn:uuid:02b04074-a60b-47c2-91ac-a0dcc3d06f03;

O nome do meio, representado pelo atributo NameTxt, que tem como

contedo NDD CEARA, e

A sigla do meio, representado pelo atributo HullNoTxt, que tem como

contedo G30.

Figura 4.7 XML de cadastro de objeto de interesse

Cabe ressaltar que nesse exemplo utilizado um navio, porm, o mesmo tipo de

mensagem poder ser utilizado para registrar unidades de combate, edificaes, carros

de combate, aeronaves ou outro objeto que possa vir a ser acompanhado em uma
operao.

48

4.3.3 - Processo 1.3 Adjudicar Objeto a Operao

Neste processo, o meio efetivamente adjudicado (empregado) a operao,

conforme o planejamento realizado. A partir deste momento, o meio empregado

operao passa a ser identificado como Acompanhamento.

O servio Acompanhamento, ilustrado na camada intermediaria da Figura 4.5,

indica que o relacionamento entre o Objeto de Interesse e a Operao Conjunta, ser

registrado na entidade ActionResource,
barramento.

do banco de dados JC3IEDM ligado ao

Na Figura 4.8, apresentada a mensagem enviada ao barramento para o registro

da adjudicao do Objeto de Interesse Operao Conjunta. Essa mensagem um

arquivo XML que respeita a especificao do ADEM. Destacam-se nessa mensagem
que a identificao da operao, urn:uuid:02b04074-a60b-47c2-91ac-a0dcc3d06f01, e
a

identificao

do

Objeto

de

Interesse,

a0dcc3d06f03, estabelecendo o vinculo entre eles.

urn:uuid:02b04074-a60b-47c2-91ac-

Figura 4.8 XML de adjudicao de objeto de interesse a operao

4.4 Processos de acompanhamento

Aps a execuo dos processos iniciais que registram a Operao Conjunta no

barramento, notificando os sistemas participantes, e que registram os meios que

49

participam da operao, inicia-se a troca de mensagens entre os atores (SIPLOM e

sistemas de C2 das Foras). Os processos apresentados na Figura 4.9 representam esse

fluxo de troca de mensagens durante o decorrer da operao.

Figura 4.9 Processo de troca de mensagens durante a operao

4.4.1 - Processo 2.1 Registrar Localizao

Neste processo, os sistemas de C2 das Foras mantm a localizao dos

Acompanhamentos atualizada atravs do envio de uma mensagem no formato XML ao

SIPLOM. A Figura 4.10 exemplifica a mensagem enviada.

O servio Localizao, ilustrado na camada intermediaria da Figura 4.9, indica

que a localizao do Acompanhamento ser registrada no banco de dados JC3IEDM,

ligado ao barramento, e apresenta as principais entidades envolvidas na transao.

Os dados a serem destacados nesta mensagem so os contidos nos atributos

LatCoord e LongCoord, que representam localizao geogrfica em termos de latitude e

longitude, respectivamente.

50

Outro atributo importante o Hostility, que define a hostilidade do

acompanhamento. Por imposio da especificao do ADEM, todas as mensagens

enviadas devem conter esse atributo.

Figura 4.10 XML de registro de localizao

4.4.2 - Processo 2.2 Registrar Situao Operacional

Neste processo, os sistemas de C2 das Foras mantm a situao operacional dos

Acompanhamentos atualizada atravs do envio de uma mensagem no formato XML ao

SIPLOM. A Figura 4.11 exemplifica a mensagem enviada.

O servio Hostilidade, ilustrado na camada intermediaria da Figura 4.9, indica

que a hostilidade do Acompanhamento ser registrada no banco de dados JC3IEDM,

ligado ao barramento, e apresenta as principais entidades envolvidas na transao.

O dado a ser destacado nesta mensagem o contido no atributo OperaStatCode,

que define se um Acompanhamento est operacional, parcialmente operacional ou no

operacional.

51

Figura 4.11 XML de registro de situao operacional

4.4.3 - Processo 2.3 Registrar Hostilidade

Neste processo, os sistemas de C2 das Foras mantm a hostilidade dos

Acompanhamentos atualizada, atravs do envio de uma mensagem no formato XML ao

SIPLOM. A Figura 4.12 exemplifica a mensagem enviada.

O servio Situao Operacional, ilustrado na camada intermediaria da Figura

4.9, indica que a situao operacional do Acompanhamento ser registrada no banco de

dados JC3IEDM, ligado ao barramento, e apresenta as principais entidades envolvidas
na transao.

Como j mencionado, por imposio da especificao do ADEM, todas as

mensagens enviadas devem conter a hostilidade. Entretanto, prev-se uma mensagem

especfica para a hostilidade, j que a possibilidade de apenas essa informao do
Acompanhamento ser alterada existe.
O atributo importante

Acompanhamento.

o Hostility, que define a hostilidade do

52

Figura 4.12 XML de registro de hostilidade

53

Captulo 5
Concluso
5.1 Concluso
A dificuldade de integrao de dados entre sistemas informatizados de Comando

e Controle (C2) um problema atual, que afeta o setor militar de muitas naes,

incluindo o Brasil. Neste estudo foi apresentado o conceito de Comando e Controle e

interoperabilidade, que uma das chaves para a soluo dos problemas de integrao

entre os sistemas informatizados de C2. Tambm foi apresentado o JC3IEDM, o

principal modelo de dados para interoperabilidade e de mtodos de intercmbios de

dados (ADEM, JBML e C-BML) e frameworks (SitaWare e Wise-BML) para
implementao da interoperabilidade.

O projeto INTERC2 est realizando a construo do Barramento de

Comunicao para o estabelecimento de servios de troca de dados entre os sistemas de

C2 das FS e o SIPLOM. O barramento contribui para ampliar a obteno de uma
conscincia situacional compartilhada intra Comando Operacional em uma Operao
Conjunta.

Como projeto-piloto foi escolhido o Sistema Naval de Comando e Controle

(SISNC2), alm da construo de simuladores que emulavam os sistemas do EB e da

FAB, para a realizao dos testes de exequibilidade. O sucesso dos testes realizados,

obtido com a transmisso das mensagens ponta a ponta, demonstra a possibilidade de

integrao com os sistemas do EB e da FAB.

5.2 Trabalhos futuros

Mediante as tecnologias estudadas no captulo 3 e a soluo apresentada no

captulo 4, nota-se certa limitao no tocante ao mtodo de troca de dados adotado, o

ADEM, pois este foca na tramitao de informaes correntes. Como no estgio atual
54

do projeto esta sendo contemplada apenas a troca das informaes atuais de localizao,

situao operacional e hostilidade dos meios utilizados nas operaes, o ADEM

suficiente, porm, mais adiante, quando a necessidade de informao crescer, incluindo

dados de planejamento e de logstica, talvez uma soluo que contemple a adoo da
BML seja mais adequada.

Uma soluo que utilize a BML possibilita a tramitao de uma gama muito

maior de informaes sem a necessidade de extenses, o que ocorre com o ADEM.

Finalmente, duas sugestes so apresentadas: a primeira um aprofundamento

no estudo da BML para uma possvel adoo pela soluo, de forma integral ou

complementar ao ADEM. A segunda uma anlise de como o conhecimento adquirido

pode ser aplicado visando a integrao de agncias governamentais a nvel de segurana
pblica, defesa civil e servios de sade pblica.

55

Bibliografia
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]

MINISTRIO DA DEFESA, Doutrina de Operaes Conjuntas Volume 1, 1

ed, Braslia, Brasil, 2011
MINISTRIO DA DEFESA, Doutrina para o Sistema Militar de Comando e
Controle, 3 ed, Braslia, Brasil, 2015,
http://www.defesa.gov.br/arquivos/legislacao/emcfa/publicacoes/comando_contr
ole/md31_m_03_dout_sismc_3_ed_2015.pdf (Acesso em 27/05/2015)
MINISTRIO DA DEFESA, Estratgia Nacional de Defesa. Ministrio da
Defesa, 2 ed, Braslia, Brasil, 2008,
http://www.defesa.gov.br/projetosweb/estrategia/arquivos/estrategia_defesa_nac
ional_portugues.pdf (Acesso em 27/05/2015)
MINISTRIO DA DEFESA, Poltica para o Sistema Militar de Comando e
Controle. Ministrio da Defesa, 3 ed, Braslia, Brasil, 2015,
http://www.defesa.gov.br/arquivos/File/doutrinamilitar/listadepublicacoesEMD/
MD31_p01_pol_sismc2_2ed_2015.pdf (Acesso em 27/05/2015)
ERL, Thomas, "SOA: Princpios de Desing de Servios", Pearson Prentice Hall,
So Paulo, 2009
https://arquiteturagoverno.wikispaces.com/BPM, em 27/06/2014
ALBERTS ,David S., HAYES, Richard E. , Understanding Command and
Control, The Command & Control Research Program, U.S. Department of
Defense, USA, 2006
LAM, Wing, SHAKARARAMAN, Venky , An Enterprise Integration
Methodology, IT
Professional Magazine - Mar. / Apr. 2004, IEEE Compute r Societ pp. 40-48,
USA, 2004.
GUERRA DE COMANDO E CONTROLE,
http://sistemasdearmas.com.br/ggn/ggn02c4i.html, 2009 (Acesso em
06/11/2014)
MULTILATERAL INTEROPERABILITY PROGRAMME (MIP), "The Joint
C3 Information Exchange Data Model - JC3IEDM Main", 3.1.4 ed, Germany,
2012
MULTILATERAL INTEROPERABILITY PROGRAMME (MIP), The Joint
C3 Information Exchange Data Model - JC3IEDM Overview, 3.1.4 ed,
Germany, 2012
MULTILATERAL INTEROPERABILITY PROGRAMME (MIP), MIP
Technical Interface Design Plan - ANNEX B: MIP DEM SPECIFICATION,
3.1.2 ed, Germany, 2012
MULTILATERAL INTEROPERABILITY PROGRAMME (MIP), Alternate
Development and Exchange Method - Main Document,1.0.4 ed, Germany,
2015
MULTILATERAL INTEROPERABILITY PROGRAMME (MIP), Alternate
Development and Exchange Method - CONCEPT OF OPERATIONS,1.0.1 ed,
Germany, 2014
LARSEN, Peter Gorm, Coalition C2 Interoperability Challenges, 11th
International Command and Control Research and Technology Symposium,
Cambridge, Inglaterra, 2006,
http://www.dodccrp.org/events/11th_ICCRTS/html/papers/124.pdf (Acesso em
10/10/2015)

56

[16] GOVERNO BRASILEIRO, e-PING Padres de Interoperabilidade de Governo

Eletrnico Verso 2014, Comit Executivo de Governo Eletrnico, Braslia,
Brasil, 2013
[17] BATTLE MANAGEMENT LANGUAGE , C4I Center, George Mason
University, http://c4i.gmu.edu/BML/BML.php (Acesso em 13/11/2015)
[18] INTEROPERABILITY FOR THE FUTURE, Battle Space News,
http://www.battle-technology.com/exhibitions.asp?key=399 (Acesso
04/08/2015)
[19] BATTLE MANAGEMENT LANGUAGE , C4I Center, George Mason
University, http://c4i.gmu.edu/BML/BML.php (Acesso em 13/11/2015)
[20] OVERVIEW OF WISE-SBML SERVER, C4I Center, George Mason
University, http://c4i.gmu.edu/BML/WISE-BML.php (Acesso em 13/11/2015)
[21] PULLEN, J. Mark a al, Linked Heterogeneous BML Servers in NATO MSG085, IEEE Fall Simulation Interoperability Workshop, Orlando, USA, 2013,
http://netlab.gmu.edu/pubs/ (Acesso em 20/10/2015)
[22] PULLEN, J. Mark a al, Joint Battle Management Language (JBML) -US
Contribution to the C-BML PDG and NATO MSG-048 TA, Euro Simulation
Interoperability Workshop, 2007, http://netlab.gmu.edu/pubs/ (Acesso em
20/10/2015)
[23] INTEGRATED BATTLE MANAGEMENT LANGUAGE (IBML)
ARCHITECTURE - IBML Reference Architecture V2.0,
http://c4i.gmu.edu/pdfs/BML_Arch/BML%20Reference%20Arch%20SpecJan2010.pdf (Acesso em 20/10/2015)
[24] COALITION BATTLE MANAGEMENT LANGUAGE (C-BML) - MSG-048,
NATO Science and Technology Organization, NATO (OTAN), 2012, diponvel
em https://www.cso.nato.int/pubs/rdp.asp?RDP=RTO-TR-MSG-048 (Acesso em
13/11/2015)
[25] ERL, Thomas, SOA Design Patterns, 1 ed, Prentice Hall Service-Oriented
Computing Series, 2009.
[26] DIAS JR.,Jorge, Arquitetura Orientada a Servios: Sobre o que voc precisa
refletir para adot-la em um contexto empresarial , Engenharia de Software
Magazine, 22 ed, pp. 30-35, disponvel em
http://www.garcia.pro.br/EngenhariadeSW/artigos%20engsw/art%208%20%20Revista%20Engenharia%20de%20Software%20-%20edicao%2022%20%20SOA.pdf (Acesso em 14/07/2015)
[27] PRINCPIOS PARA O DESIGN EFICIENTE DE SERVIOS,
http://elemarjr.net/2011/09/02/princpios-para-o-design-eficiente-de-servios/
(Acesso em 27/10/2015)
[28] SANTOS, Rildo, SOA - Fundamentos, http://pt.slideshare.net/Ridlo/soafundamentos?qid=01fceddb-1b0c-4848-83d642b773be4574&v=default&b=&from_search=1 (Acesso em 27/10/2015)
[29] GARCIA, C. M.; ABILIO, R.; MALHEIROS, N., Abordagens e Tecnologias
para Integrao de Sistemas: Um Estudo de Caso na Universidade Federal de
Lavras, Revista de Sistemas de Informao da FSMA n. 15 (2015), pp. 11-22,
Faculdade Salesiana Maria Auxiliadora, 2015
[30] SCHEPERS, Tom, KRATZ, Benedikt ,Maturidade em Governana SOA: A
Viso de um Arquiteto, InfoQ Brasil, http://www.infoq.com/br/articles/soagov-architect-s-view (Acesso em 28/10/2015)
[31] FOWLER, Martin et al, Patterns of Enterprise Application Architecture, 1 ed,
Addison Wesley, 2002.
[32] SWEENEY, Rick, Achieving Service-Oriented Architecture, 1 ed, Wiley,
2010.
57

[33] APACHE SERVICEMIX, http://servicemix.apache.org (Acesso em 03/06/2015)

[34] OSGi, http://www.osgi.org/Main/HomePage (Acesso em 03/06/2015)
[35] POSTGRESQL, http://www.postgresql.org (Acesso em 08/06/2015)
[36] CentOS, https://www.centos.org/ (Acesso em 08/06/2015)

[37] THE JMS PROGRAMMING MODEL,

http://docs.oracle.com/javaee/6/tutorial/doc/bnceh.html (Acesso em 16/06/2015)
[38] Zabbix, http://www.zabbix.com/ (Acesso em 08/06/2015)

[39] SOMMERVILLE, Ian, Engenharia de Software , 9 ed, So Paulo, Pearson,

2011.
[41] BOTELHO,Toms de A. T., S,Manoel Pedro, CALVELLI,Jorge Eduardo,
LARA,Patrick B. A., "Interoperabilidade de Comando e Controle: Barramento
de Comunicao SOA", XVII Simpsio de Aplicaes Operacionais em reas de
Defesa XVII SIGE, Instituto Tecnolgico de Aeronutica, So Jos dos
Campos, SP, Brasil, 2015
[42] O CICLO OODA, https://rodrigolj.wordpress.com/category/estrategia/johnboyd/ (Acesso em 23/11/2015)
[43] IDEF1X - DATA MODELING METHOD, http://www.idef.com/idef1x.htm
(Acesso em 23/11/2015)

58