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)

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

kohlbr@yahoo.com.br

c2ch@cige.eb.mil.br

gc2adj2@dct.eb.mil.br

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-of-the-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 BR-2, 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 Comando e Controle em Combate CGI Centro de Gerenciamento Integrado FAC Força Aérea Componente FNC Força Naval Componente FTC Força Terrestre Componente MT 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