13o ICCRTS: C2 para Missões Complexas - ccomgex

13o ICCRTS: C2 para Missões Complexas
INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE: UMA
EXPERIÊNCIA BRASILEIRA1
Tópico 8: Arquiteturas de C2
Andersonn Kohl – Major QEM
Departamento de Ciência e Tecnologia
Exército Brasileiro (Brazilian Army)
Quartel-General do Exército, Bloco G, 3º andar
Setor Militar Urbano
Brasília-DF-Brasil
70630-901
tel: +55-61-3415-3090
[email protected]
[email protected]
[email protected]
1
O artigo original em inglês pode ser obtido em
http://www.dodccrp.org/events/13th_iccrts_2008/html/best_papers.html (Paper 119)
INTEGRAÇÃO DE SISTEMAS DE COMANDO E CONTROLE: UMA
EXPERIÊNCIA BRASILEIRA
1. Resumo
Este artigo fornece uma visão geral da experiência brasileira no que se refere à integração
e interoperabilidade entre sistemas de Comando e Controle. Abrange exemplos desde o
nível mais alto das Forças Armadas, até o nível mais baixo, tanto dentro como fora do
Exército Brasileiro. As características e as capacidades relacionadas com a integração no
nível físico e com os enlaces dentro do Exército são apresentadas para uma gama de
tecnologias que cobrem vários tipos de radiofreqüências, satélite e redes. O emprego de
arquitetura orientada a serviços para interoperabilidade entre sistemas, incluindo o
segmento civil, também é discutida, juntamente com o futuro processo de integração de
C².
Palavras-chave: Interoperabilidade, integração de sistemas, SOA.
2. Introdução
Existem duas abordagens principais para integração de sistemas de comando e controle
(C2). A primeira estabelece que todos os sistemas de C² existentes devam ser descartados
em favor do desenvolvimento de um novo sistema para atender todos os requisitos dos
diferentes usuários. Trata-se de uma abordagem de cima para baixo (top-down). Este é
um conceito muito atraente, mas leva a um sistema complexo e grande, o que é quase
utópico, devido ao custo e tempo gastos. A segunda abordagem envolve a busca de uma
solução que mantenha os sistemas de C² existentes como eles são, e se concentra na troca
de informações, levando a um Sistema de Sistemas (SdS). Esta é a abordagem de baixo
para cima (bottom-up).
Devido à política brasileira, a abordagem top-down é um objetivo de longo prazo, o que
explica porque a abordagem de bottom-up foi escolhida como uma solução para a
interoperabilidade entre os sistemas de C² existentes, como os da Marinha e da Força
Aérea, e os mais novos, como os do Ministério da Defesa, Exército e do segmento de
Defesa Civil.
Mesmo com essa abordagem, muitas tarefas de desenvolvimento ainda precisam ser
realizadas a fim de agrupar todos os diferentes sistemas em conjunto, horizontal e
verticalmente. Devido a isto, uma Arquitetura Orientada a Serviço (SOA) baseada em
Web Services foi escolhida para aqueles sistemas onde largura de banda não é uma
restrição para o intercâmbio de informações. Simultaneamente, uma abordagem diferente
está sendo adotada no desenvolvimento de soluções para o nível tático das Forças.
O restante deste artigo está organizado da seguinte forma: na seção 2 é apresentada a
solução de conectividade do Exército, baseada em produtos de prateleira (commercial-ofthe-shelf - COTS), a qual é tolerante a falhas graças ao conceito de redundância de rotas.
A seção 3 apresenta a proposta de integração combinada de sistemas no nível tático,
baseada no Módulo de Telemática, desenvolvido pelo Exército, e no protocolo Link BR2, desenvolvido pela Força Aérea. A seção 4 descreve o conceito de integração que será
adotado nos níveis estratégico e operacional e a sua conexão ao nível tático. Na seção 5, a
integração ao segmento civil é descrita. A seção 6 finaliza o artigo, apresentando a
evolução planejada, técnica e conceitualmente, para o todo o sistema.
3. Sistema de Comando e Controle do Exército Brasileiro
O projeto de C² tático atualmente em desenvolvimento no Exército Brasileiro (C² em
Combate – C²Cmb) foi iniciado em 2003. Dois segmentos principais compõem este
sistema: o software de C² e a infra-estrutura de telecomunicações.
Programa C2Cmb Software
O software C²Cmb foi desenvolvido sob a diretiva de que a sua distribuição deve ser livre
de quaisquer custos de licenciamento para sua utilização. Com isso, o resultado é que o
programa é baseado em banco de dados e em software de sistema de informações
geográficas (SIG) de código aberto, totalmente integrado à interface de usuário, a qual
pode ser executada tanto em plataformas Windows quanto Linux (Figura 1).
1
Figura 1 - Tela do Programa C2Cmb
O software é totalmente desenvolvido pelo pessoal do Exército e está configurado para
funcionar sob forma distribuída (ou seja, sem emprego de servidores centrais), mesmo
operando sobre redes HF.
A distribuição dos dados é realizada por meio de um conjunto de protocolos denominado
RONDON1. Para troca de dados entre os nós de C², o protocolo de difusão trata as
informações dirigidas a um nó específico, a fim de que apenas os fluxos de dados
necessários trafeguem pela rede. Isto reduz o tráfego e faz com que as informações
disponíveis sejam bem segmentadas, o que minimiza o impacto no caso de um nó falhar
ou cair sob controle do inimigo.
A informação que chega a um nó é tratada por uma máquina mestra e o protocolo de
replicação garante que cada computador receba uma cópia das mesmas informações que
todos os outros computadores dentro do nó. Esta é uma parte essencial do conceito de
tolerância a falhas implementado em todo o sistema. A Figura 2 apresenta a visão
conceitual sobre como os protocolos de difusão e replicação funcionam.
Figura 2 - Conceito de sistema distribuído do C²Cmb
Infraestrutura Tática do C2Cmb
O Exército Brasileiro desenvolveu uma solução de conectividade chamada Módulo
Telemática (MT), com o objetivo de prover a distribuição de dados bem como
comunicações por voz.
O MT é o primeiro projeto de integração dentro do Exército a permitir, com sucesso, que
redes distintas e separadas, como redes rádio (HF, VHF e UHF) e redes com fio, troquem
informações de forma transparente ao usuário final.
O MT é um conjunto integrado de equipamentos de informática e de telecomunicações
que fornece comunicações por voz e de dados entre todos os elementos de combate no
terreno. Ele agrega um grande número de tecnologias disponíveis, a maior parte delas
provenientes do meio civil, permitindo, assim, que múltiplas rotas sejam escolhidas
automaticamente. A figura 3 ilustra os componentes.
Figura 3 - Módulo de Telemática do C2Cmb
Existem três tipos de MT, denominados "A", "B" e "C", os quais definem os
equipamentos e tecnologias empregadas no âmbito de cada conjunto. O MT tipo "A" é o
de mais alto nível, para utilização no nível brigada. É um sistema totalmente integrado
que emprega tecnologias como Wi-Fi, WiMAX, rádios H/V/UHF, SISCOMIS,
Globalstar, ADSL, linhas telefônicas públicas e de campanha. O tipo "B" é usado no
nível batalhão e o tipo "C" é empregado em companhias ou níveis mais baixos.
Quando os MT são conectados, eles formam uma rede física e lógica capaz de transmitir
dados, voz e imagens a partir de, ou para, quaisquer elementos de combate, bem como de,
ou para, redes externas como a Internet, telefonia pública comutada e rede celular. As
interligações do MT são feitas a fim de permitir caminhos ou rotas alternativas entre dois
pontos do sistema no terreno. Quando uma rota torna-se indisponível, o sistema
automaticamente adapta-se para encontrar outra rota operacional, a fim de alcançar o
destino necessário. As rotas alternativas utilizam tecnologias distintas, de modo que o
sistema é independente das condições de transmissão que poderiam afetar uma tecnologia
específica.
A evolução futura para o sistema prevê a incorporação de um Rádio Definido por
Software, atualmente em desenvolvimento no Brasil, que irá acrescentar capacidades
TDMA e ad-hoc ao sistema.
4. Sistema de Enlace de Dados Táticos
Para a interoperabilidade tática, a solução de implementação proposta é baseada no MT e
no protocolo da Força Aérea, ainda em desenvolvimento, chamado link BR-2 (BR-2 foi
especificado a partir link BR-1, desenvolvido para o projeto SIVAM). O link BR-1 é um
protocolo de comunicações ponto-a-ponto desenvolvido para disponibilizar informações
recolhidas pelas plataformas R99 para o segmento terrestre do SIVAM bem como para o
controle do tráfego aéreo. O link BR-2 foi desenvolvido para explorar a capacidade
TDMA dos sistemas rádio empregados pelas plataformas R99. A figura 4 ilustra a forma
como as camadas do link BR-2 estão relacionadas com o modelo de referência OSI.
Figura 4 - Relacionamento OSI e link BR2
Entre os principais objetivos está a menor dependência da camada física, o que lhe
permite ser configurável para diferentes camadas físicas ao mesmo tempo em que é
independente da aplicação e do catálogo de mensagens.
A independência da aplicação e do catálogo de mensagem reside na Interface de
Programação de Aplicação (API) entre as camadas lógica e de aplicação (L-A); a
independência da camada física reside na API entre as camadas lógica e física (L-P) e do
controlador de dispositivo (device driver) a ser desenvolvido por cada dispositivo de
comunicação que venha a ser utilizado. Isto permite que o protocolo venha a ser
empregado em diferentes meios de transmissão, como HF ou satélite.
Uma grande capacidade do protocolo BR2 é que ele permitirá que a plataforma funcione
como um gateway. A capacidade de roteamento do MT como um gateway físico
permitirá a troca de dados entre os sistemas táticos existentes dentro das Forças Armadas.
A inserção do protocolo BR2 no MT aumentará a interoperabilidade e a flexibilidade dos
sistemas. A figura 5 ilustra como.
Figura 5 - Conceito de Enlace de Dados Tático
5. Integração Operacional/Estratégica de C2
Os esforços para integração de sistemas no nível tático foram apresentados nas seções
anteriores. A abordagem adotada foi essencialmente voltada para a manutenção da
operacionalidade dos sistemas atuais ao mesmo tempo em que um "integrador" com
capacidades de gateway está sendo desenvolvido. A principal limitação para este
desenvolvimento é a necessidade de tratamento de informações em tempo quase-real (e,
em algumas situações, processamento em tempo real), que poderá trazer impacto sobre
alguns dos sistemas legados.
Uma abordagem semelhante foi adotada para integração nos níveis superiores de C²
operacional e estratégico. No entanto, não havia nenhuma exigência de processamento
em tempo real destes níveis. Existem também várias capacidades espalhadas pelos
sistemas legados que outros usuários poderiam querer explorar e o acesso a estas
precisam ser levados em consideração.
A primeira abordagem para os sistemas de interoperabilidade C² brasileiros foi o
desenvolvimento de uma solução baseada no C2IEDM (Modelo de Dados para
Intercâmbio de Informações de Comando e Controle). No entanto, embora o mecanismo
de intercâmbio de dados do Programa para Interoperabilidade Multilateral (Multilateral
Interoperability Programme – MIP-DEM) e o C2IEDM proporcionem meios necessários
para permitir, sem ambigüidades, a codificação e o intercâmbio de informações entre dois
sistemas de C², isto não garante a interoperabilidade. Assim, tentou-se fazer uma nova
abordagem baseada em Arquitetura Orientada a Serviço (SOA).
Fundamentos de SOA
Arquitetura Orientada a Serviço é um paradigma para organização e utilização de
capacidades distribuídas que podem estar sob controle de diferentes domínios. As partes
fundamentais de um paradigma SOA que norteiam a solução de infra-estrutura são as
seguintes:
1) Visibilidade, que se refere à capacidade de aqueles com necessidades e aqueles com
recursos (capacidades) poderem se ver uns aos outros, o que pode ser traduzido como
descrição de serviço, a qual precisa estar num formato no qual a sua sintaxe e a sua
semântica estejam acessíveis e sejam compreensíveis;
2) Interação, que é a atividade da utilização de uma capacidade. Ela prossegue através de
uma série de trocas de informações e de ações solicitadas, intermediada pela troca de
mensagens. O registro de um serviço em um servidor e sua capacidade de busca são as
principais tarefas de um processo de interação, seguida pela capacidade de enviar
mensagens entre o consumidor de serviços e o fornecedor de serviços;
3) Efeito, que é o resultado de uma interação. Esse efeito pode ser o retorno de
informações ou a mudança do estado de entidades (conhecidos ou desconhecidos) que
estão envolvidos na interação.
Linguagem de Descrição de Web Services (WSDL) é uma solução bastante adequada que
descreve as capacidades de Web Services como coleções de parâmetros de comunicação
capazes de trocar mensagens. Este é um bom ponto de partida para satisfazer requisitos
visibilidade.
A figura 6 mostra como a interação pode ser obtida por um registrador Universal de
Descrição, Descoberta e Integração (UDDI), um registrador de negócio mundial baseado
em registros XML (eXtended Mark-Up Language), e pela utilização de protocolo de
acesso simples a objetos (SOAP), um protocolo leve baseado em mensagens XML,
utilizado para codificar a informação em mensagens de pedido e resposta de Web service
antes de enviá-los através da rede. Mensagens SOAP são independentes de qualquer
sistema operacional ou protocolo e só podem ser transportadas através de uma variedade
de protocolos Internet.
Figura 6 - Conceito de SOA
Um consumidor de serviço pode procurar por um serviço no registrador UDDI, obter o
WSDL do serviço e solicitar o serviço utilizando SOAP.
Geralmente, as capacidades são desenvolvidas para resolver ou apoiar uma solução para
os problemas que surgem no negócio. É lógico que as necessidades de alguém poderiam
ser sanadas pelas capacidades desenvolvidas por outrem. Isso acontece o tempo todo em
todo o mundo.
Não há, necessariamente, um relacionamento de um-para-um entre necessidades e
capacidades, devido a muitas razões, mas, principalmente, porque qualquer necessidade
pode exigir a combinação de várias capacidades, enquanto que uma única capacidade
pode atender a mais de uma necessidade. O grande mérito da SOA é que ela provê uma
poderosa estrutura para acoplamento de necessidades e capacidades e para combinação
de capacidades que atendem aquelas necessidades.
Embora ambas as necessidades e capacidades possam existir independentemente, em
SOA, os serviços são o mecanismo pelo qual as necessidades e as capacidades são postas
em conjunto.
A chave para o sucesso da SOA é a independência entre a interface de serviço e a
implementação física. Desenvolvedores de aplicação ou integradores de sistema podem
construir aplicações pela composição de um ou mais serviços sem conhecimento das
implementações existentes sob os serviços.
Existem algumas perguntas que devem ser respondidas quando se decide desenvolver
uma arquitetura SOA.
A primeira questão é como obter comunicação entre sistemas que são independentes de
plataformas e uniformes? Para resolver esta questão é necessário ter um modo comum,
um contrato, para estabelecer a comunicação. Uma possível solução é o emprego de Web
Services.
Uma segunda questão é como integrar e reunir diferentes Web Services baseados em
padrões de processos de negócios? Para isso, é necessário criar aplicações compostas
cujos processos são distribuídos pelos serviços. Uma solução possível é o emprego de
uma linguagem baseada em XML chamada Linguagem de Execução de Processo de
Negócio (BPEL) que regula a execução conjunta de serviços, como em um fluxo de
trabalho (workflow), que poderia ser um processamento síncrono ou assíncrono, com ou
sem intervenção de agentes externos, tais como um usuário ou outro sistema. Sem essa
solução, a comunicação deverá ser estabelecida individualmente para cada par de
sistemas Web Services, criando uma malha infinita de dependências de sistemas.
A terceira pergunta é uma questão técnica sobre como conectar todos os participantes
SOA abstraindo-se da complexidade técnica existente em camadas mais baixas? Pode
haver uma série de diferentes tecnologias, como SOAP, CORBA, RMI e modelos de
dados, como C2IEDM ou JC3IEDM, e o ambiente SOA deverá colocar todos para
trabalhar em conjunto. A resposta para isto é Barramento de Empreendimento de Serviço
(ESB) que possui um conjunto de conectores os quais permitem a comunicação com
várias tecnologias distintas. Cada serviço exige não só fornecedores e consumidores, mas
também um canal no ESB para conectar os dois. Este canal implementa a interface de
serviço exatamente como um provedor (mas agindo como um proxy), incluindo formatos
de mensagens e respostas para os pedidos de serviços que permitem solicitação remota
(tal qual um processo inter-comunicação) do serviço.
6. O Sistema de Sistemas de C2 Brasileiro
Um conceito arquitetural de integração dos sistemas de C² foi concebido baseado nos
fatos de que sistemas de C²:
1) são executados sob linguagens e plataformas distintas ;
2) operam em redes privadas e seguras;
3) devem ter alto nível de redundância;
4) podem mover-se sem aviso prévio;
5) empregam modelos de dados distintos.
A primeira abordagem aponta claramente para uma solução web service, empregando um
repositório UDDI. No entanto essa solução se tornaria um ponto fraco dentro do sistema
porque os serviços tornam-se indisponíveis, caso o UDDI venha a falhar. A única
maneira de se tornar independente do UDDI é a padronização de serviços para todo o
sistema, de modo que aplicações clientes saibam exatamente:
1.Quais são os formatos das mensagens;
2.Quais as informações que podem ser obtidas;
3.Que serviços estão sendo oferecidos.
Mas existe ainda uma questão a ser resolvida: como pode um aplicativo cliente encontrar
um prestador de serviços dentro da rede, uma vez que o repositório UDDI não está mais
disponível? A resposta a esta questão é o uso de um servidor intermediário. O
intermediário sabe onde os serviços estão localizados e não precisa se preocupar em
prover informação WSDL, uma vez que esta foi padronizada anteriormente para todo o
sistema.
A figura 7 mostra a forma como o servidor intermediário atua como um ponto de acesso a
outros serviços de aplicação, porque ele sabe a real localização dos serviços. Ele também
compila informação do mesmo serviço fornecida por várias aplicações, retornando
apenas uma resposta para o solicitante. Ele funciona como referência a criação de uma
DMZ (zona desmilitarizada), realizando a transição das redes privadas de cada sistema
militar.
Não será necessário para as aplicações consumidoras saber onde os serviços estão porque
estas têm acesso apenas ao intermediário. Isto permite configurações de firewalls mais
fáceis porque nenhum sistema tem acesso direto às aplicações de outras Forças.
Todavia, isto nos leva de volta ao velho problema de "fraqueza": e se o servidor
intermediário falhar?
Figure 7 - Conceito do servidor intermediário
A fim de resolver esta "vulnerabilidade", uma malha de servidores intermediário foi
proposta por que:
1. o servidor intermediário não possui qualquer informação crítica;
2. a única informação que deve ser replicada pela rede é a localização dos serviços;
3. uma vez que ele não possui informação crítica, um servidor intermediário pode ser
rapidamente descartado e substituído;
4. as aplicações somente precisarão saber a localização de outro servidor da rede para
trabalhar normalmente no caso de seu servidor intermediário falhar e não puder ser
substituído.
Se um fornecedor de serviço muda a sua localização, ele deve informar esta alteração ao
seu servidor intermediário e este transmite para a rede a nova localização. Esta mesma
abordagem pode ser empregada quando um novo servidor intermediário se junta à rede.
O modelo da arquitetura lógica é apresentado na figura 8. Esta figura apresenta os
sistemas de C² do Ministério da Defesa, da Marinha, do Exército e da Força Aérea
fornecendo serviços por meio da rede de servidores intermediários.
A integração ao nível tático será realizada através da adição de um servidor intermediário
ao MT e pelo desenvolvimento de serviços web onde for possível prover os sistemas com
fornecimento de serviços de ou para o nível tático.
Figura 8 - SOA – Modelo Lógico
A figura 9 apresenta um exemplo de configuração física para esta solução SOA. O
intercâmbio de serviços no nível estratégico é realizado através da adição de servidores
intermediários localizados fora dos firewalls utilizados pelas forças singulares. Esses
servidores são parte da rede de servidores intermediários SOA.
Figura 9 - SOA - Modelo Físico
Por exemplo, suponha que uma operação seja conduzida na região amazônica. O
Comando Combinado e o comando operacional da Força Aérea estão localizados dentro
da mesma cidade (Manaus). Os comandos operacionais da Marinha e do Exército estão
localizados próximos, mas em uma cidade diferente (Eirunepê).
A solução SOA acrescentaria um servidor intermediário para cada cidade, mas fora do
firewall das forças, e seria conectado aos demais membros da rede. Então, dentro do
teatro de operações, se, por exemplo, um sistema do Exército apresentasse uma demanda
de serviço da Marinha, existem várias maneiras em que esta poderia ser atendida. A
primeira (e preferida) escolha seria solicitar diretamente ao servidor de Eirunepê que este
requisite ao sistema local da Marinha e, assim, atender à demanda. O pedido poderá
igualmente ser dirigido ao servidor no Rio de Janeiro que requisitaria ao sistema local da
Marinha, mas esta operação demoraria um pouco mais e somente seria feita se o servidor
local de Eirunepê se tornasse indisponível. Se o enlace do Ministério da Defesa (MD)
falhar, o pedido pode ser enviado através da rede do Exército para Brasília, onde é
transferido para a rede do MD para requisitar ao sistema da Marinha no Rio de Janeiro.
Este exemplo simples mostra que a arquitetura proposta permite a troca de informações
utilizando as características dos sistemas de C² acima listadas.
7. Integração com C² do segmento civil
Em 2003, foi iniciado o desenvolvimento do Sistema Integrado de C² para a Defesa Civil
no Rio de Janeiro, reunindo o Instituto Militar de Engenharia (IME), a Universidade
Estadual Rio de Janeiro (UERJ) e a Secretaria de Segurança do Estado do Rio de Janeiro.
O sistema foi concebido para operar nos níveis municipal e estadual. O principal objetivo
deste sistema é proporcionar um melhor planejamento e resposta rápida às catástrofes,
naturais ou causados pelo homem, permitindo que mais vidas pudessem ser salvas em tais
cenários.
Descrição do Sistema
O conceito do sistema foi concebido para permitir que toda informação necessária esteja
disponível para o decisor. À luz deste conceito, os dados das fontes de informação dos
diversos segmentos, como câmeras de controle de tráfego de veículos, polícias e
bombeiros, por exemplo, devem estar disponíveis em um local central, de modo que o
decisor possa avaliar diferentes opções e passar a sua decisão aos distintos executores. Os
terminais de campo do sistema são constituídos por muitos recursos técnicos que
transmitem a informação para o Centro de Gerenciamento Integrado (CGI) e receber
ordens e informação de lá. Os componentes básicos do terminal remoto são:
•
•
•
•
•
Computador de mão;
Telefone celular com Bluetooth;
Telefone satelital (Globalstar);
Câmera digital, e
Receptor GPS.
Posições atualizadas e mensagens curtas das equipes de campo são enviadas através da
rede de telefonia celular e/ou telefone por satélite. Vídeo digitalizado também pode ser
enviado através da rede celular.
O CGI é composto por:
•
•
•
•
Servidor GIS, onde as posições das equipes são armazenadas e podem ser
reproduzidas para análise;
Servidor de vídeos e imagens, que gerencia as informações visuais fornecidas
pelas câmeras digitais das equipes;
Controlador de terminais, que gerencia o estado das equipes de campo;
Manipulador de dados, onde planos de contingências, riscos, recursos e dados de
desastres são gerenciados para alimentar o decisor.
Existem duas telas de projeção que fornecem informações de situação e de imagem.
Atualmente, existem vários CGI em funcionamento e este fato fez surgir uma evolução
natural para o sistema, que é a construção de um CGI nacional, ligando todos os CGI
estaduais.
Figure 10 - Integrated Management Center (CGI)
Integração ao Sistema Militar de C2
Conforme descrito anteriormente, o CGI possui alguns servidores específicos que
desempenham um conjunto de tarefas que podem ser traduzidas em serviços. Esses
serviços podem ser publicados através do cluster de servidores intermediários descritos
na seção 4. Capacidades como transmissão de vídeo, posição e status de equipes de
campo estarão disponíveis para o sistema da Defesa, o que facilitará a coordenação com
as Forças Armadas para prestar ajuda em ao cenários de desastres.
8. A Integração de Processos de C2 no Futuro
A primeira e natural abordagem de integração entre dois sistemas é aquela em que uma
aplicação do sistema "A" acessa os dados armazenados no banco de dados do sistema
"B". Esta solução é a integração dados. Essa abordagem permite a aplicação "A" tratar os
dados de acordo com suas necessidades, mas pode ter dois grandes inconvenientes: o
primeiro é o possível aspecto invasivo de acesso aos dados no sistema "B", e o segundo é
que não há ganho para o sistema “A” da solução de processamento que poderia ser
implementada na aplicação "B".
O próximo nível de integração é que a aplicação "A" solicite alguma capacidade da
aplicação "B" no domínio de web service. Esta solução de integração de aplicações é o
nível atual de integração de sistemas C2 no âmbito das Forças Armadas brasileiras.
A próxima etapa prevista é a integração de componente de aplicação. Isso poderia ser,
por exemplo, um componente de comunicação C2Cmb solicitando a utilização de
capacidades do protocolo BR2. Este seria o nível de integração funcional.
O objetivo principal de todo este cenário evolutivo é a integração de processos, como
mostrado na figura 10. Todas as aplicações dentro de um sistema são conseqüência de um
processo (ou processos) bem definido, a participar do negócio. Um sistema bem ajustado
irá requerer a integração de processos que definirão, por exemplo, quais os serviços
deverão estar disponíveis para cada sistema, a fim de satisfazer exigências de integração.
Essa é a meta que solução SOA proposta objetiva. Uma vez que este objetivo seja
cumprido, e até mesmo durante o seu desenvolvimento, os requisitos para um novo e
totalmente comum sistema de C² estará sob especificação.
Figura 11 - A Futura Interação dos Sistemas de C2
9. Conclusão
A interoperabilidade e integração de sistemas C² claramente possuem dois grandes
domínios relacionados com o nível operacional/estratégico e com o nível tático. Este
artigo apresentou a atual integração de sistemas de C² brasileiros para os níveis
operacional/estratégico e tático. Para o nível tático, a integração planejada reside no
Módulo de Telemática e no protocolo BR2. Para o nível operacional/estratégico, uma
SOA está em desenvolvimento, a qual permitirá também a participação do nível tático,
embora com algumas limitações. Em longo prazo, o objetivo do C² é o desenvolvimento
de integração de processos como base para o futuro desenvolvimento de sistema conjunto
dentro das Forças Armadas brasileiras.
10. Referências
OASIS. (n.d.). OASIS SOA Reference Model TC. Retrieved January 5, 2008, from
OASIS: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=soa-rm
Bianco, Phil, Rick Kotermanski, and Paulo Merson. 2007. Evaluating a Service-Oriented
Architecture – Technical Report. Carnegie Mellon University.
Morris, Edwin, Linda Levine, Craig Meyers, Pat Place and Dan Plakosh. 2004. System of
Systems Interoperability (SOSI): Final Report. Carnegie Mellon University.
Dorf, Richard C. 2000. The Electrical Engineering Handbook (2nd Edition).CRC
PressLLC.
11. Glossário
C2Cmb
CGI
FAC
FNC
FTC
MT
Comando e Controle em Combate
Centro de Gerenciamento Integrado
Força Aérea Componente
Força Naval Componente
Força Terrestre Componente
Módulo de Telemática
RONDON
Replicação de Objetos Nodais e Difusão de Objetos Nodais.
SISCOMIS
Sistema Militar de Comunicações por Satélite.
SIVAM
Sistema de Vigilância da Amazônia
SOA
Arquitetura Orientada a Serviço
12. Agradecimentos
O autor agradece às seguintes pessoas pelo apoio no fornecimento e intercâmbio de
conhecimentos que permitiram que este artigo pudesse ser escrito.
Paulo César Guerreiro da Costa – FAB
Edmundo Lopes Cecílio – EB
Francisco Guirado Bernabeu – FAB
André Luiz Pimentel Uruguay – FAB
Leandro Costa de Andrade – FAB
Alexandre Alves dos Santos – EB
Eduardo Martins Guerra – FAB