BR102017003799A2 - Method and system for automatically filtering network messages in an aviation network for an aircraft. - Google Patents
Method and system for automatically filtering network messages in an aviation network for an aircraft. Download PDFInfo
- Publication number
- BR102017003799A2 BR102017003799A2 BR102017003799-1A BR102017003799A BR102017003799A2 BR 102017003799 A2 BR102017003799 A2 BR 102017003799A2 BR 102017003799 A BR102017003799 A BR 102017003799A BR 102017003799 A2 BR102017003799 A2 BR 102017003799A2
- Authority
- BR
- Brazil
- Prior art keywords
- network
- test
- network message
- message
- attributes
- Prior art date
Links
- 238000000034 method Methods 0.000 title claims abstract description 67
- 238000001914 filtration Methods 0.000 title claims abstract description 31
- 238000012544 monitoring process Methods 0.000 claims abstract description 12
- 238000012360 testing method Methods 0.000 claims description 108
- 230000006870 function Effects 0.000 claims description 34
- 238000012423 maintenance Methods 0.000 claims description 33
- 230000015654 memory Effects 0.000 claims description 15
- 238000011990 functional testing Methods 0.000 claims description 8
- 230000007246 mechanism Effects 0.000 abstract description 6
- 230000009471 action Effects 0.000 description 20
- 238000013459 approach Methods 0.000 description 20
- 238000004891 communication Methods 0.000 description 18
- 238000007726 management method Methods 0.000 description 12
- 230000008569 process Effects 0.000 description 9
- 238000013475 authorization Methods 0.000 description 8
- 230000000694 effects Effects 0.000 description 6
- 230000006855 networking Effects 0.000 description 6
- 230000002123 temporal effect Effects 0.000 description 6
- 238000012546 transfer Methods 0.000 description 6
- 238000007689 inspection Methods 0.000 description 5
- 230000001413 cellular effect Effects 0.000 description 3
- 238000010586 diagram Methods 0.000 description 3
- 238000005516 engineering process Methods 0.000 description 3
- 239000000446 fuel Substances 0.000 description 3
- 230000002452 interceptive effect Effects 0.000 description 3
- 238000007639 printing Methods 0.000 description 3
- 230000001052 transient effect Effects 0.000 description 3
- 230000002411 adverse Effects 0.000 description 2
- 230000006399 behavior Effects 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 239000000969 carrier Substances 0.000 description 2
- 230000001934 delay Effects 0.000 description 2
- 230000010006 flight Effects 0.000 description 2
- 230000010354 integration Effects 0.000 description 2
- 230000033001 locomotion Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 238000002360 preparation method Methods 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 102100026278 Cysteine sulfinic acid decarboxylase Human genes 0.000 description 1
- 230000003213 activating effect Effects 0.000 description 1
- 230000006978 adaptation Effects 0.000 description 1
- 230000003466 anti-cipated effect Effects 0.000 description 1
- 235000013361 beverage Nutrition 0.000 description 1
- 230000005540 biological transmission Effects 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 230000009194 climbing Effects 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 238000007596 consolidation process Methods 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 230000001186 cumulative effect Effects 0.000 description 1
- 230000007812 deficiency Effects 0.000 description 1
- 238000006731 degradation reaction Methods 0.000 description 1
- 230000003111 delayed effect Effects 0.000 description 1
- 238000005538 encapsulation Methods 0.000 description 1
- 239000004744 fabric Substances 0.000 description 1
- 230000036541 health Effects 0.000 description 1
- 238000010438 heat treatment Methods 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 238000011835 investigation Methods 0.000 description 1
- 235000012054 meals Nutrition 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000011112 process operation Methods 0.000 description 1
- 108010064775 protein C activator peptide Proteins 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 239000000523 sample Substances 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 238000012163 sequencing technique Methods 0.000 description 1
- 238000004088 simulation Methods 0.000 description 1
- 238000003860 storage Methods 0.000 description 1
- 239000013598 vector Substances 0.000 description 1
- XLYOFNOQVPJJNP-UHFFFAOYSA-N water Substances O XLYOFNOQVPJJNP-UHFFFAOYSA-N 0.000 description 1
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0227—Filtering policies
- H04L63/0263—Rule management
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
- H04L63/0227—Filtering policies
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G5/00—Traffic control systems for aircraft, e.g. air-traffic control [ATC]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L43/00—Arrangements for monitoring or testing data switching networks
- H04L43/02—Capturing of monitoring data
- H04L43/028—Capturing of monitoring data by filtering
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L45/00—Routing or path finding of packets in data switching networks
- H04L45/70—Routing based on monitoring results
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
- H04L63/1433—Vulnerability analysis
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/22—Parsing or analysis of headers
-
- G—PHYSICS
- G08—SIGNALLING
- G08G—TRAFFIC CONTROL SYSTEMS
- G08G5/00—Traffic control systems for aircraft, e.g. air-traffic control [ATC]
- G08G5/0004—Transmission of traffic-related information to or from an aircraft
- G08G5/0008—Transmission of traffic-related information to or from an aircraft with other aircraft
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04B—TRANSMISSION
- H04B7/00—Radio transmission systems, i.e. using radiation field
- H04B7/14—Relay systems
- H04B7/15—Active relay systems
- H04B7/185—Space-based or airborne stations; Stations for satellite systems
- H04B7/18502—Airborne stations
- H04B7/18506—Communications with or from aircraft, i.e. aeronautical mobile service
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Computing Systems (AREA)
- Environmental & Geological Engineering (AREA)
- General Business, Economics & Management (AREA)
- Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Aviation & Aerospace Engineering (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
- Mobile Radio Communication Systems (AREA)
- Computer And Data Communications (AREA)
- Traffic Control Systems (AREA)
Abstract
método e sistema para filtrar automaticamente mensagens de rede em uma rede de aviação para uma aeronave em geral, certos exemplos da presente descrição proporcionam técnicas ou mecanismos para filtrar automaticamente mensagens de rede em uma rede de aviação para uma aeronave com base em um contexto de sistema atual. de acordo com vários exemplos, é proporcionado um método compreendendo receber uma mensagem de rede transmitida a partir de um dispositivo aviônico de origem para um dispositivo aviônico de destino através de um ou mais pacotes de rede dentro da rede de aviação. um contexto do sistema atual, que indica um estado agregado de dispositivos aviônicos dentro da rede de aviação, é determinado com base no monitoramento dos dispositivos aviônicos. a mensagem de rede é analisada identificando uma pluralidade de atributos correspondentes aos campos de cabeçalho e de campos de dados de um ou mais pacotes de rede correspondentes à mensagem de rede. a aceitabilidade da mensagem de rede dentro do contexto do sistema atual é determinada com base em uma ou mais regras de filtro que especificam quais atributos são permitidos dentro de um contexto de sistema particular.
Description
“MÉTODO E SISTEMA PARA FILTRAR AUTOMATICAMENTE MENSAGENS DE REDE EM UMA REDE DE AVIAÇÃO PARA UMA AERONAVE” FUNDAMENTOS
[001] A presente descrição refere-se, de um modo geral, à cibersegurança e, mais especificamente, a métodos e sistemas para uso na identificação de ameaças de cibersegurança para plataformas e infraestruturas de aviação.
[002] A e-habilitação das plataformas e infraestruturas de aviação, a bordo e fora de bordo, resultou em sistemas físicos interconectados e infraestruturas de cadeia de abastecimento que agora são um alvo potencial para as ameaças de cibersegurança dinâmicas e crescentes devido a um maior acesso à sistemas de computação em rede. As plataformas e infraestruturas de aviação são sistemas complexos que envolvem sistemas e controladores embutidos hierarquicamente interligados em rede, com diferentes requisitos de criticidade, confiabilidade e disponibilidade operacionais. Em vários exemplos, os sistemas e controladores embutidos são cada vez mais hospedados em hardware de dispositivos de computação de propósito geral, sistemas operacionais de software comercial e aplicativos personalizados específicos que executam as funções de sistema pretendidas. Esses sistemas e controladores a bordo podem ser conectados em rede por meio de protocolos com base em padrões da Força-Tarefa de Engenharia da Internet (IETF) e Aeronautical Radio, Inc. (ARINC), tais como o Protocolo Internet (IP) e protocolos de rede e de comunicações sem fio ou com fio do Instituto de Engenheiros Elétricos e Eletrônicos (IEEE). Além disso, os sistemas a bordo podem ser conectados em rede com sistemas de computação fora de bordo através de protocolos com base em IP da IETF padrão, tais como Protocolo de datagrama do usuário (UDP) e Programa de Controle de Transmissão (TCP).
[003] O aumento do uso de protocolos de computação e de comunicação à base de padrões pode permitir uma integração perfeita da arquitetura e-Habilitada, mas também pode aumentar a vulnerabilidade a ataques de cibersegurança. Além disso, a definição atual de fluxos de dados da rede do avião não está em uma forma compreensível da máquina que requer interpretação manual para a criação de regras de filtro de rede adequadas para um uso de proteção de domínio. Isso pode levar a erros e interstícios de cobertura. Assim, existe uma necessidade de sistema e método para capacidades de filtro aumentadas que podem impedir fluxos de rede não autorizados com base em contextos de sistema em mudança em plataformas de aviação e-Habilitadas.
SUMÁRIO
[004] A seguir se apresenta um sumário simplificado da descrição de modo a proporcionar uma compreensão básica de certos exemplos da presente descrição. Este sumário não é uma visão geral extensa da descrição e não identifica elementos chave/críticos da presente descrição nem delineia o escopo da presente descrição. O seu único objetivo é apresentar alguns conceitos aqui descritos em uma forma simplificada como um prelúdio para a descrição mais detalhada que é apresentada mais tarde.
[005] Em geral, certos exemplos da presente descrição proporcionam técnicas ou mecanismos para a filtragem de conteúdo de mensagens consistente em contexto de fluxos de rede funcionais para plataformas e infraestruturas de aviação e-Habilitadas. De acordo com vários exemplos, é proporcionado um método para filtrar automaticamente mensagens de rede em uma rede de aviação para uma aeronave com base em um contexto de sistema atual. O método compreende receber uma mensagem de rede por um processador de um sistema de computador. A mensagem de rede é transmitida de um dispositivo aviônico de origem para um dispositivo aviônico de destino via um ou mais pacotes de rede dentro da rede de aviação. O método compreende ainda o estabelecimento, pelo processador, de um contexto de sistema atual com base no monitoramento de um ou mais dispositivos aviônicos dentro da rede de aviação. Em alguns exemplos, o contexto do sistema indica um estado agregado do um ou mais dispositivos aviônicos. Em alguns exemplos, o contexto do sistema atual pode incluir uma combinação de um ou mais dos seguintes: uma data, uma hora, uma localização do dispositivo aviônico de origem, uma localização do dispositivo aviônico de destino, um estado de dispositivo da pluralidade de dispositivos aviônicos, e uma fase de voo da aeronave. Em alguns exemplos, o estado do dispositivo da pluralidade de dispositivos aviônicos pode incluir um modo operacional, um modo de manutenção ou um modo de carga de dados. Em alguns exemplos, a fase de voo da aeronave pode incluir um ou mais dos seguintes estados operacionais: ligamento do motor, pré-voo, partida do motor, embarque, taxiamento na decolagem, decolagem, subida inicial, subida, cruzeiro em trânsito, descida, terra de aproximação, apresentação no solo, taxiamento na aterrissagem, volta de pista, e desligamento do motor.
[006] O método compreende ainda analisar uma aceitabilidade da mensagem de rede pelo processador. A aceitabilidade da mensagem de rede é analisada identificando uma pluralidade de atributos correspondentes à mensagem de rede. Em alguns exemplos, a pluralidade de atributos corresponde ao cabeçalho e campos de dados do um ou mais pacotes de rede correspondentes à mensagem de rede. Em alguns exemplos, a pluralidade de atributos que correspondem à mensagem de rede inclui um ou mais dos seguintes: um endereço de destino, um endereço de origem, uma fase de voo da mensagem de rede, um estado de dispositivo da mensagem de rede, uma função, uma subfunção, um fluxo de dados e um protocolo.
[007] A aceitabilidade da mensagem de rede é ainda analisada determinando a aceitabilidade da mensagem de rede dentro do contexto do sistema com base em uma ou mais regras de filtro que especificam quais atributos são permitidos dentro de um contexto de sistema particular. Em alguns exemplos, uma ou mais regras de filtro são geradas automaticamente durante uma fase de teste da rede de aviação, capturando um ou mais pacotes de rede de teste correspondentes a um fluxo de rede funcional de teste transmitido dentro da rede de aviação. Um ou mais pacotes de rede de teste é(são) analisado(s) para extrair uma ou mais mensagens de rede de teste correspondentes ao fluxo de rede funcional de teste. A mensagem de rede de teste de uma ou mais mensagens de rede de teste pode então ser examinada de modo a identificar uma pluralidade de atributos de teste. Em alguns exemplos, a pluralidade de atributos de teste corresponde a cabeçalho e campos de dados de um ou mais pacotes de rede de teste correspondentes à mensagem de rede de teste. A pluralidade de atributos de teste da mensagem de rede de teste é então classificada. As uma ou mais regras de filtro é(são) gerada(s) automaticamente gerando automaticamente uma ou mais tabelas correspondentes a uma ou mais mensagens de rede de teste. Uma ou mais tabelas inclui(em) uma ou mais regras de filtro e são encadeadas com base em um ou mais atributos de teste das mensagens de rede de teste. Finalmente, uma ou mais regras de filtro é(são) validada(s).
[008] Em alguns exemplos, uma ou mais regras de filtro incluem uma ou mais regras de filtragem de pacotes profunda que impedem fluxos de dados não autorizados na rede de aviação examinando uma ou mais cargas úteis de um ou mais pacotes de rede. O método compreende ainda o reencaminhamento, pelo processador, da mensagem de rede para o dispositivo aviônico de destino se a mensagem de rede for determinada como aceitável dentro do contexto do sistema.
[009] Ainda em um outro exemplo, é proporcionado um sistema compreendendo um ou mais processadores, memória, um ou mais processadores e um ou mais programas armazenados na memória. Ainda noutro exemplo, é proporcionado um meio legível por computador não transitório compreendendo um ou mais programas configurados para execução por um sistema de computador. Em vários exemplos, um ou mais programas inclui(em) instruções para receber uma mensagem de rede por um processador de um sistema de computador. A mensagem de rede é transmitida de um dispositivo aviônico de origem para um dispositivo aviônico de destino via um ou mais pacotes de rede dentro de uma rede de aviação. Um ou mais programas inclui(em) ainda instruções para estabelecer, pelo processador, um contexto de sistema atual com base no monitoramento de um ou mais dispositivos aviônicos na rede de aviação. Em alguns exemplos, o contexto do sistema indica um estado agregado de um ou mais dispositivos aviônicos. Um ou mais programas inclui(em) ainda instruções para analisar uma aceitabilidade da mensagem de rede pelo processador. A aceitabilidade da mensagem de rede é analisada identificando uma pluralidade de atributos correspondentes à mensagem de rede. Em alguns exemplos, a pluralidade de atributos corresponde a cabeçalho e campos de dados do um ou mais pacotes de rede correspondentes à mensagem de rede. A aceitabilidade da mensagem de rede é ainda analisada determinando a aceitabilidade da mensagem de rede dentro do contexto do sistema com base em uma ou mais regras de filtro. Em alguns exemplos, as regras de filtro especificam quais atributos são permitidos dentro de um contexto de sistema específico. Um ou mais programas inclui(em) ainda instruções para encaminhamento, pelo processador, da mensagem de rede para o dispositivo aviônico de destino se a mensagem de rede for determinada para ser aceitável dentro do contexto do sistema.
BREVE DESCRIÇÃO DOS DESENHOS
[0010] A descrição pode ser melhor compreendida por referência à seguinte descrição tomada em conjunto com os desenhos anexos, que ilustram exemplos particulares da presente descrição.
[0011] A Figura IA ilustra uma vista geral de um sistema exemplificativo para implementar vários métodos da presente descrição de acordo com um ou mais exemplos.
[0012] A Figura 1B ilustra um sistema exemplificativo para filtragem de mensagens de acordo com o contexto de acordo com um ou mais exemplos.
[0013] A Figura 2 ilustra um exemplo de uma plataforma de aviação e-Habilitadas de acordo com um ou mais exemplos.
[0014] A Figura 3A ilustra um exemplo de um método para a filtragem de rede consciente de contexto de acordo com um ou mais exemplos.
[0015] A Figura 3B ilustra uma sequência de eventos para executar uma carga de dados sem fio de um Computador de Manutenção Central (CMC) através de um Sistema de Rede a bordo (ONS) de acordo com um ou mais exemplos.
[0016] As Figuras 4A, 4B, 4C e 4D ilustram outro exemplo de um método para a filtragem de rede consciente de contexto de acordo com um ou mais exemplos.
[0017] A Figura 5 é um diagrama de blocos que ilustra um exemplo de um sistema capaz de implementar vários processos descritos na presente descrição.
DESCRIÇÃO DETALHADA DE EXEMPLOS PARTICULARES
[0018] Será agora feita referência em detalhes a alguns exemplos específicos da presente descrição, incluindo os melhores modos contemplados pelos inventores para a realização da presente descrição. Exemplos destes exemplos específicos são ilustrados nos desenhos anexos. Embora a presente descrição seja descrita em conjunção com estes exemplos específicos, será entendido que não se pretende limitar a presente descrição aos exemplos descritos. Pelo contrário, pretende-se cobrir alternativas, modificações e equivalentes que possam ser incluídas no espírito e escopo da presente descrição como definido pelas reivindicações anexas.
[0019] Por exemplo, as técnicas da presente descrição serão descritas no contexto de funções particulares, subfunções e fluxos de dados de certas mensagens de rede. No entanto, deve ser notado que as técnicas da presente descrição são aplicadas a outros fluxos de rede e/ou protocolos com várias funções, subfunções e fluxos de dados. Como outro exemplo, as técnicas da presente descrição referir-se-ão a dispositivos e/ou entidades particulares dentro de uma rede de aviação. Como aqui usado, os termos “entidade” e “dispositivo” podem ser usados indiferentemente para se referirem a um ou mais vários dispositivos aviônicos dentro de uma rede de aviação que transmitem e/ou recebem pacotes de rede e/ou mensagens de rede. No entanto, deve ser notado que as técnicas da presente descrição são aplicadas a dispositivos de várias outras redes e tipos de rede. Na descrição a seguir, são apresentados numerosos detalhes específicos para proporcionar uma compreensão completa da presente descrição. Exemplos particulares da presente descrição podem ser implementados sem alguns ou todos estes detalhes específicos. Em outros casos, operações de processo bem conhecidas não foram descritas em detalhes a fim de não obscurecer desnecessariamente a presente descrição.
[0020] Várias técnicas e vários mecanismos da presente descrição serão, por vezes, descritos na forma singular para maior clareza. No entanto, deve ser notado que alguns exemplos incluem múltiplas iterações de uma técnica ou múltiplos casos de um mecanismo a menos que seja indicado o contrário. Por exemplo, um sistema usa um processador em uma variedade de contextos. No entanto, será apreciado que um sistema pode usar múltiplos processadores enquanto permanece dentro do escopo da presente descrição, a menos que seja indicado de outro modo. Além disso, as técnicas e mecanismos da presente descrição por vezes descreverão uma conexão entre duas entidades. Deve ser notado que uma conexão entre duas entidades não significa necessariamente uma conexão direta, desimpedida, como uma variedade de outras entidades podem residir entre as duas entidades. Por exemplo, um processador pode ser conectado à memória, mas será apreciado que uma variedade de pontes e controladores podem residir entre o processador e a memória. Consequentemente, uma conexão não significa necessariamente uma conexão direta, desimpedida, a menos que seja indicado o contrário.
Visão Geral [0021] A presente descrição proporciona um sistema e um método para a filtragem de conteúdo de mensagem consistente em contexto de fluxos de rede funcional para plataformas e infraestruturas de aviação e-Habilitadas. Os pacotes de rede transmitidos entre vários dispositivos aviônicos em um sistema aviônico em rede podem incluir uma ou mais mensagens de rede. Tais dispositivos aviônicos podem compreender vários dispositivos de comunicação e/ou computadores dentro de uma aeronave, centro de controle, etc. Em alguns exemplos, a mensagem de rede transmitida pode ser recebida por um sistema de computador que atua como um filtro de firewall. O sistema de computador pode determinar um contexto do sistema atual de aviação em rede com base no monitoramento de um ou mais dispositivos aviônicos dentro do sistema de aviação em rede para informações de estado, tais como, a localização, o estado do dispositivo e/ou a fase de voo dos dispositivos aviônicos. O contexto do sistema atual também pode incluir a data e a hora atuais.
[0022] Com base nesse contexto atual, o sistema de computador pode determinar a aceitabilidade da mensagem de rede recebida com base em regras de filtro especificando quais atributos são permitidos dentro de um contexto de sistema particular. O sistema de computador identifica atributos da mensagem de rede examinando vários cabeçalhos e campos de dados dos pacotes de rede correspondentes à mensagem de rede através de uma profunda identificação de pacotes. O sistema de computador envia então a mensagem de rede para o dispositivo aviônico que é a entidade de destino se for determinado que os atributos particulares da mensagem de rede recebida são aceitáveis dentro do contexto do sistema atual de aviação em rede. Desta forma, o sistema de computador pode impor restrições baseadas em contexto em mensagens de rede transmitidas dentro do sistema de aviação em rede. Formas de realização exemplificativas [0023] A Figura IA ilustra uma vista geral de um sistema exemplificativo 100 para implementar vários métodos da presente descrição de acordo com um ou mais exemplos. Em particular, a Figura IA descreve um usuário que acessa uma rede 104 usando um computador 102 configurado com um navegador web para interagir com outro computador 106. Em alguns exemplos, o computador 106 pode ser configurado como um servidor contendo módulos necessários para satisfazer a solicitação do usuário. Em alguns exemplos, os computadores 102 e/ou 106 podem ser computadores de propósito geral. Em outros exemplos, os computadores 102 e/ou 106 podem ser dispositivos aviônicos especializados que incluem controles e sistemas de interface configuráveis para operar em um sistema, plataforma e/ou arquitetura de aviação em rede. Em outros exemplos, o sistema 100 pode incluir outros dispositivos e/ou computadores conectados aos computadores 102 e 106 através da rede 104. Em alguns exemplos, a rede 104 pode ser uma conexão Ethernet e/ou outras tecnologias padrão de Internet e de rede de área local (LAN) incluindo IP e UDP. Em outros exemplos, a rede 104 pode ser qualquer outra rede direta e/ou sem fio.
[0024] A Figura 1B mostra uma arquitetura de sistema exemplificativo 101 para a captura de pacotes de rede de acordo com um ou mais exemplos da presente descrição. Dois sistemas, sistema 110 e sistema 114, são conectados através de uma conexão por Ethernet, tal como a rede 104. Cada sistema (110 ou 114) pode ser um sistema de computador incluindo computadores 102 ou 106, ou sistemas aviônicos tipo uma unidade substituível de linha única (LRU) ou uma coleção de LRUs. Uma LRU pode compreender um componente modular de um avião, navio ou espaçonave (ou qualquer outro dispositivo aviônico fabricado) que foi concebido para ser substituído rapidamente em um localização de operação. Uma LRU pode ser uma unidade vedada tal como um rádio ou outro equipamento auxiliar. Por exemplo, o sistema 110 e/ou o sistema 114 podem ser componentes de comunicação e/ou computadores de uma aeronave, um satélite, uma torre de controle, uma torre celular, outros sistemas fora de bordo que se comuniquem com redes em aeronave e/ou simulações dos mesmos. A Figura 1B mostra o sistema 110 constituído por um Computador de Gerenciamento de Voo 120 (FMC) e um Sistema de Rede a bordo 122 (ONS) que se comunicam através de um roteador 116. O Sistema 114 é constituído por três LRUs incluindo um Computador de Manutenção Central 124 (CMC), Computador portátil de Manutenção 126 (ML) e uma Impressora 130 se comunicando através de um roteador 128.
[0025] Um dos objetivos da presente descrição é proporcionar um meio para criar automaticamente as regras de filtro de firewall para firewall 112 para controlar o fluxo de informação entre o sistema 110 e o sistema 114. A conexão entre o sistema 110 e o sistema 114 sobre a rede 104, é representada pela seta A. Em vários exemplos, os dados transferidos entre o sistema 110 e o sistema 114 podem ser capturados por uma derivação de rede 118 em qualquer lugar ao longo da seta A monitorando a conexão entre o sistema 110 e o sistema 114. Em vários exemplos, os dados podem ser capturados por outro computador conectados à rede 104, tais como computadores 104 e/ou 106. Em certos exemplos, os dados podem ser capturados por vários métodos, incluindo, mas não limitados a, software de captura em pacotes ("PCAP") para registar todos os pacotes de dados transmitidos entre o sistema 110 e o sistema 114. Os pacotes de dados incluem uma ou mais mensagens de rede. Uma vez capturados, os pacotes de dados podem então ser analisados, examinados, classificados e agrupados em fluxos de rede funcionais para criar regras de filtro para firewall 112 para controlar o fluxo de informação entre o sistema 110 e o sistema 114, como será descrito adiante. Um fluxo de rede funcional pode corresponder a um grupo de mensagens de rede que corresponde a uma função de aeronave de nível mais alto, subfunção, fluxo de dados e protocolo.
[0026] Os fluxos funcionais das principais funções da aeronave, tipo gerenciamento de voo, impressão, carregador de dados ou manutenção central, podem conter subfunções que também podem ser descritas como fluxos de dados diferentes. Em alguns exemplos, os fluxos de dados são uma troca temporal ou de protocolo. Exemplos de fluxos funcionais usados para ilustrar este processo de descrição incluem: 1. Carga de dados (protocolo) a. Autenticação/conexão IEEE 802. lx b. Estabelecer a sessão ARINC 615A c. Realizar a operação de carga de dados utilizando o Protocolo de Transferência de Arquivo Trivial (TFTP) d. Fechar a sessão ARINC 615A 2. Trabalho de impressora (Protocolo) 3. Funções de computação de Manutenção Central (CMCF) a. BITE contínuo (Equipamento embutido) relatando que não estabelece uma sessão (temporal) b. Consulta do relatório de configuração de LRU da CMCF (Protocolo) [0027] A Figura 2 ilustra um exemplo de uma plataforma de aviação e-Habilitadas 200 que pode ser implementada em conjunto com as técnicas e mecanismos da presente descrição de acordo com um ou mais exemplos. As plataformas e infraestruturas de aviação estão adotando rapidamente arquiteturas e tecnologias e-Habilitadas para tirar vantagem das eficiências operacionais e de desempenho que resultam em conexão em rede. Em vários exemplos da plataforma 200, uma aeronave e-Habilitada 202 pode ser conectada em várias entidades através de uma rede 204 de aeronave para aeronave (A2A) e/ou uma rede aeronave para terra (A2I) 206. Em alguns exemplos, a aeronave 202 pode incluir vários sistemas de rede em aeronave com rádios de comunicação correspondentes, incluindo sistema de posição global (GPS) 206, sistemas embutidos 208, etiquetas de identificação por radiofrequência (210), rede de sensores sem fio 212, 802.11 pontos de acesso de 214 e dispositivos de passageiros 216. Em alguns exemplos, a aeronave 202 também pode incluir aplicativos 204 que integram as múltiplas fontes de dados entre o avião 202 e os sistemas da terra. Em alguns exemplos, as fontes de dados podem transportar informação correspondente a software carregável (por exemplo, bases de dados de navegação, saco de voo eletrônico, relatórios meteorológicos), dados de saúde (por exemplo, dados de sensor e etiqueta sem fio, diagnósticos) e dados de controle de tráfego (por exemplo, sinais de tráfego). Em alguns exemplos, os sistemas de rede de aeronaves podem ser sistemas 110ell4e podem incluir computadores e/ou servidores, tais como computadores 102 e 106. Em alguns exemplos, as aplicações 204 podem estar localizadas em computadores, tais como computadores 102 e 106, e sistemas, tais como os sistemas 110 e 114. Em alguns exemplos, os sistemas de rede dentro da aeronave podem incluir uma rede de dados segura que é protegida por um firewall, tal como o filtro de firewall 112.
[0028] Em alguns exemplos, a aeronave e-habilitada 202 pode ter múltiplas entidades a comunicar com ela para cada aplicação, incluindo: comerciantes de comércio eletrônico, fabricantes de aviões, fornecedores de equipamento a bordo, companhias aéreas, fornecedores de serviços de rede aeronáuticos e outros, (por exemplo, a Federal Aviation Administration) e outros aviões, tal como aeronave 220 e a aeronave não tripulada 222. Por exemplo, os sistemas de rede em aeronave podem enviar informação e/ou receber informação a partir de outra aeronave 220 e/ou sistema de aeronave não tripulada 222 através A2A da rede 204. Tal informação pode incluir uma Tecnologia de vigilância cooperativa de rastreamento (ADS-B) baseada no enlace Squitter estendido de 1090 MHz ou outros sinais para identificar e rastrear aeronave. Por exemplo, usando uma ligação de dados ADS-B, cada aeronave 202, 220 e 222 pode automaticamente transmitir sua posição precisa, sua velocidade (vertical e horizontalmente), bem como sua altitude e outra informação para controladores e outras aeronaves próximas.
[0029] De modo semelhante, os sistemas de rede em aeronave podem enviar informação para e/ou receber informação de entidades de infraestrutura de companhias aéreas através da comunicação com o satélite 224, o ponto de acesso do aeroporto 226, a estação terrestre de controle de tráfego aéreo (ATC) 228, e/ou estação de base celular 230, através A2I da rede 206. Em alguns exemplos, os enlaces A2I com entidades de infraestrutura de companhias aéreas podem ser através de um satélite de banda larga (via SATCOM) quando o avião está no ar ou um enlace 802.11 quando na terra. Em alguns exemplos, um centro ATC pode transmitir sinais, informações de trânsito e/ou outras informações de navegação através da estação terrestre de controle de tráfego aéreo 228. Em alguns exemplos, as comunicações com as estações terrestres ATC podem ser efetuadas por meio de protocolos aeronáuticos por enlaces de rádio via satélite ou terrestres. ADS-B pode fornecer um enlace de rádio Mode S adicional com os centros ATC. Em alguns exemplos, fornecedores terceirizados podem fornecer serviços de internet, banda larga e outros serviços via estação de base celular 230.
[0030] A e-habilitação das plataformas e infraestruturas de aviação, tanto a bordo como fora de bordo, resultou em sistemas físicos interconectados e infraestruturas de cadeia de abastecimento que agora são um alvo potencial para as ameaças de cibersegurança dinâmicas e crescentes devido a um maior acesso à sistemas de computação em rede. As plataformas e infraestruturas de aviação são sistemas complexos que envolvem sistemas e controladores embutidos hierarquicamente interligados em rede, com diferentes requisitos de criticidade, confiabilidade e disponibilidade operacionais. Além disso, os sistemas e controladores embutidos são cada vez mais hospedados em hardware de computação de propósito geral, sistemas operacionais de software comercial e aplicativos personalizados específicos que executam as funções de sistema pretendidas. Esses sistemas e controladores embutidos a bordo são conectados em rede por meio de protocolos baseados em IETF e ARINC, tais como comunicações e protocolos de rede com e sem fio, IP e IEEE. Além disso, os sistemas a bordo são de rede com sistemas de computação fora de bordo via protocolos baseados em IP e IETF padrão, tais como UDP e TCP. O uso crescente de protocolos de computação e comunicação baseados em padrões permite uma integração perfeita da arquitetura e-Habilitada, mas também aumenta a vulnerabilidade aos ataques de cibersegurança.
[0031] Em vários exemplos, algumas entidades conectadas na plataforma de aviação e-Habilitada 200 podem ser entidades de confiança e algumas entidades podem ser entidades não confiáveis. Assim, é importante evitar fluxos de dados não autorizados em tais plataformas de aviação e-Habilitadas e filtrar as informações e/ou comunicações com base no contexto do sistema, incluindo a fase de voo, a localização da aeronave, o horário e o local.
[0032] A Figura 3A ilustra um método exemplificativo 300 para filtragem de rede consistente em contexto de acordo com um ou mais exemplos. Na etapa 301, é recebida uma mensagem de rede. Em alguns exemplos, uma mensagem de rede pode ser transmitida entre dispositivos em um sistema, tal como o sistema 100 e/ou 101, através de um ou mais pacotes de rede dentro de um fluxo de rede. Em alguns exemplos, um fluxo de rede funcional pode ser uma sequência de pacotes de uma fonte para um destino, que pode ser um hospedeiro, um grupo de multidifusão ou um domínio de difusão. Em alguns exemplos, um fluxo de rede funcional pode ser identificado unicamente pelos seguintes parâmetros dentro de um determinado período de tempo: endereço de IP de origem e de destino, portão de origem e de destino e protocolo de camada 4. Em vários exemplos, os fluxos de rede funcionais podem vir de várias fontes diferentes, tais como o sistema 110 e/ou o sistema 114.
[0033] Na etapa 303, o contexto do sistema atual é determinado. Em alguns exemplos, o contexto do sistema atual pode corresponder a uma fase de voo particular. Em alguns exemplos, o contexto do sistema pode ser determinado com base em mensagens de rede capturadas que são mensagens de fase de voo que indicam a fase de voo particular. Em outros exemplos, o contexto do sistema atual pode ser baseado em outras medições e pode ser determinado com base em outras informações recebidas de vários sistemas e dispositivos. Em vários exemplos, o contexto do sistema pode compreender um ou mais dos seguintes: localização, data, hora, estado do dispositivo e fase de voo. A localização do sistema, tal como o sistema 100 e/ou 101, pode ser determinada pelo sistema de posição global (GPS) ou outros meios de geolocalização incluindo métodos de localização por radiofrequência (RF), tais como Diferença de Hora de Chegada (TDOA), triangulação por torres celulares ou geolocalização de internet e computador através da associação com endereço de IP, RFID de endereço MAC, etc. Em vários exemplos, o estado do dispositivo do sistema pode incluir um modo operacional, um modo de manutenção e/ou um modo de carga de dados. Em vários exemplos, o sistema pode adicionalmente estar em uma fase de voo particular, que pode compreender um ou mais dos seguintes estados operacionais: ligamento do motor, pré-voo, partida do motor, embarque, taxiamento na decolagem, decolagem, subida inicial, subida, cruzeiro em trânsito, descida, terra de aproximação, apresentação no solo, taxiamento na aterrissagem, volta de pista, e desligamento do motor. Por exemplo, o sistema ou aeronave pode estar em um modo operacional durante as fases de voo em que a aeronave se afasta do portão e/ou no ar. Altemativamente, se a aeronave estiver no solo, o sistema atual pode estar no modo de manutenção. Em alguns exemplos, uma aeronave pode ser considerada no solo durante uma ou mais fases de voo entre o momento em que a aeronave chega a um portão de terminal e a hora em que parte em seu próximo voo. Tais fases de voo podem incluir, mas não estão limitadas a, embarque, desligamento do motor, o pré-voo e o partida do motor. Em outros exemplos, uma aeronave também pode ser considerada no solo durante outras fases de voo, como taxiamento de aterrisagem e taxiamento de decolagem. Em alguns exemplos, somente ações de manutenção típicas são permitidas quando o sistema está em modo de manutenção, tal como descarregamento de dados de falha de compra, consultas para informações de configuração, e carga de dados de novos dados operacionais ou de configuração nas unidades substituíveis de linha (LRU).
[0034] Em vários exemplos, vários outros tipos de mensagens de rede e/ou fluxos podem ser permitidos e/ou bloqueados sobre uma plataforma e-Habilitadas dependendo das diferentes fases de voo. Por exemplo, a fase de pré-voo pode incluir qualquer atividade envolvida na preparação da aeronave para partida, durante a qual a tripulação deve determinar a aeronavegabilidade da aeronave e abordar quaisquer questões em aberto antes da partida. Em alguns exemplos, a aeronave pode ter capacidades de voo automático extensivas que permitem que muitas das tarefas de otimização de navegação e desempenho sejam realizadas automaticamente se desejado. A programação de inicialização de voo automático e de sistema de gerenciamento de voo (FMS) pode ser realizada durante a fase de pré-voo. Em vários exemplos, os parâmetros de voo necessários são selecionados ou programados no sistema durante a fase de pré-voo. Algumas companhias aéreas possuem sistemas de informação que permitem que as informações necessárias para inicializar os sistemas de voo automático sejam carregadas automaticamente através de uma unidade de ligação de dados de ACARS (Sistema de endereçamento e reporte de comunicações de aeronaves). ACARS tipicamente utiliza uma ligação de dados de VHF e interface alfanumérica para facilitar a comunicação específica da empresa entre a aeronave e um centro de operações aéreas central (AOC).
[0035] Durante a fase de voo antes da partida, o capitão, o agente de portão e o chefe da tripulação do solo coordenam seus esforços para assegurar que todos os requisitos de pré-partida sejam atendidos, à medida que a hora de partida programada se aproxima. Os pilotos podem finalizar os parâmetros de FMS e voo automático, obtendo uma atualização sobre as condições meteorológicas e a utilização da pista através do Serviço de Informação do Terminal do Aeroporto (ATIS). Além disso, a tripulação deve receber confirmação do roteamento do voo do ATC. Antes da partida programada (geralmente pelo menos algumas horas antes), o escritório de expedição da companhia aérea arquiva um roteamento solicitado com base em sua otimização de plano de voo com ATC. Aproximadamente 20 minutos antes da partida, a autorização da rota do ATC é solicitada, preferencialmente através da função de Autorização de Pré-Partida (PDC) ACARS. A autorização da rota ATC recebida pela tripulação pode diferir do roteiro arquivado e as alterações devem ser endereçadas (combustível/desempenho/considerações de despacho) e reprogramadas.
[0036] Além de possíveis mudanças de roteamento, o ATC também pode ajustar o horário de partida planejado como resultado da dinâmica do espaço aéreo atual. A autorização do ATC pode incluir um tempo de “espera de portão” ou hora do “levantamento das rodas” esperada devido ao congestionamento de trânsito, conflitos de roteamento ou condições climáticas adversas. Para preparar a aeronave para o movimento, a tripulação do solo completa da carga da bagagem e da carga de transporte, incluindo os sacos tardios, e fecha as portas de carga. Tipicamente, o Capitão se comunica com o piloto (ou outro tripulante de solo) através de uma ligação de “interfone”, enquanto o Primeiro Oficial se comunica com o controle de rampa e/ou ATC através do rádio de VHF.
[0037] Sempre que o movimento terrestre é iniciado, a permissão deve ser recebida da autoridade de controle, como na fase de taxiamento de decolagem. Em algum ponto antes de deixar a área da rampa, o Primeiro Oficial contacta o controle terrestre para obter a autorização de taxiamento para a pista ativa. Considerações operacionais, tais como alto peso à decolagem, podem ditar a solicitação de uma pista especial que pode resultar em um taxiamento e/ou atraso de decolagem enquanto o ATC elabora uma sequência modificada. Durante o taxiamento, a saída de carga é recebida via ACARS ou por rádio de VHF. Nas situações em que haverá um longo taxiamento devido a numerosas partidas à frente na sequência da decolagem, o capitão pode fazer um anúncio de PA informando os passageiros e a tripulação de cabine de sua melhor estimativa da duração do atraso. Se o atraso for significativo, a empresa poderá ter de ser atualizada via rádio de ACARS ou VHF com um novo ETO (tempo estimado “desligado”). À medida que a aeronave se aproxima da extremidade de partida da pista, o capitão pode fazer um anúncio de partida da PA para informar aos comissários de bordo de que a decolagem é iminente e devem se proteger nas estações. Uma instrução de passageiros (vídeo) também pode ser mostrada.
[0038] Em vários exemplos, as mensagens de rede durante a fase de decolagem podem incluir várias comunicações da torre de controle para a aeronave. Por exemplo, para tomar o uso mais eficiente dos recursos da pista, o controlador da torre local emite frequentemente uma autorização de “posição e retenção” para uma aeronave em preparação para a autorização de decolagem final, a fim de permitir que a aeronave faça taxiamento na posição e espere na pista de decolagem enquanto espera por outro tráfego, restrições de pista ou um tempo de partida emitido pelo ATC (controle de tráfego aéreo). Altemativamente, se este tempo de espera não for exigido ou uma partida precisar de ser acelerada, a torre pode autorizar o voo para a decolagem sem ficar em posição. Como outro exemplo, os requisitos adequados de separação de vigília devem ser assegurados confirmando que um intervalo aceitável de tempo se passou antes de iniciar a apresentação de decolagem se o voo for depois da partida de uma aeronave grande.
[0039] Uma decolagem sem incidentes é tipicamente seguida pela fase de subida. Uma subida inicial normal inclui “limpar” a aeronave (engrenagem levantada, flapes/slats retraídos), conforme as exigências de ruído e/ou obstáculo. A dinâmica do ambiente de voo, incluindo a adaptação ATC diretas, exige que a tripulação monitore continuamente o desempenho da aeronave a fim de obter o melhor perfil de voo possível. Em algum ponto durante a subida, a tripulação da cabine de pilotagem verifica o FMS e/ou gráficos de desempenho para comparar as altitudes de cruzeiro otimizadas e máximas com os dados planejados e cruzeiro desejado em Mach. Esta informação é usada para coordenar uma altitude de cruzeiro ideal com ATC. Outros fatores incluem dados de vento e condições de passeio (turbulência), tempo de convecção em convecção, contingências de Lista de Equipamentos Mínimos (MEL), restrições de velocidade induzidas pelo tráfego e questões de consumo de combustível. As atividades relacionadas ao passageiro durante a escalada podem incluir o início da refeição e/ou serviço de bebidas, entregando qualquer anúncio PA de comercialização e ativando qualquer sistema de entretenimento. Além disso, o Capitão costuma fazer um PA descrevendo o tempo de voo e condições meteorológicas, pontos de interesse, estimativa de chegada, tempo de destino e, se aplicável, qualquer informação sobre a presença de uma tripulação aumentada e/ou informações de segurança.
[0040] Em alguns exemplos, à medida que a altitude de cruzeiro é alcançada durante a fase de cruzeiro em trânsito, as configurações de energia e/ou o Mach alvo pode(m) ser estabelecidos, e as tripulações irão reportar o nível ao ATC. A tripulação também executa várias tarefas administrativas, incluindo ligação descendente de qualquer código de ACARS de retardo de partida e registrando o perfil do monitor do motor (se não automatizado). A aeronave é usualmente equipada com pelo menos 2 transceptores de VHF e, se certificada sobre a água, rádios de HF. Gerenciamento por rádio de VHF usualmente requer um sintonizador para ser ajustado para a frequência de ATC atual, enquanto o outro é utilizado para comunicações da empresa ou para manter uma escuta de rádio no canal de emergência universal (121,5 MHz). As comunicações por satélite (SATCOM) podem ser usadas sempre que disponíveis para o ATC e as comunicações da empresa. Os sistemas de SATCOM oferecem o benefício da cobertura de comunicação mundial sem a degradação do sinal, variabilidade da hora do dia e outras deficiências associadas à HC. Além disso, quando fora do contato de VHF com instalações terrestres, a tripulação normalmente mantém uma escuta de rádio na frequência ar-ar de 123,45 MHz. Este canal pode ser usado para passar informação operacional, tais como relatórios de percurso e tempo de rota entre aeronaves.
[0041] Em outros exemplos, as fontes de informação disponíveis para a tomada de decisão de nível de cruzeiro incluem Relatórios Piloto (PIREP) de outros voos, ATC, experiência própria da tripulação, expedição e plano de voo. Em voos internacionais, a transição através de fronteiras do espaço aéreo sob a jurisdição de outras soberanias nacionais pode exigir procedimentos suplementares para lidar com as restrições locais. Estes limites de FIR (Região de Informação de Voo) normalmente requerem notificação prévia através do processo de planejamento de voo (plano de voo arquivado), e o contato preliminar da aeronave à medida que o voo se aproxima da fronteira. Em geral, devem ser emitidas autorizações do ATC separadas em cada cruzamento de fronteira, incluindo a entrada no espaço aéreo oceânico.
[0042] A necessidade de desviar-se da trilha desejada devido ao tempo adverso é sempre uma possibilidade. As condições de tempo e as tempestades convectivas e podem exigir desvios dos roteiros planejados, mas isso é facilitado pela coordenação com ATC neste ambiente de VHF/radar. Como em outras fases do voo, a tripulação deve estar constantemente preparada para a possibilidade de contingências que requerem desvio da aeronave para um aeroporto alternativo em trânsito. Além do possível fechamento do aeroporto de destino (devido a condições meteorológicas, falhas de energia ou outras situações de campo), as razões para desviar incluem emergências médicas (passageiros/tripulantes doentes), problemas com equipamentos de aeronaves, atividades terroristas a bordo, tempos de espera inaceitáveis, desvio de combustível devido a retardos de vento ou de tráfego.
[0043] Durante a fase de descida, a descida inicial pode ocorrer com cerca de 30 a 40 minutos restantes no voo, em cujo tempo a tripulação inicia as suas preparações de aproximação e aterrisagem. Uma mensagem "Em Alcance" é frequentemente transmitida para a estação de destino através de ACARS ou por rádio de VHF. Esta mensagem inclui a última estimativa de toque na pista, solicitações especiais de passageiros (cadeiras de rodas/conexões) e, se ainda não foi transmitida, quaisquer discrepâncias de manutenção. A estação transmite, ou faz ligação ascendente com, a atribuição do portão de chegada, o estado da unidade de potência terrestre e qualquer outra mensagem de estado relevante, tal como um requisito de “somente reboque” para o portão atribuído. Durante a descida, o ATC pode emitir restrições de cruzamento que podem ser parte de um procedimento de chegada padrão publicado, como uma rota de chegada de terminal padrão (STAR), ou como uma resposta a uma exigência de sequenciamento de tráfego. O FMS é o principal recurso disponível para a tripulação para o planejamento da descida, uma vez que as restrições podem ser programadas diretamente através da CDU e um perfil calculado.
[0044] As condições climáticas de destino e os procedimentos esperados de aproximação/pista são considerações importantes no planejamento da chegada. A principal fonte desta informação é o Sistema de Informação de Terminais de Aeroportos (ATIS), embora os atrasos de espera, as condições meteorológicas e as operações de pista possam ser transmitidas através de ATC e/ou expedição. ATIS fornece os procedimentos atuais de condições meteorológicas, procedimentos de aproximação por instrumentos em uso e pistas ativas, bem como detalhes sobre fechamentos de pistas de taxiamento e de rodagem, relatórios de cisalhamento de vento, valores de visibilidade precisos para pistas individuais, capacidade de frear, atividade de pássaros, obstruções temporárias (por exemplo, construção), utilização de terreno e operações de curo prazo (LAHSO) e quaisquer outras informações relevantes relacionadas com a segurança.
[0045] A aeronave operada pela maioria das transportadoras aéreas é usualmente equipada para satisfazer os requisitos de navegação de uma variedade de procedimentos de aproximação para a fase de aproximação. As abordagens de precisão incluem a aterrisagem com piloto automático por sistema de posicionamento global (GPS), GPS LNAV/VNAV e abordagens ILS de categoria (CAT) I, II e ΠΙ como descrito anteriormente. Muitas pistas em aeroportos maiores utilizam o Sistema de Aterrisagem por Instrumentos (ILS) para fornecer orientação aos pilotos durante as condições do instrumento ao longo de um trajeto bem definido constituído por elementos laterais e verticais chamados de localizador e trajetória de planeio, respectivamente. Uma aproximação de não-precisão é um procedimento onde as informações de trilhos laterais são fornecidas por um auxílio de navegação local (navegável) ou por satélite, mas a orientação vertical é recebida através de referência barométrica ou outros meios não diretamente associados com a pista específica. Como esperado, as abordagens de precisão preveem operações em condições muito mais baixas de teto e visibilidade.
[0046] Se os requisitos para a conclusão da aproximação e aterrisagem não for satisfeita, a fase de volta de pista pode ser executada e um “procedimento normalizado de aproximação falhada” e/ou instruções do ATC padronizado(as) deve(m) ser seguido(as). As opções disponíveis na sequência de uma aproximação interrompida incluem entrar em espera para esperar qualquer condição inaceitável resultou na aterrisagem abortada, desviando para um aeroporto alternativo, ou mais comumente, aceitando vetores do ATC para iniciar outra aproximação. Muitas aterrisagens abortadas são iniciadas pelo ATC ou pela tripulação da cabine de pilotagem devido ao tráfego na pista. Na maioria dos casos, uma chegada anterior não conseguiu autorizar a pista de uma forma temporal, mas uma decolagem tardia por uma aeronave sentada na posição no limiar também pode resultar em uma aterrisagem abortada.
[0047] Depois de tocar na pista, durante a fase de aterrisagem e/ou apresentação no solo, o piloto usa impulso de inversão, spoilers de solo e freios nas rodas para desacelerar a velocidade de taxiamento e desocupar a pista. Depois de sair da pista, o Primeiro Oficial pode entrar em contato com o controle terrestre para obter instruções de táxi, completar a lista de verificação de taxiamento após aterrisagem e chamar o controle de rampa local para confirmar a atribuição do portão de chegada e o estado de ocupação. Durante a fase de taxiamento na aterrissagem, os pilotos podem usar cartas de pista de taxiamento do aeroporto de destino para ajudar na execução das autorizações de taxiamento que lhes é dado pelo ATC. Se o portão de chegada estiver ocupado, a aeronave pode ser obrigada a esperar o atraso em um local remoto. Portões ocupados são muitas vezes o resultado de uma partida atrasada ou outras questões operacionais com a aeronave atualmente posicionada no portão e o atraso antecipado deve ser passado para o ATC e os passageiros.
Algumas estações utilizam sistemas de estacionamento automático que empregam um arranjo de luzes e/ou sinalizações que o capitão usa para conduzir orientação de linha e paragem.
[0048] O dispositivo de origem da mensagem de rede é determinado na etapa 305 e o dispositivo de destino é determinado na etapa 307. Em alguns exemplos, o dispositivo de origem e/ou de destino pode ser um ou mais vários dispositivos aviônicos dentro de uma rede de aviação, tais como os dispositivos descritos na Figura 1B. Em outros exemplos, o dispositivo de origem e/ou de destino pode ser um processo, uma aplicação, um dispositivo e/ou um sistema operativo (SO). Conforme descrito anteriormente, um fluxo de rede funcional e mensagens de rede nele incluídas podem ser identificados unicamente pelos seguintes parâmetros dentro de um determinado período de tempo: endereço de IP de origem e de destino, portão de origem e de destino e protocolo de camada 4. Em alguns exemplos, um firewall, tal como o firewall 112, pode inspecionar os pacotes de rede transmitidos para determinar se o pacote corresponde ao conjunto de regras de filtragem do firewall com base na informação contida no pacote, tal como uma combinação da origem do pacote e do endereço de destino, seu protocolo, e, para o tráfego TCP e UDP, o número da porta.
[0049] Em alguns exemplos, o firewall pode ser um firewall de camada de rede, um filtro de pacotes, um firewall de camada de aplicação e/ou qualquer combinação dos mesmos. Em alguns exemplos, o firewall pode ser um firewall sem estado que não determina se um pacote faz parte de um fluxo de tráfego existente (por exemplo, não armazena nenhuma informação sobre o “estado” de conexão) e filtra somente cada pacote com base apenas nas informações contidas no próprio pacote. Em outros exemplos, o firewall pode ser um firewall com estado, que pode manter o contexto sobre sessões ativas, e usar essa “informação de estado” para acelerar o processamento de pacotes. Por exemplo, uma conexão de rede existente, como a representada pela seta A na Figura 1B, pode ser descrita por várias propriedades, incluindo endereço de IP de origem e destino, portas de UDP ou TCP e o estágio atual da vida útil da conexão (incluindo iniciação de sessão, estabelecimento de ligação, transferência de dados ou conexão de conclusão). Se um pacote de rede não corresponder a uma conexão existente, ele será avaliado de acordo com o conjunto de regras para novas conexões. Se um pacote corresponder a uma conexão existente com base na comparação com a tabela de estado do firewall, poderá ser permitido passar sem processamento posterior.
[0050] Na etapa 309, o conteúdo do campo de dados da mensagem de rede é identificado para determinar se a mensagem de rede, que é enviada a partir do dispositivo de origem e direcionada para o dispositivo de destino, é aceitável quando o sistema está no contexto atual. Em outros exemplos, o firewall pode incorporar ser programado com regras de filtragem de pacotes profunda para executar a inspeção de pacotes profunda (DPI) dos pacotes de rede recebidos. Em alguns exemplos, esse firewall habilitado com profundas capacidades de inspeção de pacotes pode ter a capacidade de olhar na camada 2 e além da camada 3 do modelo OSI. Em alguns casos, a DPI pode ser invocada para olhar através da camada 2-7 do modelo OSI, incluindo cabeçalhos e estruturas de protocolo de dados, bem como a carga útil da mensagem de rede. A funcionalidade de DPI é invocada quando um dispositivo procura ou toma outra ação, com base em informações além da camada 3 do modelo OSI. Em alguns exemplos, a DPI pode identificar e classificar o tráfego baseado em um banco de dados de assinatura que inclui informações extraídas da parte de dados de um pacote, permitindo um controle mais fino do que a classificação baseada apenas em informações de cabeçalho. Em alguns exemplos, a mensagem de rede pode ser adicionalmente examinada pelo firewall, tal como através da inspeção de pacotes profunda, para identificar e/ou definir atributos adicionais da mensagem de rede recebida. Em vários exemplos, tais atributos podem incluir estado do dispositivo, fase de voo, função, subfunção, fluxo de dados e/ou protocolo. Em alguns exemplos, tais atributos podem corresponder aos campos de cabeçalho e de dados dos pacotes de rede e indicar o tipo de ação iniciada por uma mensagem de rede.
[0051] Em alguns exemplos, a ação iniciada por uma mensagem de rede pode ser várias ações baseadas em aplicativo, como abrir, imprimir, copiar, iniciar, escrever e/ou se comunicar com. Em outros exemplos, outras ações podem ser iniciadas por uma mensagem de rede. Em alguns exemplos, tais ações da mensagem de rede podem estar associadas a um estado de dispositivo e/ou fases de voo correspondentes. Como descrito anteriormente, tais fases de voo podem incluir, mas não se limitando a, pré-voo; ligar o motor; embarque; taxiamento na decolagem; decolagem; subida inicial; subida; cruzeiro em trânsito; descida; terra de aproximação; apresentação no solo, taxiamento na aterrissagem, volta de pista, e desligamento do motor. Em alguns exemplos, uma ou mais dessas fases de voo podem corresponder a um estado do dispositivo, tal como modo operacional, modo de manutenção ou modo de carga de dados.
[0052] Em alguns exemplos, a função, a subfunção e o fluxo de dados de uma mensagem de rede podem categorizar a mensagem transportada pela mensagem de rede e/ou uma ação iniciada pela mensagem de rede. Por exemplo, as funções de uma mensagem de rede podem incluir carga de dados sem fio, manutenção central e funções de computação (“CMCF’), trabalhos de impressão, etc. Outros fluxos funcionais das principais funções de aeronaves podem incluir ainda a gerenciamento de voo, gerenciamento de impulso e/ou monitoramento da condição da aeronave. Tais fluxos funcionais podem conter subfunções, que também podem ser descritas como fluxos de dados diferentes. Em vários exemplos, a subfunção de uma mensagem de rede pode ser uma implementação particular da função da mensagem de rede. Por exemplo, uma função de carga de dados sem fio pode incluir subfunções como IEEE 802. lx, 615A, Config Relatório, Imprimir Solicitação, etc.
[0053] Em alguns exemplos, o fluxo de dados de uma mensagem de rede pode descrever a ação específica iniciada pela mensagem de rede. Em alguns exemplos, o fluxo de dados pode ser temporal ou de troca de protocolo. Por exemplo, os fluxos funcionais, incluindo trabalhos de impressão e de carga de dados sem fio, são trocas de protocolo. 802. lx autenticação e/ou autorização é outro exemplo de um protocolo de troca de fluxo de dados. Os fluxos de dados de velocidade de ar e/ou altitude são um exemplo de fluxos de dados temporais. As funções de computação de manutenção central podem incluir fluxos de dados de troca temporal e de protocolo. Por exemplo, um relatório de equipamento de teste embutido contínuo ("BITE"), que não estabelece uma sessão, é um fluxo de dados temporais. Da mesma forma, um estado funcional que é lançado a partir da lista de sistema de membro estabelecido é um fluxo de dados temporais. Outro fluxo de dados temporais pode ser funções que se enfileiram para dados da lista do sistema de membros estabelecida. No entanto, uma consulta do estado da unidade substituível linha (“LRU”) de CMCF, é um protocolo de fluxo de dados.
[0054] Por exemplo, uma mensagem de rede pode ser uma ação para carregar software para um dispositivo aviônico, tal como uma mensagem de rede 4 mostrada na Tabela 1 abaixo. Tal mensagem de rede só pode ser permitida quando o sistema está em um modo de carga de dados, tal como quando a aeronave está em uma fase de voo de embarque. Tal mensagem de rede pode incluir ainda uma função “Carregamento de Dados sem Fio”, uma subfunção “615a”, um fluxo de dados “Dados de Transferência” e um protocolo TFTP. Outros exemplos de possíveis mensagens de rede são mostrados abaixo na Tabela 1.
Tabela 1: Exemplo de Tabela de Fluxo de Rede Funcional Classificada [0055] A Tabela 1 contém possíveis mensagens de rede que podem ser transferidas entre o sistema 110, o sistema 114 e/ou outros sistemas de computador, LRU's e/ou dispositivos em uma plataforma de aviação em rede. Como mostrado na Tabela 1, as mensagens 3 a 12 são associadas a uma ação de Carregamento de dados durante uma fase de voo pré-voo e foram identificadas com uma fimção de carga de dados. Tal ação de carga de dados corresponde a uma carga de dados do LRU do Computador de Manutenção Central (CMC) pelo Sistema de Rede a Bordo (ONS) executado por um Computador portátil de Manutenção sem fio (ML), tal como o Computador portátil de Manutenção 126. Como descrito anteriormente, as funções de carga de dados podem ser ações de manutenção somente são permitidas no modo de manutenção quando a aeronave está no solo, tal como durante a fase de voo de embarque e/ou a fase de voo de taxiamento de decolagem. Em alguns exemplos, uma função de Carregamento de dados sem fio pode incluir operações para trocar arquivos de dados entre alvos carregáveis. Essas operações podem incluir a descoberta de alvos carregáveis disponíveis em uma rede, a consulta de configurações atuais de alvos carregáveis, o carregamento de software novo ou atualizado e arquivos de configuração para alvos carregáveis, o descarregamento de arquivos de dados a partir de alvos carregáveis, etc.
[0056] Uma subfunção da ação Carregamento de dados para mensagens 3 a 5 foi identificada como IEEE 802. lx. O padrão IEEE 802.lx para controle de acesso à rede baseado em porta (PNAC) define o encapsulamento do protocolo de autenticação extensível (EAP) sobre o IEEE 802, também conhecido como EAP sobre LAN (EAPOL). Por exemplo, os fluxos de rede funcionais 3, 4 e 5 incluem subfunções IEEE 802.lx. Como mostrado na Tabela 1, o Fluxo de Dados da mensagem 3 foi identificado como uma Solicitação de Autenticação ML do endereço de origem 4, correspondente ao computador portátil de manutenção (ML) 126, ao endereço de destino 2, correspondente ao Sistema de Rede a Bordo (ONS) 122. O Fluxo de Dados da mensagem de rede 4 foi classificado como uma Concessão de Autorização de ML de ONS 122 a ML 126, para iniciar um Carregamento de dados sem fio. O Fluxo de Dados da mensagem de rede 5 foi identificado como uma carga de dados de CMC de Solicitação por ML por ONS de ML 126 para ONS 122 para uma Porta B adicional em ONS 122.
[0057] Em outros exemplos, a subfunção de uma mensagem de rede para uma função de carga de dados sem fio pode ser o padrão ARINC 615A, que é usado para operações de carregamento de dados em aeronaves sobre vários tipos de redes, tais como Ethernet, Controlador de Área de Rede (CAN) e/ou ARINC 664. Em alguns exemplos, o software que utiliza o padrão 615A pode executar carregamentos, carregamentos em lote, descarregamentos, pesquisa e operações de carregamento de dados de informação para um ou mais alvos. Por exemplo, as mensagens de rede 6 a 12 na Tabela 1 foram identificadas para incluir a subfunção 615A, a função de carregamento de dados. O fluxo de rede funcional 6 inclui um fluxo de dados de solicitação de sessão de estabelecimento, que pode iniciar uma troca de informação interativa entre dispositivos, tais como sistemas 110 e 114, em certos exemplos. A solicitação de sessão de estabelecimento é enviada a partir do endereço de origem 2, correspondente ao ONS 122, ao endereço de destino 3, correspondente ao CMC 124. A mensagem de rede 7 inclui um fluxo de dados de Concessão de Sessão de Estabelecimento CMC 124 ao ONS 122. A mensagem de rede 8 inclui ainda Transferir dados de fluxo de dados, que pode iniciar o descarregamento e/ou o carregamento de dados entre os dispositivos ONS 122 e CMC 124. Em alguns exemplos, tal descarregamento e/ou carregamento podem usar um Protocolo de Transferência de Arquivo Trivial (TFTP) e o protocolo da mensagem de rede 8 é identificado como tal. As mensagens de rede 9, 10 e 11 incluem Transferir Dados de fluxos de dados usando o protocolo TFTP entre o ONS 122 e o CMC 124. Em outros exemplos, podem ser implementados outros protocolos em operações de carregamento de dados sem fio. Por fim, a mensagem de rede 12 inclui uma solicitação de Fechamento de Sessão, que pode terminar a troca de informação interativa entre os dispositivos ONS 122 e CMC 124 depois de os dados terem sido completamente descarregados e/ou carregados entre os dispositivos, em certos exemplos.
[0058] As mensagens 13 e 14 são também identificadas como correspondentes à fase de voo pré-voo e estão associadas a uma ação da impressora. Como mostrado na Tabela 1, as mensagens 13 e 14 e foram identificadas com uma função de Impressão. As mensagens de rede 13 e 14 incluem ainda subfimções identificadas como Solicitação de Impressão, que podem ser correspondentes a uma solicitação para uma impressão do Carregamento de dados estabelecido através de fluxos de rede funcionais 6 a 12, em certos exemplos. A mensagem de rede 13 inclui um fluxo de dados de Estabelecimento de Sessão, que pode iniciar uma troca interativa de informação entre dispositivos, tal como ONS 122 e impressora 130. O Fluxo de rede funcional 13 inclui uma classificação de fluxo de dados de Impressão para Fluxo de dados 002 que pode iniciar a impressão do relatório, na impressora 130.
[0059] Como outro exemplo, a fimção de uma mensagem pode ser uma fimção central de controle de manutenção (CMCF). Como mostrado na Tabela 1, as mensagens de rede 15 a 18 foram identificadas com uma Função CMCF, que pode indicar uma solicitação de relatório de manutenção. Em certos exemplos, uma fimção central de controle de manutenção pode iniciar e/ou receber comunicação com o sistema de manutenção a bordo de uma aeronave, a fim de isolar falhas e orientar ações de manutenção adequadas através de relatórios centralizados de falhas. Em alguns exemplos, um CMCF também pode permitir a consolidação de relatório de falhas, associação de mensagens e correlação de efeito de cabeceira de voo (FDE).
[0060] As mensagens 15 e 16 estão associadas a um relatório de configuração CMC. Como mostrado na Tabela 1, as mensagens de rede 15 e 16 foram identificadas com uma Subfunção de Relatório de Configuração. A mensagem de rede 15 inclui Solicitar Relatório de Fluxo de Dados do CMC 124 para o FMC 120, solicitando um relatório de configuração. Subsequentemente, a mensagem de rede 16 inclui Enviar Relatório de Fluxo de Dados do FMC 120 para CMC 124.
[0061] As mensagens 17 e 18 estão associadas a um relatório de BITE de CITE. Como mostrado na Tabela 1, as mensagens de rede 17 e 18 foram identificadas com uma Sub-Fusão de Relatório BITE. BITE (Equipamento de Teste Incorporado) caracteriza-se principalmente como um gerenciamento de falhas passiva e diagnóstico embutido em sistemas aéreos para suportar o processo de manutenção. O equipamento de teste embutido pode referir-se a multímetros, osciloscópios, sondas de descarga e geradores de frequência que são fornecidos como parte do sistema para permitir o teste e executar diagnósticos. A mensagem de rede 17 inclui uma Solicitação de Relatório do Fluxo de Dados do CMC 124 para o Computador de Gerenciamento de Voo 112, que pode corresponder a uma solicitação para um diagnóstico do FMC 120. Subsequentemente, a mensagem de rede 18 inclui Enviar Relatório de Fluxo de Dados de ONS 122 para CMC 124, fornecendo um relatório de diagnóstico ao CMC 124.
[0062] As mensagens de rede restantes 1, 2 e 19 a 38 são identificadas com uma Função de Dados do Ar de FMC. O FMC, tal como o Computador de Gerenciamento de Voo 120 mostrado na Figura 1B, é um sistema de computador especializado que automatiza uma grande variedade de tarefas durante o voo, reduzindo a carga de trabalho na tripulação de voo. Uma função primária do FMC é gerenciamento em voo do plano de voo. Usando vários sensores, tais como o GPS e um sistema de navegação inercial (INS), muitas vezes apoiado por navegação por rádio, para determinar a posição da aeronave, o FMS pode guiar a aeronave ao longo do plano de voo. Estas mensagens de rede incluem ainda um Fluxo de Dados de Altitude e um Fluxo de Dados de Velocidade do Ar que pode indicar a altitude e a velocidade de ar de uma aeronave, respectivamente. Tais fluxos de dados são enviados a partir do endereço de origem 1, correspondente ao computador de gerenciamento de voo (FMC) 120, a uma fonte de destino 3, correspondente a um CMC 124.
[0063] Na etapa 310, o sistema determina se a mensagem enviada a partir do dispositivo de origem e direcionada para o dispositivo de destino é aceitável quando o sistema está no contexto atual. Através do uso de profundas capacidades de inspeção de pacotes, o sistema pode identificar os dados da mensagem de rede e fazer referência às regras de filtro para determinar se uma determinada entidade (dispositivo de origem) pode tomar uma determinada ação (dados e atributos de mensagens de rede) em uma outra entidade (dispositivo de destino) durante o contexto particular (localização, hora do dia, estado do dispositivo, fase de voo, etc.). Conforme descrito anteriormente, uma entidade pode referir-se a um ou vários dispositivos aviônicos dentro de uma rede de aviação, tal como descrito nas Figuras IA e 1B. Em alguns exemplos, uma entidade pode ser uma coleção de um ou mais desses dispositivos aviônicos. A saída deste processo consciente em contexto pode incluir um rico conjunto de perguntas, tais como: quem tem autoridade (qual (fonte) entidade, restrição de função), que eles estão autorizados a fazer (restrição de ação), de onde podem fazê-lo (restrição de ação), quando eles podem fazê-lo (restrição de tempo), como eles podem fazê-lo (protocolo/restrição de API), e a quem podem fazê-lo (que (destino) entidade). Essas restrições podem ser aplicadas utilizando controles baseados no contexto, cujos resultados podem ser considerados como autorização consistente em contexto. Embora as regras de firewall atuais possam ser reduzidas para saber se um primeiro dispositivo pode se comunicar com um segundo dispositivo usando um determinado protocolo, a filtragem consciente em contexto pode ser descrita como se uma primeira entidade possa tomar uma determinada ação em uma segunda entidade em um contexto específico. Os controles baseados em consistência de contexto fornecem um conjunto muito mais completo de controle que restringe a comunicação entre duas entidades.
[0064] Na etapa 311, a mensagem de rede é encaminhada para o dispositivo de destino se for determinado que a mensagem de rede, que é enviada a partir do dispositivo de origem e direcionada para o dispositivo de destino, é aceitável quando o sistema está no contexto atual. Se a mensagem de rede não for aceitável, a mensagem de rede não será encaminhada para o dispositivo de destino. Na etapa 312, o sistema determina se a mensagem de rede é a mensagem de rede final. Se a mensagem de rede não é a mensagem de rede final transmitida dentro do sistema, é recebida outra mensagem na etapa 301. Se a mensagem de rede é a mensagem de rede final transmitida dentro do sistema, então o método termina na etapa 313.
[0065] A Figura 3B ilustra uma sequência 350 de eventos para executar uma carga de dados sem fio de um Computador de Manutenção Central (CMC) através de um Sistema de Rede A Bordo (ONS) de acordo com um ou mais exemplos. A Figura 3B ilustra o contexto e as etapas de protocolo para usar um computador portátil de manutenção sem fio (ML) 126 para executar uma carga de dados sem fio de um CMC 124 através de um ONS 122. Estas etapas correspondem a mensagens de rede 3 a 12 na Tabela 1. O habilitado na matéria determina que as atividades chave para cada contexto desenvolvam filtro consistente em contexto. Para o exemplo mostrado na Figura 3B, a aeronave está na fase de voo pré-voo. Em outros exemplos, tais etapas podem ser realizadas por um sistema de computador, tal como o computador 102 e/ou o servidor 106.
[0066] Primeiro o ML 126 é autorizado pelo ONS 122 nas etapas 352 a 356. A etapa 352 corresponde à mensagem de rede 3 que é uma Solicitação de Autenticação de ML de ML 126 para ONS 122. A etapa 354 corresponde à mensagem de rede 4 que é uma Concessão de Autenticação de ML do ONS 122 para o ML 126. Na etapa 356, o ML 126 envia então a mensagem 5 correspondente a uma carga de dados do CMC de solicitação por ML pelo ONS, como descrito na Figura 3A.
[0067] Uma vez que o Computador portátil de Manutenção (ML) 126 foi 802.1x autorizado sem fio, uma sessão 615A é estabelecida através das etapas 358 e 360. A Etapa 358 corresponde à mensagem 6 que é um Estabelecimento de Solicitação de Sessão do ONS 122 a CMC 124. A etapa 360 corresponde à mensagem 7 que é um Estabelecimento de Concessão de Sessão do CMC 124 para o ONS 122. A etapa 362 corresponde às mensagens 8, 9 e 10 nas quais os dados são transferidos do ONS 122 para o CMC 124 utilizando um protocolo TFTP. Para cada mensagem, o filtro verifica se as condições acima foram satisfeitas e então pode permitir que a mensagem passe entre os sistemas, tal como na etapa 310 na Figura 3A.
[0068] Fase de voo é apenas um parâmetro que pode ser usado para determinar o contexto de um sistema. Altemativamente, à medida que o sistema realiza uma sequência de operações, cada etapa anterior pode ser usada como contexto para determinar se a mensagem cumpre os requisitos para a etapa seguinte. Para as mensagens de Velocidade do Ar e Altitude (mensagem de rede I,2el9a38), não há nenhuma limitação sobre qual fase de voo a mensagem pode passar, de modo que as regras de filtro para essas mensagens sejam como regras tipo tabela de IP padrão baseadas em Endereço de origem, Endereço de destino, portão e protocolo.
[0069] A Figura 4A, a Figura 4B, a Figura 4C e a Figura 4D ilustram um método adicional 400 para filtrar automaticamente mensagens de rede em uma rede de aviação para uma aeronave com base em um contexto de sistema atual de acordo com um ou mais exemplos. Tal como na etapa 301, uma mensagem de rede 415 é recebida na etapa 401 por um processador de um sistema de computador, tal como o processador 501 descrito adiante. A mensagem de rede 415 é transmitida através de um ou mais pacotes de rede dentro da rede de aviação. A mensagem de rede 415 é transmitida de um dispositivo aviônico de origem para um dispositivo aviônico de destino. Em alguns exemplos, o dispositivo aviônico de origem e/ou o dispositivo aviônico de destino podem compreender vários dispositivos aviônicos diferentes, tais como computadores 102 e 106, ou as várias LRUs dentro do sistema 110 e/ou do sistema 114.
[0070] Na etapa 403, um contexto de sistema atual 419 é estabelecido pelo processador com base no monitoramento de um ou mais dispositivos aviônicos na rede de aviação, tal como na etapa 303. Em alguns exemplos, o contexto de sistema 419 pode indicar o estado agregado 417 de um ou mais dispositivos aviônicos. Em alguns exemplos, o contexto de sistema atual 419 inclui uma combinação de um ou mais dos seguintes: uma data, uma hora, uma localização do dispositivo aviônico de origem, uma localização do dispositivo aviônico de destino, um estado de dispositivo 421 da pluralidade de dispositivos aviônicos e uma fase de voo 423 da aeronave. Em alguns exemplos, o estado do dispositivo 421 da pluralidade de dispositivos aviônicos pode incluir um modo operacional, um modo de manutenção ou um modo de carga de dados. Em alguns exemplos, a fase de voo 423 da aeronave pode incluir um ou mais dos seguintes estados operacionais: ligamento do motor, pré-voo, partida do motor, embarque, taxiamento na decolagem, decolagem, subida inicial, subida, cruzeiro em trânsito, descida, terra de aproximação, apresentação no solo, taxiamento na aterrissagem, volta de pista, e desligamento do motor. Por exemplo, um contexto de sistema atual 419 pode estar em modo operacional em 28 de fevereiro de 2015 às 13 horas com uma aeronave realizando uma subida inicial em uma fase de voo de subida que comunica com o Controlo de Tráfego Aéreo (ATC) no solo. Como descrito anteriormente em conjunto com as Figuras 3A-3B, várias mensagens de rede 415 podem ser permitidas e/ou proibidas durante as várias fases de voo 419.
[0071] Na etapa 405, uma aceitabilidade da mensagem de rede 415 é analisada pelo processador, tal como nas etapas 305, 307, 309 e 310. A aceitabilidade da mensagem de rede 415 é analisada identificando (409) uma pluralidade de atributos 425 correspondentes à mensagem de rede 415. Em alguns exemplos, a pluralidade de atributos 425 correspondentes à mensagem de rede 415 pode incluir um ou mais dos seguintes: um endereço de destino, um endereço de origem, uma fase de voo da mensagem de rede, um estado de dispositivo da mensagem de rede, uma função, uma subfunção, um fluxo de dados e um protocolo. Em alguns exemplos, a pluralidade de atributos 425 corresponde a cabeçalho e campos de dados 427 de um ou mais pacotes de rede correspondentes à mensagem de rede 415. Como previamente descrito na etapa 309, um sistema de computador que executa um programa de firewall, tal como o firewall 112 pode identificar os atributos utilizando a investigação de pacotes profunda ou filtragem de estado.
[0072] A aceitabilidade da mensagem de rede 415 é ainda analisada determinando (411) a aceitabilidade da mensagem de rede 415 dentro do contexto de sistema 419 com base em uma ou mais regras de filtro 429. Uma ou mais regras de filtro 429 especificam quais atributos 425 são permitidos dentro um determinado contexto do sistema. Em vários exemplos, as regras de filtro 429 especificam os atributos permissíveis 425 para vários contextos de sistema, incluindo o contexto de sistema atual 419. Os outros vários contextos de sistemas podem, por sua vez, tomar-se o contexto de sistema atual 419 dependendo de mudanças na data, na hora, na localização do dispositivo aviônico de origem, na localização do dispositivo aviônico de destino, no estado de dispositivo (421) da pluralidade de dispositivos aviônicos, na fase de voo (423) da aeronave e/ou em qualquer outra operação dentro da rede de aviação. Em um exemplo, um contexto de sistema particular pode ser o contexto de sistema atual 419. Em alguns exemplos, uma ou mais regras de filtro 429 pode(m) incluir uma ou mais regras de filtragem de pacotes profunda 431 que impeçam fluxos de dados não autorizados na rede de aviação examinando uma ou mais cargas úteis de um ou mais pacotes em rede, como descrito nas Figuras 3A-3B. Na etapa 407, a mensagem de rede 415 é encaminhada pelo processador para o dispositivo aviônico de destino se a mensagem de rede 415 for determinada como sendo aceitável dentro do contexto de sistema 419, tal como na etapa 311.
[0073] Em alguns exemplos, uma ou mais regras de filtro 429 podem ser geradas automaticamente (433) durante uma fase de teste da rede de aviação. De acordo com vários exemplos, uma ou mais regras de filtro 429 podem ser geradas automaticamente (433) capturando (451) um ou mais pacotes de rede de teste correspondentes a um fluxo de rede funcional de teste transmitido dentro da rede de aviação. Um ou mais pacotes de rede de teste são então analisados (453) para extrair uma ou mais mensagens de rede de teste correspondentes ao fluxo de rede funcional de teste. Uma mensagem de rede de teste de uma ou mais mensagens de rede pode então ser examinada (455) de modo a identificar uma pluralidade de atributos de teste 456. Em alguns exemplos, a pluralidade de atributos de teste 456 pode corresponder a cabeçalho e campos de dados de um ou mais pacotes de rede de teste correspondentes à mensagem de rede de teste. Em alguns exemplos, as mensagens de rede de teste podem ser mensagens de rede 415 e os atributos da mensagem de rede de teste podem ser atributos 425.
[0074] A pluralidade de atributos de teste da mensagem de rede de teste pode então ser classificada (457). Em alguns exemplos, a classificação (457) da pluralidade de atributos de teste pode incluir pesquisar uma ou mais fontes para recuperar atributos previamente classificados correspondentes a fluxos de rede predeterminados. Em alguns exemplos, uma ou mais fontes podem incluir armazenamento local ou bancos de dados globais acessados através de uma rede global. Em alguns exemplos, fluxos de rede funcionais predeterminados podem ter sido previamente classificados por um ou mais usuários. Em alguns exemplos, as classificações predeterminadas podem ser incluídas em um ou mais arquivos de classificação. Em outros exemplos, classificar (457) a pluralidade de atributos de teste pode adicionalmente, ou altemativamente, incluir pedir um usuário para introduzir uma classificação para um ou mais atributos de teste identificados. Em alguns exemplos, pedido a um usuário pode incluir pedir a um usuário para selecionar uma ou mais classificações de uma lista de seleções mais relevantes. Em alguns exemplos, as seleções relevantes podem ser classificadas com base em semelhanças de fluxos de rede e/ou atributos de rede para o fluxo de rede de teste e/ou atributos de teste 456. Exemplos de fluxos de rede classificados são mostrados na Tabela 1.
[0075] Em alguns exemplos, uma ou mais regras de filtro 429 são ainda geradas automaticamente (433) gerando automaticamente (459) uma ou mais tabelas 461 correspondentes a uma ou mais mensagens de rede de teste. Em alguns exemplos, uma ou mais tabelas 461 podem incluir uma ou mais regras de filtro 429. Em outros exemplos, uma ou mais tabelas 461 podem ser encadeadas (463) com base em um ou mais atributos de teste das mensagens de rede de teste. Em alguns exemplos, as tabelas 461 podem ser organizadas pela fase de voo das mensagens de rede de teste. Em alguns exemplos, uma ou mais regras de filtro 429 são então validadas (465). Em alguns exemplos, uma ou mais regras de filtro 429 podem ser validadas comparando-as automaticamente com um arquivo de classificação existente ou outra base de conhecimento.
[0076] Em alguns exemplos, à medida que cada mensagem de rede de teste é classificada (457), é gerada uma regra de filtro 429 para cada mensagem de rede de teste classificada. Em alguns exemplos, as regras de filtro geradas 429 podem ser uma regra de controle de acesso discricionário (DAC). Em alguns exemplos, cada regra DAC é baseada em um fluxo de rede de teste classificado. Em alguns exemplos, as regras do DAC podem ser regras IPtables usadas em tabelas Linux. IPtables pode se referir a um programa de aplicativo de espaço de usuário que permite que um administrador do sistema configure as tabelas fornecidas pelo firewall do kemel do Linux (implementado como diferentes módulos Netfilter) e as cadeias e regras armazenadas. Diferentes módulos e programas do kemel são usados atualmente para diferentes protocolos; Iptables se aplica a IPv4, ipótables para IPv6, arptables para ARP e ebtables para quadros de Ethernet. Em alguns exemplos, outros tipos de regras de filtro podem ser gerados com base nos fluxos de rede classificados, como ipótables, arptables e ebtables.
[0077] Em alguns exemplos, cada fluxo funcional/de dados pode gerar regras de filtro de IP 429 para ambos os filtros de saída e de entrada em uma base por modo. Isso é relevante para regras particulares, como regras de filtro para mensagens de carga de dados (mensagens de rede 3 a 12 na Tabela 1) ou mensagens de Relatório de CMC (mensagens de rede 15 a 18 na Tabela 10, que dependem da fase de voo para indicar o contexto do sistema. Outas mensagens, tais como as mensagens Altitude e Velocidade do Ar (mensagens de rede 1, 2 e 19 a 38 na Tabela 1) são agnósticas para a fase de voo. Em alguns exemplos, estes filtros podem ser suficientemente ricos para endereçar cada fluxo de dados/funcional distintamente. Em alguns exemplos, tais regras de filtro de IP 429 podem ser estendidas para capturar o comportamento de estado encadeando as regras de IPtable simples ou as regras de filtro sem estado. Por exemplo, um diagrama de protocolo de sequência pode ser criado no nível de subfunção, tal como transações 802.lx. Em vários exemplos, as regras de filtro de IP de estado 429 podem estabelecer limites mínimos e máximos para regras que têm um intervalo de valores operacionais, tais como comprimento do pacote, espaço de endereço de IP de Destino/Fonte (DA/SA) de nível bruto, Porta DA/SA, etc. Em alguns exemplos, tais regras 429 podem ser estendidas para um limite mais direcionado uma vez que o comportamento de estado é levado em conta onde regras de IP simples estão encadeadas. Um firewall, tal como o firewall 112, pode usar regras de filtro de estado 429 para rastrear o estado operacional e as características de conexões de rede que o atravessam, e pode ser capaz de manter atributos significativos de cada conexão na memória. Tais atributos podem ser coletivamente conhecidos como o estado da conexão, e podem incluir tais detalhes como os endereços de IP e portas envolvidas no ligamento do motor e os números de sequência dos pacotes que atravessam a conexão. Em alguns exemplos, a inspeção de estado por um firewall pode monitorar pacotes de entrada e de saída ao longo do tempo, bem como o estado da conexão e armazena os dados em tabelas de estado dinâmico. Em alguns exemplos, esses dados acumulativos são avaliados, de modo que as decisões de filtragem não se baseiem somente em regras definidas pelo administrador, mas também no contexto que foi construído por conexões prévias, assim como pacotes anteriores pertencentes à mesma conexão.
[0078] A Figura 5 é um diagrama de blocos que ilustra um exemplo de um sistema 500 capaz de implementar vários processos descritos na presente descrição. Em alguns exemplos, o sistema 500 pode ser um dispositivo cliente, tal como o computador 102 e/ou o computador 106, e um ou mais exemplos podem ser implementados na forma de um meio legível por computador não transitório que armazena um ou mais programas. De acordo com exemplos particulares, um sistema 500, adequado para implementar exemplos particulares da presente descrição, inclui um processador 501, uma memória 503, uma interface 511 e um barramento 515 (por exemplo, um barramento PCI ou outro tecido de interconexão) e opera como um servidor de transferência contínua. Em alguns exemplos, ao atuar sob o controle de um software ou firmware apropriado, o processador 501 é responsável por receber mensagens de rede transmitidas dentro de um sistema de aviação em rede (tal como na etapa 401), determinar um contexto de sistema atual (tal como na etapa 403), analisando a aceitabilidade da mensagem de rede (tal como na etapa 405) e/ou encaminhando uma mensagem de rede aceitável (tal como na etapa 407). Em outros exemplos, o processador 501 pode ser responsável para receber entrada de usuário e pela geração (433) de regras de filtro. Podem também ser usados vários dispositivos especialmente configurados no lugar de um processador 501 ou em adição ao processador 501. Em outros exemplos, o sistema 500 também pode incluir um ou mais dos seguintes elementos: uma bomba, um elemento de temporização, um elemento de aquecimento, um termostato e um detector de concentração.
[0079] A interface 511 é tipicamente configurada para enviar e receber pacotes de dados ou segmentos de dados através de uma rede, tal como a rede 104. Exemplos particulares de suportes de interfaces incluem interfaces Ethernet, interfaces de Frame Relays, interfaces de cabo, interfaces DSL, interfaces de token ring e semelhantes. Além disso, podem ser proporcionadas várias interfaces de alta velocidade, tais como interfaces de Ethernet rápidas, interfaces de Ethernet Gigabit, interfaces ATM, interfaces HSSI, interfaces POS, interfaces FDDI e semelhantes. Geralmente, essas interfaces podem incluir portas apropriadas para comunicação com a mídia apropriada. Em alguns casos, eles também podem incluir um processador independente e, em alguns casos, RAM volátil. Os processadores independentes podem controlar tais tarefas intensivas de comunicações como comutação de pacotes, controle e gerenciamento de mídia.
[0080] De acordo com exemplos particulares, o sistema 500 usa a memória 503 para armazenar dados e instruções de programa para operações incluindo receber mensagens de rede transmitidas dentro de um sistema de aviação em rede (tal como na etapa 401), determinar um contexto de sistema atual (tal como na etapa 403), analisar a aceitabilidade da mensagem de rede (tal como na etapa 405) e/ou encaminhar uma mensagem de rede aceitável (tal como na etapa 407). Em outros exemplos, a memória 503 pode armazenar dados e instruções de programa de operações incluindo receber entrada de usuário e gerar (433) regras de filtro. As instruções do programa podem controlar a operação de um sistema operativo e/ou uma ou mais aplicações, por exemplo. A memória ou as memórias também pode(m) ser configurada(s) para armazenar metadados recebidos e metadados solicitados em lote.
[0081] Além disso, a descrição compreende exemplos de acordo com as seguintes cláusulas: Cláusula 1. Método para filtrar automaticamente mensagens de rede em uma rede de aviação para uma aeronave com base em um contexto de sistema atual, o método compreendendo: receber, por um processador de um sistema de computador, uma mensagem de rede transmitida através de um ou mais pacotes de rede dentro da rede de aviação, em que a mensagem de rede é transmitida de um dispositivo aviônico de origem para um dispositivo aviônico de destino; estabelecer, pelo processador, um contexto de sistema atual baseado na monitoração de um ou mais dispositivos aviônicos na rede de aviação, em que o contexto do sistema indica um estado agregado do um ou mais dispositivos aviônicos; analisar, pelo processador, uma aceitabilidade da mensagem de rede por: identificação de uma pluralidade de atributos correspondentes à mensagem de rede, em que a pluralidade de atributos corresponde a cabeçalho e campos de dados de um ou mais pacotes de rede correspondentes à mensagem de rede; e determinar a aceitabilidade da mensagem de rede dentro do contexto do sistema com base em uma ou mais regras de filtro, em que uma ou mais regras de filtro especificam quais atributos são permitidos dentro de um contexto de sistema particular; e encaminhar, pelo processador, a mensagem de rede para o dispositivo aviônico de destino se a mensagem de rede for determinada como aceitável dentro do contexto do sistema.
Cláusula 2. Método da cláusula 1, em que o contexto do sistema atual inclui uma combinação de um ou mais dos seguintes: uma data, uma hora, uma localização do dispositivo aviônico de origem, uma localização do dispositivo aviônico de destino, um estado de dispositivo da pluralidade de dispositivos aviônicos, e uma fase de voo da aeronave.
Cláusula 3. Método da cláusula 2, em que o estado do dispositivo da pluralidade de dispositivos aviônicos inclui um modo operacional, um modo de manutenção ou um modo de carga de dados.
Cláusula 4. Método da cláusula 2, em que a fase de voo da aeronave inclui um dos seguintes estados operacionais: ligamento do motor, pré-voo, partida do motor, embarque, taxiamento na decolagem, decolagem, subida inicial, subida, cruzeiro em trânsito, descida, terra de aproximação, apresentação no solo, taxiamento na aterrissagem, volta de pista, e desligamento do motor.
Cláusula 5. Método da cláusula 1, em que a pluralidade de atributos que correspondem à mensagem de rede inclui um ou mais dos seguintes: um endereço de destino, um endereço de origem, uma fase de voo da mensagem de rede, um estado de dispositivo da mensagem de rede, uma função, uma subfunção, um fluxo de dados e um protocolo.
Cláusula 6. Método da cláusula 1, em que uma ou mais regras de filtro são geradas automaticamente durante uma fase de teste da rede de aviação por: capturar um ou mais pacotes de rede de teste correspondentes a um fluxo de rede funcional de teste transmitido dentro da rede de aviação; analisar um ou mais pacotes de rede de teste para extrair uma ou mais mensagens de rede de teste correspondentes ao fluxo de rede funcional de teste; examinar uma mensagem de rede de teste de uma ou mais mensagens de rede de teste para identificar uma pluralidade de atributos de teste, em que a pluralidade de atributos de teste corresponde a cabeçalho e campos de dados de um ou mais pacotes de rede de teste correspondentes à mensagem de rede de teste; classificar a pluralidade de atributos de teste da mensagem de rede de teste; gerar automaticamente uma ou mais tabelas correspondentes a uma ou mais mensagens de rede de teste, em que uma ou mais tabelas incluem uma ou mais regras de filtro; em que uma ou mais tabelas são encadeadas com base em um ou mais atributos de teste das mensagens de rede de teste e validar a uma ou mais regras de filtro.
Cláusula 7. Método da cláusula 1, em que uma ou mais regras de filtro incluem uma ou mais regras de filtragem de pacotes profunda, em que uma ou mais regras de filtragem de pacotes profunda impedem fluxos de dados não autorizados na rede de aviação examinando uma ou mais cargas úteis de um ou mais pacotes de rede.
Cláusula 8. Sistema para filtrar automaticamente mensagens de rede em uma rede de aviação para uma aeronave, o sistema compreendendo: um ou mais processadores; memória; e um ou mais programas armazenados na memória, um ou mais programas incluindo instruções para: receber, por um ou mais processadores, uma mensagem de rede transmitida através de um ou mais pacotes de rede dentro da rede de aviação, em que a mensagem de rede é transmitida de um dispositivo aviônico de origem para um dispositivo aviônico de destino; estabelecer, por um ou mais processadores, um contexto de sistema atual com base no monitoramento de um ou mais dispositivos aviônicos na rede de aviação, em que o contexto do sistema indica um estado agregado de um ou mais dispositivos aviônicos; analisar, por um ou mais processadores, uma aceitabilidade da mensagem de rede por: identificar uma pluralidade de atributos correspondentes à mensagem de rede, em que a pluralidade de atributos corresponde a cabeçalho e campos de dados de um ou mais pacotes de rede correspondentes à rede mensagem de rede; e determinar a aceitabilidade da mensagem de rede dentro do contexto do sistema com base em uma ou mais regras de filtro, em que uma ou mais regras de filtro especificam quais atributos são permitidos dentro de um contexto de sistema particular; e encaminhar, por um ou mais processadores, a mensagem de rede para o dispositivo aviônico de destino se a mensagem de rede for determinada como aceitável dentro do contexto do sistema.
Cláusula 9. Sistema de acordo com a reivindicação 8, caracterizado pelo fato de que o contexto do sistema inclui uma combinação de um ou mais dos seguintes: uma data, uma hora, uma localização do dispositivo aviônico de origem, uma localização do dispositivo aviônico de destino, um estado de dispositivo da pluralidade de dispositivos aviônicos e uma fase de voo da aeronave.
Cláusula 10. Sistema da cláusula 9, em que o estado do dispositivo da pluralidade de dispositivos aviônicos inclui um modo operacional, um modo de manutenção ou um modo de carga de dados.
Cláusula 11. Sistema da cláusula 9, em que a fase de voo da aeronave inclui um dos seguintes estados operacionais: ligamento do motor, pré-voo, partida do motor, embarque, taxiamento na decolagem, decolagem, subida inicial, subida, cruzeiro em trânsito, descida, terra de aproximação, apresentação no solo, taxiamento na aterrissagem, volta de pista, e desligamento do motor.
Cláusula 12. Sistema da cláusula 8, em que a pluralidade de atributos correspondente à mensagem de rede inclui um ou mais dos seguintes: um endereço de destino, um endereço de origem, uma fase de voo da mensagem de rede, um estado de dispositivo da mensagem de rede, uma função, uma subfunção, um fluxo de dados e um protocolo.
Cláusula 13. Sistema da cláusula 8, em que uma ou mais regras de filtro são geradas automaticamente durante uma fase de teste da rede de aviação por: capturar ou mais pacotes de rede de teste correspondentes a um fluxo de rede funcional de teste transmitido dentro da rede de aviação; analisar um ou mais pacotes de rede de teste para extrair uma ou mais mensagens de rede de teste correspondentes ao fluxo de rede funcional de teste; examinar uma mensagem de rede de teste de uma ou mais mensagens de rede de teste para identificar uma pluralidade de atributos de teste, em que a pluralidade de atributos de teste corresponde a cabeçalho e campos de dados de um ou mais pacotes de rede de teste correspondentes à mensagem de rede de teste; classificar a pluralidade de atributos de teste da mensagem de rede de teste; gerar automaticamente uma ou mais tabelas correspondentes a uma ou mais mensagens de rede de teste; em que uma ou mais tabelas incluem uma ou mais regras de filtro; em que uma ou mais tabelas são encadeadas com base em um ou mais atributos de teste das mensagens de rede de teste; validar uma ou mais regras de filtro.
Cláusula 14. Sistema da cláusula 8, em que uma ou mais regras de filtro incluem uma ou mais regras de filtragem de pacotes profunda, em que uma ou mais regras de filtragem de pacotes profunda impedem fluxos de dados não autorizados na rede de aviação examinando uma ou mais cargas úteis de um ou mais pacotes de rede.
Cláusula 15. Meio legível por computador não transitório compreendendo um ou mais programas configurados para execução por um sistema de computador, um ou mais programas incluindo instruções para: receber, por um processador de um sistema de computador, uma mensagem de rede transmitida através de um ou mais pacotes de rede dentro de uma rede de aviação para uma aeronave, em que a mensagem de rede é transmitida de um dispositivo aviônico de origem para um dispositivo aviônico de destino; estabelecer, pelo processador, um contexto de sistema atual baseado na monitoração de um ou mais dispositivos aviônicos na rede de aviação, em que o contexto do sistema indica um estado agregado de um ou mais dispositivos aviônicos; analisar, pelo processador, uma aceitabilidade da mensagem de rede por: identificar uma pluralidade de atributos correspondentes à mensagem de rede, em que a pluralidade de atributos corresponde a cabeçalho e campos de dados de um ou mais pacotes de rede correspondentes à mensagem de rede; e determinar a aceitabilidade da mensagem de rede dentro do contexto do sistema com base em uma ou mais regras de filtro, em que uma ou mais regras de filtro especificam quais atributos são permitidos dentro de um contexto de sistema particular; e encaminhar, pelo processador, a mensagem de rede para o dispositivo aviônico de destino se a mensagem de rede for determinada como aceitável dentro do contexto do sistema.
Cláusula 16. Meio legível por computador não transitório da cláusula 15, em que o contexto do sistema atual inclui uma combinação de um ou mais dos seguintes: uma data, uma hora, uma localização do dispositivo aviônico de origem, uma localização do dispositivo aviônico de destino, um estado do dispositivo da pluralidade de dispositivos e uma fase de voo da aeronave.
Cláusula 17. Meio legível por computador não transitório da cláusula 16, em que o estado do dispositivo da pluralidade de dispositivos aviônicos inclui um modo operacional, um modo de manutenção ou um modo de carga de dados.
Cláusula 18. Meio legível por computador não transitório da cláusula 16, em que a fase de voo da aeronave inclui um dos seguintes estados operacionais: ligamento do motor, pré-voo, partida do motor, embarque, taxiamento na decolagem, subida inicial, subida, cruzeiro em trânsito, descida, terra de aproximação, apresentação no solo, taxiamento na aterrisagem, volta de pista, e desligamento do motor.
Cláusula 19. Meio legível por computador não transitório da cláusula 15, em que a pluralidade de atributos correspondente à mensagem de rede inclui um ou mais dos seguintes: um endereço de destino, um endereço de origem, uma fase de voo da mensagem de rede, um estado de dispositivo da mensagem de rede, uma função, uma subfunção, um fluxo de dados e um protocolo.
Cláusula 20. Meio legível por computador não transitório da cláusula 15, em que a uma ou mais regras de filtro incluem uma ou mais regras de filtragem de pacotes profunda, em que uma ou mais regras de filtragem de pacotes profunda impedem fluxos de dados não autorizados no sistema de aviação em rede examinando as cargas úteis de um ou mais pacotes de rede.
[0082] Devido a tais informações e instruções de programa poderem ser empregadas para implementar os sistemas/métodos aqui descritos, a presente descrição refere-se a mídia legível por máquina, tangível, ou não transitória, que incluem instruções de programas, informações de estado, etc. para executar várias operações aqui descritas. Exemplos de meios legíveis por máquina incluem discos rígidos, disquetes, fita magnética, meios ópticos tais como discos de CD-ROM e DVDs; meios magneto-ópticos tais como discos ópticos e dispositivos de hardware que são especialmente configurados para armazenar e executar instruções de programa, tais como dispositivos de memória somente de leitura (ROM) e dispositivos de memória somente de leitura programáveis (PROMs). Exemplos de instruções de programa incluem código de máquina, como produzido por um compilador, e arquivos contendo código de nível superior que pode ser executado pelo computador usando um interpretador.
[0083] Embora a presente descrição tenha sido particularmente mostrada e descrita com referência a exemplos específicos dos mesmos, será entendido pelos habilitados na técnica que as alterações na forma e nos detalhes dos exemplos descritos podem ser feitas sem afastamento do espírito ou escopo da presente descrição. Por conseguinte, pretende-se que a presente descrição seja interpretada de modo a incluir todas as variações e equivalentes que estejam dentro do verdadeiro espírito e escopo da presente descrição. Embora muitos dos componentes e processos sejam descritos acima no singular por conveniência, será apreciado por um habilitado na técnica que múltiplos componentes e processos repetidos podem também ser usados para praticar as técnicas da presente descrição.
REIVINDICAÇÕES
Claims (14)
1. Método para filtrar automaticamente mensagens de rede em uma rede de aviação para uma aeronave com base em um contexto de sistema atual, o método caracterizado pelo fato de compreender: receber (401), por um processador (501) de um sistema de computador (500), uma mensagem de rede (415) transmitida através de um ou mais pacotes de rede dentro da rede de aviação, em que a mensagem de rede é transmitida de um dispositivo aviônico de origem para um dispositivo aviônico de destino; estabelecer (403), pelo processador, um contexto de sistema atual (419) baseado na monitoração de um ou mais dispositivos aviônicos na rede de aviação, em que o contexto do sistema indica um estado agregado (417) do um ou mais dispositivos aviônicos; analisar (405), pelo processador, uma aceitabilidade da mensagem de rede por: identificar (409) uma pluralidade de atributos (425) correspondentes à mensagem de rede, em que a pluralidade de atributos corresponde a cabeçalho e campos de dados (427) de um ou mais pacotes de rede correspondentes à mensagem de rede; e determinar (411) a aceitabilidade da mensagem de rede dentro do contexto do sistema com base em uma ou mais regras de filtro (429), em que uma ou mais regras de filtro especificam quais atributos são permitidos dentro de um contexto de sistema particular; e encaminhar (407), pelo processador, a mensagem de rede para o dispositivo aviônico de destino se a mensagem de rede for determinada como aceitável dentro do contexto do sistema.
2. Método de acordo com a reivindicação 1, caracterizado pelo fato de que o contexto do sistema atual (419) inclui uma combinação de um ou mais dos seguintes: uma data, uma hora, uma localização do dispositivo aviônico de origem, uma localização do dispositivo aviônico de destino, um estado de dispositivo (421) da pluralidade de dispositivos aviônicos, e uma fase de voo (423) da aeronave.
3. Método de acordo com a reivindicação 2, caracterizado pelo fato de que o estado do dispositivo (421) da pluralidade de dispositivos aviônicos inclui um modo operacional, um modo de manutenção ou um modo de carga de dados.
4. Método de acordo com a reivindicação 2, caracterizado pelo fato de que a fase de voo (423) da aeronave inclui um dos seguintes estados operacionais: ligamento do motor, pré-voo, partida do motor, embarque, taxiamento na decolagem, decolagem, subida inicial, subida, cruzeiro em trânsito, descida, terra de aproximação, apresentação no solo, taxiamento na aterrissagem, volta de pista, e desligamento do motor.
5. Método de acordo com a reivindicação 1, caracterizado pelo fato de que a pluralidade de atributos (425) que correspondem à mensagem de rede (415) inclui um ou mais dos seguintes: um endereço de destino, um endereço de origem, uma fase de voo da mensagem de rede, um estado de dispositivo da mensagem de rede, uma função, uma subfunção, um fluxo de dados e um protocolo.
6. Método de acordo com a reivindicação 1, caracterizado pelo fato de que uma ou mais regras de filtro (429) são geradas automaticamente (433) durante uma fase de teste da rede de aviação por: capturar (451) um ou mais pacotes de rede de teste correspondentes a um fluxo de rede funcional de teste transmitido dentro da rede de aviação; analisar (453) um ou mais pacotes de rede de teste para extrair uma ou mais mensagens de rede de teste correspondentes ao fluxo de rede funcional de teste; examinar (455) uma mensagem de rede de teste de uma ou mais mensagens de rede de teste para identificar uma pluralidade de atributos de teste (456), em que a pluralidade de atributos de teste corresponde a cabeçalho e campos de dados de um ou mais pacotes de rede de teste correspondentes à mensagem de rede de teste; classificar (457) a pluralidade de atributos de teste da mensagem de rede de teste; gerar (459) automaticamente uma ou mais tabelas (461) correspondentes a uma ou mais mensagens de rede de teste, em que uma ou mais tabelas incluem uma ou mais regras de filtro; em que uma ou mais tabelas são encadeadas (463) com base em um ou mais atributos de teste das mensagens de rede de teste e validar (465) a uma ou mais regras de filtro.
7. Método de acordo com a reivindicação 1, caracterizado pelo fato de que uma ou mais regras de filtro (429) incluem uma ou mais regras de filtragem de pacotes profunda (431), em que uma ou mais regras de filtragem de pacotes profunda impedem fluxos de dados não autorizados na rede de aviação examinando uma ou mais cargas úteis de um ou mais pacotes de rede.
8. Sistema para filtrar automaticamente mensagens de rede em uma rede de aviação para uma aeronave, o sistema caracterizado pelo fato de compreender: um ou mais processadores (501); memória (503); e um ou mais programas armazenados na memória, um ou mais programas incluindo instruções para: receber (401), por um ou mais processadores, uma mensagem de rede (415) transmitida através de um ou mais pacotes de rede dentro da rede de aviação, em que a mensagem de rede é transmitida de um dispositivo aviônico de origem para um dispositivo aviônico de destino; estabelecer (403), por um ou mais processadores, um contexto de sistema atual (419) com base no monitoramento de um ou mais dispositivos aviônicos na rede de aviação, em que o contexto do sistema indica um estado agregado (417) de um ou mais dispositivos aviônicos; analisar (405), por um ou mais processadores, uma aceitabilidade da mensagem de rede por: identificar (409) uma pluralidade de atributos (425) correspondentes à mensagem de rede, em que a pluralidade de atributos corresponde a cabeçalho e campos de dados (427) de um ou mais pacotes de rede correspondentes à rede mensagem de rede; e determinar (411) a aceitabilidade da mensagem de rede dentro do contexto do sistema com base em uma ou mais regras de filtro (429), em que uma ou mais regras de filtro especificam quais atributos são permitidos dentro de um contexto de sistema particular; e encaminhar (407), por um ou mais processadores, a mensagem de rede para o dispositivo aviônico de destino se a mensagem de rede for determinada como aceitável dentro do contexto do sistema.
9. Sistema de acordo com a reivindicação 8, caracterizado pelo fato de que o contexto do sistema (419) inclui uma combinação de um ou mais dos seguintes: uma data, uma hora, uma localização do dispositivo aviônico de origem, uma localização do dispositivo aviônico de destino, um estado de dispositivo (421) da pluralidade de dispositivos aviônicos e uma fase de voo (423) da aeronave.
10. Sistema de acordo com a reivindicação 9, caracterizado pelo fato de que o estado do dispositivo (421) da pluralidade de dispositivos aviônicos inclui um modo operacional, um modo de manutenção ou um modo de carga de dados.
11. Sistema de acordo com a reivindicação 9, caracterizado pelo fato de que a fase de voo (423) da aeronave inclui um dos seguintes estados operacionais: ligamento do motor, pré-voo, partida do motor, embarque, taxiamento na decolagem, decolagem, subida inicial, subida, cruzeiro em trânsito, descida, terra de aproximação, apresentação no solo, taxiamento na aterrissagem, volta de pista, e desligamento do motor.
12. Sistema de acordo com a reivindicação 8, caracterizado pelo fato de que a pluralidade de atributos (425) correspondente à mensagem de rede (415) inclui um ou mais dos seguintes: um endereço de destino, um endereço de origem, uma fase de voo da mensagem de rede, um estado de dispositivo da mensagem de rede, uma função, uma subfunção, um fluxo de dados e um protocolo.
13. Sistema de acordo com a reivindicação 8, caracterizado pelo fato de que uma ou mais regras de filtro (429) são geradas automaticamente (451) durante uma fase de teste da rede de aviação por: capturar ou mais pacotes de rede de teste correspondentes a um fluxo de rede funcional de teste transmitido dentro da rede de aviação; analisar (453) um ou mais pacotes de rede de teste para extrair uma ou mais mensagens de rede de teste correspondentes ao fluxo de rede funcional de teste; examinar (455) uma mensagem de rede de teste de uma ou mais mensagens de rede de teste para identificar uma pluralidade de atributos de teste (456), em que a pluralidade de atributos de teste corresponde a cabeçalho e campos de dados de um ou mais pacotes de rede de teste correspondentes à mensagem de rede de teste; classificar (457) a pluralidade de atributos de teste da mensagem de rede de teste; gerar automaticamente (459) uma ou mais tabelas (461) correspondentes a uma ou mais mensagens de rede de teste; em que uma ou mais tabelas incluem uma ou mais regras de filtro; em que uma ou mais tabelas são encadeadas (463) com base em um ou mais atributos de teste das mensagens de rede de teste; validar (465) uma ou mais regras de filtro.
14. Sistema de acordo com a reivindicação 8, caracterizado pelo fato de que uma ou mais regras de filtro (429) incluem uma ou mais regras de filtragem de pacotes profunda (431), em que uma ou mais regras de filtragem de pacotes profunda impedem fluxos de dados não autorizados na rede de aviação examinando uma ou mais cargas úteis de um ou mais pacotes de rede.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US15/095,973 US10063435B2 (en) | 2016-04-11 | 2016-04-11 | System and method for context aware network filtering |
| US15/095973 | 2016-04-11 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| BR102017003799A2 true BR102017003799A2 (pt) | 2017-10-17 |
Family
ID=58692296
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| BR102017003799-1A BR102017003799A2 (pt) | 2016-04-11 | 2017-02-23 | Method and system for automatically filtering network messages in an aviation network for an aircraft. |
Country Status (10)
| Country | Link |
|---|---|
| US (2) | US10063435B2 (pt) |
| EP (1) | EP3232639B1 (pt) |
| JP (1) | JP6937154B2 (pt) |
| KR (1) | KR20170116571A (pt) |
| CN (1) | CN107294949B (pt) |
| AU (1) | AU2017200333B2 (pt) |
| BR (1) | BR102017003799A2 (pt) |
| CA (1) | CA2955737C (pt) |
| RU (1) | RU2722366C2 (pt) |
| SG (1) | SG10201702996UA (pt) |
Families Citing this family (31)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10652253B2 (en) | 2013-03-15 | 2020-05-12 | CyberSecure IPS, LLC | Cable assembly having jacket channels for LEDs |
| WO2014145539A2 (en) * | 2013-03-15 | 2014-09-18 | Stephen Sohn | Method and system for protective distribution system (pds) and infrastructure protection and management |
| US10721259B2 (en) * | 2016-03-31 | 2020-07-21 | The Boeing Company | System and method for automatic generation of filter rules |
| US10063435B2 (en) | 2016-04-11 | 2018-08-28 | The Boeing Company | System and method for context aware network filtering |
| US10819418B2 (en) * | 2016-04-29 | 2020-10-27 | Honeywell International Inc. | Systems and methods for secure communications over broadband datalinks |
| US10819601B2 (en) * | 2016-06-30 | 2020-10-27 | Ge Aviation Systems Llc | Wireless control unit server for conducting connectivity test |
| US20180002040A1 (en) * | 2016-06-30 | 2018-01-04 | Ge Aviation Systems Llc | Data load connectivity test for wireless communication unit for communicating engine data |
| FR3058290B1 (fr) * | 2016-10-27 | 2019-08-02 | Thales | Equipement avionique avec signature a usage unique d'un message emis, systeme avionique, procede de transmission et programme d'ordinateur associes |
| US10320749B2 (en) * | 2016-11-07 | 2019-06-11 | Nicira, Inc. | Firewall rule creation in a virtualized computing environment |
| US10623903B2 (en) * | 2017-05-10 | 2020-04-14 | Sr Technologies, Inc. | Temporal location of mobile WLAN stations using airborne station |
| GB2563894A (en) * | 2017-06-29 | 2019-01-02 | Airbus Operations Ltd | Data centric messaging |
| US20190031373A1 (en) * | 2017-07-28 | 2019-01-31 | Honeywell International Inc. | System and method for testing the functionality of an electronic flight bag |
| CN108280582A (zh) * | 2018-01-26 | 2018-07-13 | 中远网络物流信息科技有限公司 | 一种全程供应链控制塔及控制方法 |
| US10764749B2 (en) * | 2018-03-27 | 2020-09-01 | Honeywell International Inc. | System and method for enabling external device connectivity to avionics systems |
| US11758500B2 (en) | 2018-04-05 | 2023-09-12 | Telefonaktiebolaget Lm Ericsson (Publ) | Methods for controlling unauthorized aerial UEs |
| US10607496B2 (en) * | 2018-04-10 | 2020-03-31 | Honeywell International Inc. | System and method to assist pilots in determining aircraft phase transition time based on monitored clearance information |
| US10715511B2 (en) | 2018-05-03 | 2020-07-14 | Honeywell International Inc. | Systems and methods for a secure subscription based vehicle data service |
| US10819689B2 (en) | 2018-05-03 | 2020-10-27 | Honeywell International Inc. | Systems and methods for encrypted vehicle data service exchanges |
| US11134057B2 (en) * | 2018-08-27 | 2021-09-28 | The Boeing Company | Systems and methods for context-aware network message filtering |
| EP3627788A1 (de) * | 2018-09-18 | 2020-03-25 | Siemens Aktiengesellschaft | Verfahren und vorrichtung zum konfigurieren eines zugangsschutzsystems |
| US11743226B2 (en) * | 2018-09-21 | 2023-08-29 | Honeywell International Inc. | Communication system processing external clearance message functions |
| CN109067605B (zh) * | 2018-10-08 | 2021-10-22 | 郑州云海信息技术有限公司 | 一种存储子系统故障诊断方法、装置、终端及存储介质 |
| US11063954B2 (en) * | 2019-01-11 | 2021-07-13 | Panasonic Avionics Corporation | Networking methods and systems for transportation vehicle entertainment systems |
| US11908336B2 (en) | 2019-11-04 | 2024-02-20 | The Boeing Company | System and method for clearance-based taxi route planning |
| EP3848832B1 (de) * | 2020-01-08 | 2024-05-08 | Rohde & Schwarz GmbH & Co. KG | Flugverkehrskontrollsystem sowie verfahren zur überwachung eines flugverkehrskontrollnetzwerks |
| US11948466B2 (en) * | 2020-09-28 | 2024-04-02 | Rockwell Collins, Inc. | Mission reasoner system and method |
| CN112735188B (zh) * | 2020-11-26 | 2022-03-25 | 南京航空航天大学 | 基于复杂网络理论的空中交通网络脆弱性分析系统 |
| CN112530206B (zh) * | 2020-11-26 | 2022-03-11 | 南京航空航天大学 | 空中交通网络脆弱性分析方法 |
| US11975863B2 (en) * | 2021-04-30 | 2024-05-07 | Rtx Corporation | Gas turbine engine communication data management function communicating via aircraft wireless gateway |
| US20230176956A1 (en) * | 2021-12-08 | 2023-06-08 | Hcl Technologies Limited | Method and system for performing dataload protocol operation testing in an avionics unit |
| EP4345420A1 (en) * | 2022-09-29 | 2024-04-03 | Honeywell International Inc. | Systems and methods for high integrity domain-specific data broker engine in vehicle data gateway |
Family Cites Families (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7013482B1 (en) | 2000-07-07 | 2006-03-14 | 802 Systems Llc | Methods for packet filtering including packet invalidation if packet validity determination not timely made |
| JP2002176430A (ja) * | 2000-12-06 | 2002-06-21 | Auto Network Gijutsu Kenkyusho:Kk | 車両用通信制御装置 |
| US7715819B2 (en) * | 2001-08-03 | 2010-05-11 | The Boeing Company | Airborne security manager |
| US7249162B2 (en) * | 2003-02-25 | 2007-07-24 | Microsoft Corporation | Adaptive junk message filtering system |
| US7408932B2 (en) * | 2003-10-20 | 2008-08-05 | Intel Corporation | Method and apparatus for two-stage packet classification using most specific filter matching and transport level sharing |
| FR2879388B1 (fr) | 2004-12-15 | 2007-03-16 | Sagem | Procede de transmission securisee, systeme, pare-feu et routeur le mettant en oeuvre |
| US7779458B1 (en) | 2005-09-20 | 2010-08-17 | Rockwell Collins, Inc. | Situation aware mobile location ad hoc firewall |
| JP2008193602A (ja) * | 2007-02-07 | 2008-08-21 | Tamura Seisakusho Co Ltd | 無線通信制御装置、その制御方法及びプログラム |
| FR2917206B1 (fr) * | 2007-06-06 | 2009-12-25 | Airbus France | Systeme embarque de controle d'acces pour une communication du domaine ouvert vers le domaine avionique. |
| FR2922705B1 (fr) * | 2007-10-23 | 2011-12-09 | Sagem Defense Securite | Passerelle bidirectionnelle a niveau de securite renforce |
| EP2441229B1 (en) | 2009-06-11 | 2020-05-06 | Panasonic Avionics Corporation | System and method for providing security aboard a moving platform |
| FR2952257B1 (fr) | 2009-11-05 | 2011-11-11 | Airbus Operations Sas | Procede et dispositif de configuration d'un systeme d'information de maintenance embarque dans un aeronef |
| CN101834751B (zh) * | 2010-03-19 | 2012-10-10 | 北京经纬恒润科技有限公司 | 航空全双工交换以太网监测处理系统及方法 |
| US8762990B2 (en) * | 2011-07-25 | 2014-06-24 | The Boeing Company | Virtual machines for aircraft network data processing systems |
| WO2013144962A1 (en) * | 2012-03-29 | 2013-10-03 | Arilou Information Security Technologies Ltd. | Security system and method for protecting a vehicle electronic system |
| US9003052B2 (en) * | 2012-07-09 | 2015-04-07 | The Boeing Company | System and method for air-to-ground data streaming |
| US8788731B2 (en) * | 2012-07-30 | 2014-07-22 | GM Global Technology Operations LLC | Vehicle message filter |
| TWI515600B (zh) * | 2013-10-25 | 2016-01-01 | 緯創資通股份有限公司 | 惡意程式防護方法與系統及其過濾表格更新方法 |
| FR3013880B1 (fr) * | 2013-11-26 | 2017-03-31 | Airbus Operations Sas | Systeme avionique, notamment un systeme de gestion de vol d'un aeronef |
| EP2916511B1 (en) * | 2014-03-07 | 2020-02-12 | Airbus Opérations SAS | High assurance security gateway interconnecting different domains |
| US10523521B2 (en) * | 2014-04-15 | 2019-12-31 | Splunk Inc. | Managing ephemeral event streams generated from captured network data |
| US9413783B1 (en) * | 2014-06-02 | 2016-08-09 | Amazon Technologies, Inc. | Network interface with on-board packet processing |
| US10063435B2 (en) | 2016-04-11 | 2018-08-28 | The Boeing Company | System and method for context aware network filtering |
-
2016
- 2016-04-11 US US15/095,973 patent/US10063435B2/en active Active
-
2017
- 2017-01-18 AU AU2017200333A patent/AU2017200333B2/en active Active
- 2017-01-20 CA CA2955737A patent/CA2955737C/en active Active
- 2017-01-23 RU RU2017102041A patent/RU2722366C2/ru active
- 2017-02-23 BR BR102017003799-1A patent/BR102017003799A2/pt not_active Application Discontinuation
- 2017-02-27 KR KR1020170025268A patent/KR20170116571A/ko active IP Right Grant
- 2017-03-27 CN CN201710187421.3A patent/CN107294949B/zh active Active
- 2017-04-04 JP JP2017074455A patent/JP6937154B2/ja active Active
- 2017-04-10 EP EP17165846.1A patent/EP3232639B1/en active Active
- 2017-04-11 SG SG10201702996UA patent/SG10201702996UA/en unknown
-
2018
- 2018-08-03 US US16/054,924 patent/US10938689B2/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| RU2722366C2 (ru) | 2020-05-29 |
| KR20170116571A (ko) | 2017-10-19 |
| US10938689B2 (en) | 2021-03-02 |
| AU2017200333A1 (en) | 2017-10-26 |
| CA2955737C (en) | 2021-05-18 |
| CN107294949A (zh) | 2017-10-24 |
| EP3232639A1 (en) | 2017-10-18 |
| US20180375747A1 (en) | 2018-12-27 |
| JP2017216673A (ja) | 2017-12-07 |
| CA2955737A1 (en) | 2017-10-11 |
| EP3232639B1 (en) | 2019-09-11 |
| SG10201702996UA (en) | 2017-11-29 |
| CN107294949B (zh) | 2021-09-10 |
| US20170295031A1 (en) | 2017-10-12 |
| US10063435B2 (en) | 2018-08-28 |
| RU2017102041A (ru) | 2018-07-27 |
| RU2017102041A3 (pt) | 2020-03-26 |
| JP6937154B2 (ja) | 2021-09-22 |
| AU2017200333B2 (en) | 2021-11-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| BR102017003799A2 (pt) | Method and system for automatically filtering network messages in an aviation network for an aircraft. | |
| EP3226479B1 (en) | System and method for automatic generation of filter rules | |
| US11716334B2 (en) | Transport communication management | |
| US11134057B2 (en) | Systems and methods for context-aware network message filtering | |
| EP3598421B1 (en) | Systems and method for wirelessly and securely updating a terrain awareness warning system database | |
| EP3101643B1 (en) | Systems and methods for creating a network cloud based system for supporting regional, national and international unmanned aircraft systems | |
| US20170255902A1 (en) | Vehicle identification and interception | |
| Ramaker et al. | Application of a civil integrated modular architecture to military transport aircraft | |
| JP7255954B2 (ja) | 分別発注管理のための移動接続プロビジョニング | |
| Kuenz | City-ATM–Live Drone Trials with Dynamic Geo-fencing | |
| US20220309930A1 (en) | Device for assisting in the piloting of aircraft | |
| US11257379B2 (en) | Emulating a vehicle-communications-center data request to obtain data from a system or subsystem onboard the vehicle | |
| Baron Garcia | Machine Learning and Artificial Intelligence Methods for Cybersecurity Data within the Aviation Ecosystem |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| B03A | Publication of a patent application or of a certificate of addition of invention [chapter 3.1 patent gazette] | ||
| B06W | Patent application suspended after preliminary examination (for patents with searches from other patent authorities) chapter 6.23 patent gazette] | ||
| B07A | Application suspended after technical examination (opinion) [chapter 7.1 patent gazette] | ||
| B09B | Patent application refused [chapter 9.2 patent gazette] | ||
| B12B | Appeal against refusal [chapter 12.2 patent gazette] |