A arquitetura funcional do UCS necessária para suportar a interoperabilidade em UASs é a que se ilustra na figura 17.
45
Esta arquitetura estabelece os seguintes elementos funcionais e interfaces: CUCS; DLI; CCI; VSM; CCISM; HCI.
1.2.5.1 VSM
A função do VSM é a de providenciar os protocolos de comunicação, temporização de interface e formatos de dados que cada veículo aéreo requere. Uma das principais funções do VSM é a de fornecer qualquer tipo de tradução necessária dos protocolos e formatos de mensagens do DLI para os requisitos do veículo. Caso as ligações de dados utilizados no UAS não sejam compatíveis com o STANAG 7085 (como uma ligação com pouco largura de banda que serve comunicações BLOS, e. g. comunicações satélite), o CDT associado à ligação de dados incompatível tem de ser fornecido e ligado com o UCS via a função DLI do VSM. A gestão de interfaces requerida necessária para controlar e monitorizar as ligações de dados ou a capacidade de receber e processar as mensagens de estado e comando do DLI deverão ser incorporadas no CDT. Funções VSM selecionadas, e. g. tradução de dados apresentados na forma de representação do CUCS (mensagens definidas pelo DLI) para as representações especificas do veiculo e vice-versa, podem ser incorporadas no veículo e/ou na superfície.
Sempre que um UAV é introduzido numa frota de UAS interoperáveis, poderá ser necessária a integração e validação da nova função VSM correspondente a cada UCS. O anterior só será necessário caso o novo veículo introduzido requeira a funcionalidade VSM no segmento de superfície do veículo. Caso o UCS existente inclua um CDT compatível com o STANAG 7985 e incorpore as funções de gestão de ligação de dados definida pelo STANAG 4586, e ainda, se o novo UAV introduzido implemente diretamente mensagens DLI e inclua um VDT compatível com o STANAG 7985, então as funções VSM correspondentes não são necessárias.
A localização do VSM pode ser tanto no veículo como no UCS. Tendo em conta que o CUCS não pode conter nenhum processo em tempo real que seja necessário para suportar a operação entre a plataforma e o CDT, a implementação do VSM e a sua relação com o DLI podem ser efetuadas de 4 formas, ilustradas na figura 18.
46
A Figura 18 ilustra quatro veículos que suportam diferentes níveis de DLI como a sua linguagem nativa. No caso 1, o veículo e o CDT suportam todas as funcionalidades do VSM. No caso 2, o veículo e CDT não suportam qualquer funcionalidade do VSM e por isso requerem um VSM no seguimento que forneça essas funcionalidades. No caso 3, as funções do VSM estão alocadas no veículo. No caso 4, as funcionalidades do VSM estão distribuídas entre o veículo e os elementos terrestres do sistema.
1.2.5.2 CCISM
O CCISM fornece uma função semelhante ao VSM, isto é, o encapsulamento dos dados CCI e qualquer tradução necessária para que seja compatível/interoperável
47
com as ligações físicas de comunicação entre o UCS e os sistemas C4I. O CCISM pode estar localizado junto do UCS ou com o terminal dos sistemas C4I. A arquitetura do UCS deve prever a integração do CCISM.
1.2.5.3 Operador
O sistema de operação de um UAV deve possuir um conjunto de parâmetros padrão, com os quais o operador possa operar/monitorizar todos os veículos que possam ser designados a esse mesmo operador. Apesar de não ser necessário que diferentes UCSs compatíveis com o STANAG 4586 possuam displays idênticos, é mandatário que o CUCS esteja de acordo com os requisitos do HCI.
1.2.5.4 CUCS
O UCS central deverá fornecer ao utilizador uma interface que permita a um operador qualificado conduzir todas as fases da missão de um UAV. Deverá também suportar os requisitos do DLI, CCI e HCI. O CUCS permite uma interface gráfica com o utilizador gerada computacionalmente a alta resolução que fornece ao operador a capacidade de controlar diferentes UAVs e payloads.
Dependendo do nível de interoperabilidade apropriado e a carga útil suportada no respetivo UAS, o CUCS deve:
Fornecer a funcionalidade e capacidade de receber, processar e disseminar dados recebidos do UAV e carga útil;
Permitir o planeamento de missões;
Monitorizar e controlar a carga útil, o UAV e as ligações de dados;
Possuir uma arquitetura open software13 para que seja possível no futuro
suportar novas capacidades de UAVs e carga útil;
Fornecer ao operador do sistema as ferramentas computacionais necessárias relativamente a comunicações, planeamento, monitorização e execução da missão e receção, processamento e disseminação de dados;
13 software que tem o seu código fonte disponível para modificações ou ajustes por qualquer pessoa,
48
Possuir a capacidade de aglomerar as funções VSM e CCISM necessárias.
1.2.5.5 CCI
O conjunto de mensagens padrão relativas á interface de comando e controlo e os protocolos associados foram selecionados para serem independentes dos sistemas C4I e para evitar adicionar requisitos nesses mesmos sistemas. O UCS e respetivo utilizador C4I do UAS deverão identificar conjuntamente a funcionalidade CCISM requerida, caso necessário, para fornecer ao UCS compatibilidade com o sistema C4I específico. As redes e comunicações usadas para suportar o CCI deverão ser compatíveis com NISP (NATO Interoperability Standards and Profiles). A intenção do NISP é providenciar um quadro global para as comunicações NATO que procuram a interoperabilidade entre sistemas de comando militar, controlo e comunicações. A estratégia do NISP foi desenvolvida com o objetivo de alcançar a interoperabilidade, maximizar a exploração de COTS14 (Commercial Of-The Shelf) e ainda reduzir a proliferação de sistemas não padronizados. Todas as comunicações e sistemas de informação utilizados em âmbito NATO, no futuro, irão estar em conformidade com estes padrões.
1.2.5.6 HCI
O HCI estabelece os requisitos de exibição e input do utilizador que o CUCS deverá suportar. Estes estão categorizados em: requisitos gerais; configuração UCS; planeamento de missão; controlo do veículo aéreo; monitorização e controlo do operador; monitorização e controlo da carga útil; avisos, precauções e conselhos; gestão das comunicações.
1.2.5.7 Protocolos de Tecnologia de Informação e Comunicação do UCS
Todos os sistemas que englobem o veículo aéreo não tripulado e os sistemas C4I devem ser capazes de interoperar ao longo de uma rede encaminhada com múltiplas sub-redes, em que o UAS é visto como um elemento terminal (ou sub-rede terminal) de toda a rede. Esse mesmo facto possibilita que os componentes físicos do
49
UAS e dos sistemas C4I estejam localizados em qualquer parte da rede. A troca eletrónica de informação por parte do UCS e dos sistemas C4I deverá estar de acordo com o NISP.
O NISP vai também servir como guia e componente técnico para suportar implementações de projeto e transições para a NNEC (NATO Network Enabled Capability). O NISP é aplicável a todos os sistemas de informação computorizados (CIS – Computer Information System) NATO e sistemas de gestão de informação (MIS – Management Information System), incluindo as suas interfaces internas e externas, que produzem, utilizam e trocam informação eletronicamente.
1.2.5.8 DLI
Ao estabelecer o conjunto de mensagens DLI foram considerados todos os requisitos do sistema de controlo e a grande variedade de veículos aéreos. O DLI deverá ser então a interface entre UAV/ligação de dados e o CUCS. Fornece ainda o formato e mensagens padrão que possibilita a comunicação entre a grande variedade de veículos e os CUCSs compatíveis com o STANG 4586.
No anexo B, apêndice B1 do STANAG 4586 encontra-se a definição da estrutura genérica de mensagens para a comunicação AV/CDT/CUCS. Este conjunto de mensagens inclui mensagens de controlo e de estado dos seguintes elementos:
Veiculo Aéreo Carga Útil
Ligação de Dados Precauções e avisos
O conjunto de mensagens contém os dados do UAV que são independentes da plataforma e da carga útil, tal que a interação padrão não requer uma mudança de modo a acomodar um veículo aéreo ou carga útil particular. Como complemento, o conjunto de mensagens ainda inclui a capacidade do DLI criar displays específicos do sistema pelo HCI.
50
O DLI é constituído por dois componentes principais. O primeiro componente é um conjunto genérico de mensagens desenvolvidos para serem independentes do veículo e carga útil e ainda suportar a funcionalidade do CUCS. O segundo componente é um mecanismo para suportar a comunicação da informação específica do veículo, do AV/CDT para o CUCS, de modo a exibir remotamente essa informação.
O CUCS irá gerar e compreender as mensagens comuns do veículo e carga útil usando o DLI. É possível concluir que o desenvolvimento de um conjunto de mensagens padrão e respetivo protocolo de comunicação entre o veículo/ligação de dados e a função CUCS é a chave para estabelecer uma arquitetura do CUCS interoperável.
O método primário de transferência de informação entre estes dois componentes é a comunicação por mensagens. Essa estrutura de mensagens tem como objetivo passar informação de estado e controlo do UAV entre o CUCS e o CDT sem criar dependências entre estes dois componentes. Esta metodologia permite ao CUCS usar os dados fornecidos pelo CDT e transmiti-los para uma localização independente.
O método secundário de comunicação entre estes dois componentes prende-se com a utilização de serviços. Os serviços permitem ao CDT afetar o HCI no CUCS, processo muito semelhante como um explorador web acede a uma página web para localmente apresentar dados que residem num servidor remoto.