Diferentes tipos de software
Precisamos distinguir entre várias categorias de software.
O software carregável em campo (FLS) é, vagamente definido, qualquer software que possa ser reconfigurado, atualizado ou carregado por técnicos e fabricantes, como o software aviônico.
Os bancos de dados aeronáuticos não são categorizados como software carregável em campo e são tratados separadamente nos regulamentos. Esses bancos de dados aeronáuticos podem ser um banco de dados de terrenos, um banco de dados de navegação, um banco de dados de obstáculos ou um banco de dados de mapas de aeroportos.
Software carregado de fábrica, que supostamente não muda durante a substituição do dispositivo ligado. Para alterar o software carregado de fábrica, você geralmente precisa quebrar um lacre e piscar a memória. Também pode estar na memória somente leitura como uma EEPROM.
Graças aos avanços nas práticas de FLS, o software carregável em campo está sendo usado em muitos locais onde o software carregado de fábrica havia sido usado anteriormente e atualizações frequentes de software estão se tornando comuns na maioria dos sistemas. O software em praticamente qualquer parte pode ser carregado em campo se seguir as medidas de segurança e integridade.
Os bancos de dados aeronáuticos são tratados de maneira diferente em parte devido à diferença na frequência de atualização. Um banco de dados aeronáutico deve mudar com freqüência (muitas vezes mais de uma vez por mês), enquanto as atualizações de aviônica são menos frequentes e podem ser menos de uma vez por ano (especialmente porque toda a configuração da aeronave, inclusive o software, deve ser certificada).
Quais são as etapas para atualizar o software?
A patente da Airbus explica o processo de forma excelente, mesmo com diagramas em francês:
The first step is managed by the manufacturer of the aircraft. The latter decides upon a required modification for the aircraft it has constructed. It develops the modification for the solution found and certifies it with the certification authorities. The manufacturer thus shows that the new configuration proposed is compatible with the environment and with the configuration of the aircraft for which the modification is destined.
Once the solution has been developed and validated, the manufacturer prepares a pack, referred to as service bulletin, containing a description of the operations to conduct to perform the modification of the aircraft and also a physical element containing the software to change and furthermore containing corresponding documentation. The physical element containing the software depends on the size of the software and it may for example be a USB key (USB standing for “Universal Serial Bus”), a CD/DVD, etc. This pack is delivered physically to the company concerned that operates the aircraft. This delivery may also be performed electronically.
The second step is carried out under the responsibility of the operator of the aircraft, for example an airline company, or, when the aircraft is under heavy maintenance under the responsibility of the maintenance organization authorized for that. Similarly, this step may be performed by an authorized MRO (standing for Maintenance Repair Organization) when the aircraft is transformed for a change of operator. This is typically of the case for an aircraft hire company.
The operator receives the service bulletin and transfers it to a technical center (FIG. 1) in order for the operator to allocate and verify the compatibility of the service bulletin received with the environment of the aircraft of its fleet. Once the verifications have been performed and the service bulletin validated, a work request is sent to the maintenance management department of the operator's fleet. That department then defines the times (stopover, heavy maintenance visit, etc.) at which the aircraft may undergo that update and provides the workshop with the software element to install on the aircraft (USB key, DVD, etc.).
A maintenance workshop of the airline company or of a maintenance repair organization performs the requested task and downloads the software which is in the DVD or USB key (or other medium). The action is recorded and the configuration repository of the aircraft is updated. Of course, the technical center (and possibly other departments concerned) is kept informed of the upgrade which has just been carried out.
As atualizações de banco de dados de navegação eram tradicionalmente atualizadas usando um processo semelhante de acordo com este Patente da Honeywell:
... the information contained in the navigation database changes on a very frequent basis as new navigation aids are created, old navigation aids are retired, airports add or retire runways, or the like. Accordingly, government agencies such as the United States Federal Aviation Administration (FAA) typically require that aircraft update navigation databases on a regular basis, such as every twenty-eight days. Other components (such as global positioning systems (GPS)) may also make use of periodic data upgrades.
Conventional techniques of updating databases have been cumbersome and time consuming. Typically, a customer (such as an airline) obtains a diskette containing the upgrade for a particular aircraft type from a database or component vendor. The customer then duplicates the diskette and distributes copied diskettes to service technicians, who then go to individual aircraft and manually load the data update using a specialized data loader...
Veja também https://www.google.com/patents/US20030208579 para um exemplo de como os sistemas de entretenimento a bordo são tradicionalmente atualizados.
Que mídia é usada?
Uma variedade de mídias tem sido usada ao longo do tempo, uma vez que a mídia de armazenamento muda rapidamente. Mídias físicas como CDs estão sendo substituídas rapidamente por atualizações de rede de alta integridade devido aos benefícios de custo envolvidos.
Uma patente para um "Método para controlar atualizações de dados implementadas pelo cliente" explica como esse processo foi feito historicamente:
Originally, airline maintenance personnel upgraded flight management
computers by using an ARINC standard 603 portable tape upload device,
but such tape loaders were clumsy and slow. Manufacturers then
progressed to data loading computers that were based on ARINC standard
615 (Data Loader standard), which is in essence a software protocol
layered onto an ARINC standard 429 data bus. ARINC 615 data loaders
abandoned the tape format of ARINC 603 in favor of a 3.5-inch floppy
diskette medium for transferring data and software... The
software or data for these updates has grown increasingly more complex
as the systems in aircraft provide more functionality to the cockpit
crew and traffic control.
Na história mais recente, "A mídia usada para carregar as mudanças no FLS com o tempo. No início dos 1990, disquetes de polegadas 3.5 eram usados. Por exemplo, o Boeing 777 original carregava fichários cheios de disquetes. A tecnologia mudou para discos compactos. (Cds), pen drives de discos digitais de vídeo (DVD), dispositivos de armazenamento em massa e até mesmo redes locais (LANs) " fonte
Outro patente discute em detalhes a maneira como o software pode ser carregado pela LAN. A imagem abaixo é da patente. Os princípios são os mesmos:
- O software deve fazer parte de uma configuração de aeronave certificada
- As aeronaves da frota são verificadas na rede para ver se sua configuração está desatualizada ou incorreta
- A aeronave é atualizada para uma nova configuração quando e somente quando o operador inicia a atualização
- Uma verificação de integridade confiável como um CRC está em vigor para garantir que a atualização pela LAN foi bem-sucedida
Que medidas de segurança e integridade são tomadas?
Fato engraçado: O software carregável em campo é considerado uma partee, portanto, o gerenciamento de configuração que se aplica às peças também se aplica às atualizações de software. O software atualizado deve ser certificado para a configuração da aeronave em que está ligado, deve ter um número de peça que possa ser verificado e deve aparecer na lista de materiais da nova aeronave. Às vezes, um dispositivo inteiro terá um novo número de peça quando seu software é atualizado ou, às vezes, o software tem um número de peça separado que é atualizado enquanto o hardware retém seu próprio número de peça. Quaisquer modificações no software devem passar por uma análise e recertificação de impacto de alterações.
O software carregável em campo deve ser certificado para o dispositivo e a aeronave em que está sendo carregado e deve haver verificações no processo de carregamento do software, no próprio software e no número de peça do software. O DO-178C especifica especificamente que:
- deve haver proteção contra carregamento inadvertido (o que também significa que, diferentemente do Windows, ele não forçará a atualização no pior momento possível)
- deve haver detecção de cargas com falha, parciais ou corrompidas
- você deve poder determinar com segurança que o software atualmente carregado e todos os seus arquivos estão corretos (por exemplo, usando um CRC)
- se um mecanismo de exibição for usado para exibir a carga do software, a exibição deverá ser precisa e confiável
As verificações de integridade devem ter um nível de confiabilidade, semelhante a outras verificações de confiabilidade nas aeronaves. Isso geralmente significa que o carregamento do software deve ter uma chance do 10 ^ -9 de corromper o software ou indicar incorretamente que o carregamento do software está correto. Em vez disso, você pode qualificar a ferramenta usada para carregar o software, mas isso é menos comum do que mostrar que as verificações de integridade são confiáveis.
Cadeia de confiança para bancos de dados aeronáuticos
Para bancos de dados aeronáuticos, os níveis de segurança e a verificação de erros também são seriamente considerados. Cada participante na criação e transmissão de bancos de dados aeronáuticos deve ter um plano de conformidade, gerenciamento de configuração, verificação de erros, um método para garantir que alterações não autorizadas não ocorram e gerenciamento de qualidade. Conforme descrito em AC 20-153, A FAA fornecerá uma carta de aceitação (LOA) para cada participante neste processo, indicando sua conformidade com regulamentos como DO-200A. Os dados aeronáuticos devem atender a vários padrões aplicáveis, como ARINC 424 e DO-291B, mas uma discussão sobre eles está fora do escopo da questão.
Para mais informações:
Capítulo 5 de Pedido FAA 8110.49 aborda especificamente a aprovação de software carregável em campo. O DO-200A da RTCA é o padrão para a preparação e transmissão de bancos de dados aeronáuticos de um provedor de dados regulamentado para o operador da aeronave. Veja também FAA AC 20-153 por certificar conformidade e conceder cartas de aceitação à DO-200A. Eu referenciei fortemente "Desenvolvendo software crítico para a segurança" de Leanna Rierson. Eu sugiro que você faça referência a este ou outro livro.
Isenção de responsabilidade: Eu não sou um DER ou engenheiro do processo de carregamento de dados e, portanto, essas informações são apenas para referência. Para trabalhos técnicos, consulte os documentos de origem e um DER em vez de confiar nessas informações.
Atualizando a navegação do A380 usando unidades flash
