BRPI0813077B1 - sistema de módulo de processamento de computador - Google Patents

Abstract

sistema de módulo de processamento de computador trata-se um módulo de processamento de computador (módulo) com n-rotas de alta integridade, sendo que n é um número inteiro maior ou igual a dois, sendo que o módulo compreende: um elemento de aplicação hospedada (310) e um elemento de i/o (320) por rota de processamento; uma unidade de gerenciamento de tempo (tm) (400) configurada para determinar um valor de tempo equivalente para uma solicitação feita pelo software que funciona em cada uma das n rotas de processamento, independente de quando a solicitação é de fato recebida e age sobre cada uma das n rotas de processamento; uma unidade de gerenciamento de regiões críticas (crm) configurada para possibilitar que as regiões críticas dentro da rota respectiva sejam identificadas e sincronizadas através de todas as n rotas de processamento; uma unidade de gerenciamento de entrada de dados (im) configurada para assegurar que cada rota respectiva receba exatamente o mesmo conjunto de dados de alta integridade, conforme todas as outras n rotas de processamento, e para emitir, de outra forma, uma condição de erro; uma unidade de gerenciamento de saída de dados (om) configurada para determinar se a saída da rota respectiva é exatamente o mesmo conjunto de dados de alta integridade que todas as outras n rotas de processamento, e para emitir, de outra forma, uma condição de erro; as regiões críticas identificadas pelo crm corresponderem às regiões dentro do software que não podem ser obtidas por preempção por quaisquer outras linhas de execução separados de uma linha de execução que está funcionando.

Description

“SISTEMA DE MÓDULO DE PROCESSAMENTO DE COMPUTADOR” Campo da Invenção [001] A presente invenção refere-se a um módulo de processamento de computador (módulo) para alta integridade e alta disponibilidade no processamento de fonte que aplica mínimas restrições do projeto nas aplicações de software (aplicações hospedadas) que são hospedadas no módulo, de modo que possam ainda funcionar em típicos módulos de processamento de computador normais.

Antecedentes da Invenção [002] Os módulos de processamento de computador (módulos) podem fornecer alta integridade e alta disponibilidade na fonte para assegurar que as falhas sejam detectadas e isoladas com precisão e os alarmes falsos sejam minimizados. Os módulos de alta integridade são até mais importantes para aeronaves, de modo que uma falha que não é detectada e isolada prontamente e com precisão possa resultar em dificuldades operacionais. O isolamento e detecção adequada de falhas, em um módulo que fornece alta integridade na fonte, são algumas vezes chamados de capacidade de estabelecer zonas de contenção de falhas (FCZ) dentro do módulo ou sistema, de modo que uma falha não seja capaz de se propagar para fora da FCZ, na qual ocorreu. Além disso, é importante que os módulos de alta integridade devam ter também uma probabilidade muito baixa de alarmes falsos, uma vez que cada alarme falso pode resultar em uma perda temporária de função ou recursos do computador desperdiçados a fim de corrigir um suposto problema que não existe de fato.

[003] Os projetos convencionais para a alta integridade nos módulos de fonte exigem um caro conjunto de circuitos personalizado a fim de implementar o processamento de sincronia (lock-step) em nível de instrução entre dois ou mais microprocessadores no módulo. As abordagens do

Petição 870190059930, de 27/06/2019, pág. 13/40

2/25 processamento de sincronia (lock-step) em nível de instrução convencional fornecem alta integridade a todas as aplicações hospedadas, mas pode ser difícil (ou impossível) de implementar com os microprocessadores do estado da técnica que implementam controladores de memória integrados e suporte de entrada/saída que exigem múltiplas malhas de captura de fase (PLLs - Phase Lock Loops) com diferentes circuitos de recuperação de clock.

[004] Há uma necessidade por uma alta integridade no projeto de fonte para um módulo que aplica mínimas restrições de projeto nas aplicações hospedadas (isto é, a mesma aplicação hospedada pode também funcionar em um módulo de integridade normal típico) e que seja capaz de utilizar microprocessadores de alta velocidade (por exemplo, processadores integrados).

Descrição da Invenção [005] Uma realização da invenção refere-se a um módulo de processamento de computador com N-rotas de alta integridade (módulo), sendo que N é um número inteiro maior ou igual a dois. O módulo compreende um elemento de aplicação hospedada e um elemento de I/O por rota de processamento, uma unidade de gerenciamento de tempo (TM) configurada para determinar um valor de tempo equivalente para uma solicitação feita pelo software que funciona em cada uma das N rotas de processamento, independente de quando a solicitação é realmente recebida e age sobre cada uma das N rotas de processamento, e uma unidade de gerenciamento de regiões críticas (CRM) configurada para possibilitar que as regiões críticas dentro da rota respectiva sejam identificadas e sincronizadas através de todas as N rotas de processamento.

Breve Descrição dos Desenhos [006] As realizações serão descritas, daqui por diante, com referência aos desenhos em anexo, em que os numerais semelhantes

Petição 870190059930, de 27/06/2019, pág. 14/40

3/25 representam elementos semelhantes, e nos quais:

-a Figura 1 mostra um primeiro cenário para o qual se deseja que seja atenuado, de modo que torne impossíveis as condições de falha para as aplicações hospedadas;

-a Figura 2 mostra um segundo cenário para o qual se deseja que seja atenuado, de modo que torne impossíveis as condições de falha para as aplicações hospedadas;

-a Figura 3 é um diagrama de blocos lógico das unidades de gerenciamento de tempo (TM), gerenciamento de região crítica (CRM), gerenciamento de entrada de dados (IM) e gerenciamento de saída de dados (OM);

-a Figura 4 é um diagrama de blocos que mostra um módulo de processamento de computador livremente sincronizado de alta integridade (módulo), de acordo com uma realização;

-a Figura 5 é um diagrama de blocos que mostra detalhes da unidade de gerenciamento de tempo, de acordo com a realização;

-a Figura 6 é um diagrama de blocos que mostra detalhes da unidade de gerenciamento de regiões críticas, de acordo com a realização;

-a Figura 7 mostra o primeiro cenário (da Figura 1), para o qual as condições de falha potenciais são evitadas, mediante a utilização do sistema e método, de acordo com a realização; e

-a Figura 8 mostra o segundo cenário (da Figura 2), para o qual as condições de falha potenciais são evitadas, mediante a utilização do sistema e método, de acordo com a realização.

Descrição Das Realizações da Invenção [007] Na seguinte descrição, para os propósitos de explicação, são apresentados numerosos detalhes específicos, a fim de fornecer uma compreensão completa da tecnologia descrita no presente documento. Será

Petição 870190059930, de 27/06/2019, pág. 15/40

4/25 evidente para um técnico no assunto, no entanto, que as realizações podem ser praticadas sem estes detalhes específicos. Em outros casos, as estruturas e dispositivos são mostrados em forma de diagrama a fim de facilitar a descrição das realizações.

[008] As realizações são descritas abaixo com referência aos desenhos. Estes desenhos ilustram determinados detalhes de realizações específicas que implementam o módulo, o método e o produto de programa de computador, descritos no presente documento. Contudo, os desenhos não deveriam ser construídos como imponentes a quaisquer limitações que possam estar presentes nos desenhos. O método e produto de programa de computador podem ser fornecidos em qualquer meio legível por máquina para concluir suas operações. As realizações podem ser implementadas com o uso de um processador de computador existente, ou por um processador de computador de propósito especial integrado para isto ou outro propósito, ou por um sistema de conexão física.

[009] Conforme observado acima, as realizações descritas no presente documento incluem um produto de programa de computador que compreende meios legíveis por máquina para carregar ou ter instruções executáveis por máquina ou estruturas de dados armazenados no mesmo. Tais meios legíveis por máquina podem ser qualquer meio disponível, o qual possa ser acessado por um computador de propósito especial ou propósito geral, ou outra máquina com um processador. A título de exemplo, tal meio legível por máquina pode compreender RAM, ROM, EPROM, EEPROM, CD-ROM ou outro armazenamento de disco óptico, armazenamento de disco magnético, outros tipos de dispositivos de armazenamento magnético, ou qualquer meio que possa ser usado para carregar ou armazenar o código de programa desejado na forma de instruções executáveis por máquina ou estruturas de dados, e que possam ser acessados por um computador de propósito especial

Petição 870190059930, de 27/06/2019, pág. 16/40

5/25 ou propósito geral, ou outra máquina com um processador. Quando a informação é transferida ou fornecida sobre uma rede ou outra conexão de comunicação (conexão física, sem fio ou uma combinação de conexão física ou sem fio) a uma máquina, a máquina vê propriamente a conexão como um meio legível por máquina. Deste modo, essa conexão é propriamente chamada de um meio legível por máquina. As combinações do que foi acima referido também são incluídas no escopo do meio legível por máquina. As instruções executáveis por máquina compreendem, por exemplo, as instruções e dados que fazem com que um computador de propósito geral, computador de propósito especial ou máquinas de processamento de propósito especial executem uma determinada função ou grupo de funções.

[0010] As realizações serão descritas no contexto geral das etapas do método que podem ser implementadas em uma realização por um produto de programa, que inclui as instruções executáveis por máquina, tais como código de programa, por exemplo, na forma de módulos de programa executados por máquinas em ambientes em rede. Geralmente, os módulos de programa incluem rotinas, programas, objetivos, componentes, estruturas de dados, etc. que executam tarefas particulares ou implementam determinados tipos de dados abstratos. As instruções executáveis por máquina, as estruturas de dados associadas e os módulos de programa representam exemplos de código de programa para a execução das etapas do método apresentado no presente documento. A sequência particular de tais instruções executáveis ou estruturas de dados associadas representam exemplos de ações correspondentes para a implementação das funções descritas em tais etapas.

[0011] As realizações podem ser praticadas em um ambiente em rede com o uso de conexões lógicas a um ou mais computadores remotos que têm processadores. As conexões lógicas podem incluir uma rede de área local (LAN - local area network) e uma rede de área ampla (WAN - wide area

Petição 870190059930, de 27/06/2019, pág. 17/40

6/25 network) que são apresentadas aqui a título de exemplo e não constituem qualquer limitação. Tais ambientes em rede são comuns em redes de computadores coorporativos ou empresariais, intranets e a internet e podem usar uma ampla variedade de protocolos de comunicação diferentes. Os técnicos no assunto irão observar que tais ambientes de computação em rede irão abranger tipicamente muitos tipos de configuração de sistema de computador que incluem computadores pessoais, dispositivos de mão, sistemas de multiprocessadores, eletrônicos de consumo programáveis ou à base de microprocessador, PCs de rede, minicomputadores, computadores centrais, e similares.

[0012] As realizações podem ser também praticadas em ambientes de computação distribuídos, onde as tarefas são executadas por dispositivos de processamento remotos ou locais que são vinculados (por meio de conexões física, conexões sem fio ou por uma combinação das conexões sem fio ou de conexão física) através de uma rede de comunicação. Em um ambiente de computação distribuída, os módulos de programa podem ser localizados em dispositivos de armazenamento de memória tanto remotos quanto locais.

[0013] Um sistema para a implementação de todas ou parte das realizações pode incluir um dispositivo de computação de propósito geral na forma de um computador, que inclui uma unidade de processamento, uma memória do sistema e um barramento do sistema, que acopla diversos componentes do sistema que incluem a memória do sistema para a unidade de processamento. A memória do sistema pode incluir memória somente de leitura (ROM) e memória de acesso aleatório (RAM). O computador pode incluir também uma unidade de disco rígido magnético para a leitura a partir de, e escrita para, um disco rígido magnético, uma unidade de disco magnético para a leitura ou escrita para um disco magnético removível e uma unidade de disco

Petição 870190059930, de 27/06/2019, pág. 18/40

7/25 óptico para a leitura ou escrita para um disco óptico removível, tal como um CD-ROM ou outro meio óptico. As unidades e o meio legível por máquina associados das mesmas fornecem o armazenamento não-volátil das instruções executáveis por máquina, estruturas de dados, módulos de programa e outros dados para o computador.

[0014] Uma primeira realização será descrita em detalhes abaixo no presente documento, a qual corresponde a uma abordagem livremente sincronizada para o fornecimento de alta integridade na fonte de um sistema compreendido por um módulo de processamento de computador (módulo).

[0015] A alta integridade na computação de fonte exige atualmente ao menos duas rotas de processamento que funcionam em sincronia no nível de instrução, ou uma rota de processamento e um monitor. Para uma rota dupla, alta integridade no módulo de processamento de fonte, o problema a ser resolvido pode ser comparado a uma máquina de estado finito. Isto é, se o software que funciona em cada rota de processamento de um módulo recebe as mesmas entradas (dados, interrupções, tempo, etc.) e é capaz de executar a mesma “quantidade” de processamento sobre os dados antes de enviar saídas ou antes de receber novas entradas, então, cada rota irá produzir saídas idênticas na ausência de falhas. Deve-se observar que esta realização é primeiramente descrita em função de um módulo, onde cada rota de processamento tem microprocessadores idênticos. Contudo, esta realização também se aplica a módulos que têm processadores diferentes em uma ou mais das N rotas. Neste caso, espera-se que cada rota de processamento produza saídas que são idênticas dentro de uma faixa específica (talvez devido à diferença na unidade de ponto flutuante do microprocessador, por exemplo).

[0016] As implicações da analogia da máquina de estado finito são conforme o exposto a seguir. Quando o software que funciona em um módulo recebe as entradas, as entradas precisam ser idênticas em ambas as

Petição 870190059930, de 27/06/2019, pág. 19/40

8/25 rotas e ambas as rotas precisam receber as entradas quando estão exatamente no mesmo estado. As entradas deveriam ser consideradas aquelas explicitamente solicitadas (por exemplo, dados da porta ARINC653, carimbo de data/hora, etc.) ou aquelas recebidas devido a um evento externo (interrupção de hardware, interrupção virtual, etc.). É dada atenção particular às entradas que fariam com que o software modificasse a linha de execução (estado) devido, por exemplo, ao comportamento preemptivo de prioridade. Quando o software que funciona em um módulo envia uma saída, os dados a partir de ambas as rotas precisam ser comparados antes de sua saída. A fim de assegurar que a comparação de dados de saída não falhe (devido à sincronização de estado imprópria), as partes do software responsáveis pela produção dos dados de saída precisam alcançar o mesmo estado em ambas as rotas antes que as saídas possam ser comparadas e, então, subsequentemente transmitidas.

[0017] Os cenários mostrados na Figura 1 e Figura 2 fornecem ilustrações de dois cenários de falha potenciais que precisam ser atenuados, de modo que as condições de falha sejam evitadas (pelo projeto do módulo). Estes cenários específicos têm sido selecionados, devido á isto acredita-se que um projeto de módulo que possa atenuar estas condições de falha tenha uma alta probabilidade em ser capaz de lidar (ou possa ser estendido para lidar) com uma restrição de projeto mais geral de equivalência de dados de entrada e controlar a sincronização para o software que funciona nas N rotas de um módulo.

[0018] Com referência à Figura 1, um primeiro tipo de condição de falha potencial é descrito para um módulo de alta integridade de duas rotas. Neste módulo, as rotas 1 e 2 estão em funcionamento livremente sincronizado, mas sem a adição das unidades TM e CRM descritas no presente documento. Neste caso, livremente sincronizado significa que a rota 1 poderia estar em

Petição 870190059930, de 27/06/2019, pág. 20/40

9/25 qualquer lugar a partir de menos que uma instrução à frente ou atrás da rota 2, a qualquer número de instruções à frente ou atrás da rota 2. Para o exemplo mostrado na Figura 1, a rota 1 está “à frente” da rota 2. A condição booleana inicial usada neste exemplo é “Falsa”.

[0019] Na etapa 1, o processo 1 na rota 1 tem recém completado o ajuste de um Booleano para “Verdadeiro” quando ocorre uma interrupção de temporizador. O processo 1 na rota 2 não teve realmente uma chance de ajustar o Booleano para “Verdadeiro” (de modo que o Booleano ainda é “Falso”).

[0020] Na etapa 2, a interrupção faz com que a aplicação hospedada tanto na rota 1 como na rota 2 se desvie para o processo 2 (devido à preempção de prioridade).

[0021] Na etapa 3, o processo 2 na rota 1 e o processo 2 na rota 2 leem o Booleano e enviam uma saída que inclui o estado Booleano. A rota 1 emite verdadeiro, enquanto que a rota 2 emite falso.

[0022] Na etapa 4, uma unidade de gerenciamento de saída de dados (OM) detecta uma falha de comparação entre duas rotas. Isto é um tipo de falha que poderia ter sido evitada (aumentando assim a disponibilidade) se a sincronização adequada entre as duas rotas de computação tivesse sido fornecida pelo módulo.

[0023] Com referência à Figura 2, um segundo tipo de condição de falha potencial é descrito para um módulo de alta integridade de duas rotas. Neste sistema, as rotas 1 e 2 estão em funcionamento livremente sincronizado, mas sem as unidades TM e CRM descritas no presente documento. Neste caso, livremente sincronizado significa que a rota 1 poderia estar em qualquer lugar a partir de menos que uma instrução à frente ou atrás da rota 2, a qualquer número de instruções à frente ou atrás da rota 2. Para o exemplo mostrado na Figura 2, a rota 1 está “à frente” da rota 2.

Petição 870190059930, de 27/06/2019, pág. 21/40

10/25 [0024] Na etapa 1, o processo 1 na rota 1 (um processo de segundo plano de baixa prioridade) tem recém completada uma transação de saída na porta FOO, quando ocorre uma interrupção de temporizador. O processo 1 na rota 2 não completou a mesma transação de saída.

[0025] Na etapa 2, o processo de segundo plano (processo 1) não funciona mais devido ao fato de ser uma baixa prioridade. De preferência, um processo de alta prioridade (processo 2) funciona em ambas as rotas e recebe dados de entrada que fazem com que o processo 1 seja reiniciado. Deste modo, o processo 1 na rota 2 jamais envia sua saída.

[0026] Na etapa 3, eventualmente (dentro de algum limite de tempo delimitado), a unidade de gerenciamento de saída de dados relata uma falha devido ao fato de que a rota 2 jamais enviou uma saída na porta FOO. Isto é um tipo de falha que poderia ser evitada (aumentando assim a disponibilidade) se a sincronização adequada entre as duas rotas de computação tivesse sido fornecida pelo módulo.

[0027] A abordagem arquitetural utilizada na primeira realização consiste no fato de que os componentes de hardware e software do módulo trabalham em conjunto para assegurar que o estado do software de cada rota de processamento seja sincronizado antes que (e enquanto) o processamento de I/O seja executado. Deve-se observar que “software” se refere tanto ao software de aplicação hospedada como ao componente de software do módulo. Deve-se observar também que o termo “sincronizado” significa que cada uma das rotas completou o mesmo conjunto de regiões críticas e ambas estão dentro da mesma região crítica que reúne as mesmas entradas, ou ambas estão dentro da mesma região crítica que envia as mesmas saídas. A saída de I/O de cada uma das N rotas é comparada e precisa passar esta comparação antes que seja emitida.

[0028] Os atributos de nível superior da abordagem arquitetural

Petição 870190059930, de 27/06/2019, pág. 22/40

11/25 são conforme o exposto a seguir. A arquitetura suporta de maneira robusta os ambientes divididos por espaço e/ou tempo, típicos de módulos que suportam a virtualização (por exemplo, conforme especificado pela especificação ARINC 653), assim como os ambientes onde o módulo suporta somente uma única aplicação hospedada. A arquitetura suporta processadores diferentes ou idênticos (2 ou mais) nas N rotas de processamento do módulo. A arquitetura é livremente síncrona, por meio da qual os estados computacionais são sincronizados. A arquitetura abstrai o gerenciamento de redundância (sincronização e comparação) das aplicações hospedadas até a maior extensão possível. Isto possibilita que os fornecedores de aplicação hospedada utilizem os padrões de projeto convencionais para seus softwares (não são exigidos para adicionar em recursos de alta integridade especiais) e irá possibilitar que executem o mesmo software de aplicação hospedada nos módulos de integridade normal típicos. A arquitetura é paramétrica de modo que as unidades que fornecem alta integridade e disponibilidade possam ser estaticamente configuradas. Isto possibilita que algumas aplicações hospedadas (ou dados para/a partir destas aplicações hospedadas) sejam configuradas como integridade normal. A arquitetura assegura que as falhas sejam detectadas a tempo para atenuar os perigos funcionais devido à saída errônea.

[0029] Para implementar esta abordagem, um sistema e método, de acordo com a primeira realização, fornece mecanismos (ou elementos) que incluem: gerenciamento de entrada de dados (IM), gerenciamento de tempo (TM), gerenciamento de regiões críticas (CRM) e gerenciamento de saída de dados (OM). A Figura 3 mostra um diagrama de blocos lógico de como estes elementos se relacionam tanto com o módulo como com o software de aplicação hospedada. Cada um destes elementos será descrito em detalhes.

[0030] Em uma possível implementação da primeira realização,

Petição 870190059930, de 27/06/2019, pág. 23/40

12/25 os mecanismos de IM, TM, CRM e OM são construídos em um elemento de I/O que é conectado ao elemento processador de aplicação hospedada através de um barramento de alta velocidade (por exemplo, PCI-Express ou um barramento patenteado). Dois elementos de I/O são utilizados (com um canal de comunicação entre eles) a fim de suportar as exigências de alta integridade. Além disso, o software no elemento de aplicação hospedada interage com estes mecanismos em pontos de sincronização prescritos.

[0031] A Figura 4 mostra um diagrama de blocos de como esta funcionalidade poderia ser implementada em um módulo de alta integridade de duas rotas, de acordo com a primeira realização. Um técnico no assunto irá reconhecer que existem muitas outras implementações possíveis da primeira realização que incluem as seguintes. Um módulo que consiste em duas rotas de processamento, cada uma contendo um microprocessador de núcleo duplo (ou múltiplo) altamente integrado e clocks associados, dispositivos de memória, dispositivos de I/O, etc., onde a funcionalidade do elemento de aplicação hospedada 310 é implementada através de componentes de software e hardware de módulo, que utilizam um ou mais dos núcleos do microprocessador (e clocks associados, memória, dispositivos de I/O, etc.) e a funcionalidade do elemento de I/O 320 é implementada através de componentes de software e hardware de módulo, que utilizam um ou mais dos núcleos do microprocessador integrados (e clocks associados, dispositivos memória, dispositivos de I/O, etc.) em cada rota. Um módulo que consiste em duas rotas de processamento, cada uma contendo um microprocessador de núcleo único e clocks associados, dispositivos de memória, dispositivos de I/O, etc., onde todas as funcionalidades do elemento de aplicação hospedada 310 e do elemento de I/O 320 para cada rota são implementadas através de componentes de software e hardware de módulo fornecidos pelo núcleo de microprocessador e memória associada, dispositivos de I/O, etc., em cada rota.

Petição 870190059930, de 27/06/2019, pág. 24/40

13/25 [0032] Conforme mostrado no exemplo fornecido na Figura 4, um módulo livremente sincronizado de alta integridade 300, de acordo com a primeira realização, inclui duas rotas, rota 1 e rota 2, por meio das quais a primeira realização pode ser utilizada em um módulo de N rotas, sendo que N é um número inteiro positivo maior ou igual a dois. O módulo 300 inclui também um elemento de aplicação hospedada 310, o qual tem um processador CPU 350A, 350B para cada rota (no exemplo mostrado na Figura 4, existem dois processadores CPUs, um 350A para a rota 1 e um 350B para a rota 2). Cada processador CPU 350A, 350B tem acesso a uma memória não volátil (NVM) 330A, 330B e a uma memória de acesso aleatório dinâmica síncrona (SDRAM) 340A, 340B, de modo que um circuito de clock seja fornecido para cada processador CPU. A Figura 4 mostra um circuito de clock 360 que fornece um sinal de clock para cada processador CPU 350A, 350B, de modo que um monitor de clock 365 seja fornecido também para assegurar um sinal de clock estável para o processador CPUs 350A, 350B de cada rota, em todo momento. Um técnico no assunto irá reconhecer que o clock 360 e o monitor de clock 365 no elemento de aplicação hospedada 310 poderiam ser substituídos por um clock independente que funciona em cada rota e o clock 384 e o monitor de clock 382 no elemento de I/O 320 poderiam ser substituídos por um clock independente que funciona em cada rota, enquanto que se inclui no escopo da realização descrita no presente documento.

[0033] O elemento de aplicação hospedada 310 é conectado de maneira comunicativa a um elemento de I/O 320 em cada rota respectiva, por meio de um barramento PCI-E. Além disso, cada rota do elemento de aplicação hospedada 310 é conectada à outra rota do elemento de aplicação hospedada 310 por meio de um barramento PCI-E. Um técnico no assunto irá reconhecer que outros tipos de barramentos, redes comutadas ou dispositivos de memória podem ser utilizados para fornecer tal conexão comunicativa dentro do

Petição 870190059930, de 27/06/2019, pág. 25/40

14/25 elemento de aplicação hospedada 310 e entre o elemento de aplicação hospedada 310 e o elemento de I/O 320, enquanto que se inclui no escopo da realização descrita no presente documento.

[0034] O elemento de I/O 320 inclui um processador de I/O 370A de rota 1 e um processador de I/O 370B de rota 2, de modo que estes processadores de I/O 370A, 370B sejam conectados de maneira comunicativa um ao outro, por meio de um barramento PCI-E. Um técnico no assunto irá reconhecer que outros tipos de barramentos, redes comutadas ou dispositivos de memória podem ser utilizados para fornecer tal conexão comunicativa entre os processadores de I/O 370A, 370B de cada rota, enquanto que se inclui no escopo da realização descrita no presente documento.

[0035] Cada processador de I/O 370A, 370B inclui um elemento de gerenciamento de entrada de dados (IM), um elemento de gerenciamento de tempo (TM), um elemento de gerenciamento de regiões críticas (CRM) e um elemento gerenciamento de saída de dados (OM). Cada processador de I/O 370A, 370B inclui também outro elemento de I/O 375A, 375B e um elemento de ARINC 664 parte 7 380A, 380B, de modo que estes elementos sejam conhecidos pelos técnico no assunto de processamento de computador de aeronaves, e não será descrito qualquer adicional com os propósitos de brevidade. Um técnico no assunto irá reconhecer que outros tipos de barramentos de dados de I/O (além de ARINC664 parte 7) podem ser utilizados para fornecer tal conexão comunicativa para o módulo, enquanto que se inclui no escopo da realização descrita no presente documento.

[0036] Uma unidade de clock 384 e um monitor de clock 382 são mostrados também na Figura 4, para o fornecimento de um sinal de clock estável para cada processador de I/O 370A, 370B em cada rota do módulo de rota múltipla. Um técnico no assunto irá reconhecer que o clock 384 e o monitor de clock 382 no elemento de I/O 320 poderiam ser substituídos por um clock

Petição 870190059930, de 27/06/2019, pág. 26/40

15/25 independente que funciona em cada rota, enquanto que se inclui no escopo da realização descrita no presente documento.

[0037] A Figura 4 mostra também uma unidade PHY de I/O 386A, 386B para cada rota, uma unidade XFMR 388A, 388B para cada rota, e uma unidade de monitores e fornecedores de energia 390 que fornece sinais de energia e que executa o monitoramento para os componentes em cada rota do módulo de rota múltipla. Uma unidade de interface 395 fornece conexões de sinal para energia (por exemplo, 12V DC, PWR ENBL) a diversos componentes do módulo 300. A energia pode ser fornecida para a unidade de interface 395 (e, deste modo, para os diversos componentes do módulo de alta integridade 300) a partir de um motor da aeronave (quando o motor da aeronave está ligado) ou a partir de uma bateria ou gerador (quando o motor da aeronave está desligado), a título de exemplo. Um técnico no assunto irá reconhecer que os monitores e fornecedores de energia 390 poderiam ser implementados como independentes (um por rota) ou como um único monitor e fornecedor de energia para o módulo, enquanto que inclui-se no escopo das realizações descritas no presente documento.

[0038] A seguir é fornecida uma visão geral dos mecanismos de IM, TM, CRM e OM.

[0039] O IM assegura que as rotas de computação em todo funcionamento do software recebam exatamente o mesmo conjunto de dados de entrada de alta integridade. Se o mesmo conjunto de dados não pode ser fornecido para cada rota, o IM irá descartar os dados, evitar que cada rota receba os dados e relatar a condição de erro.

[0040] Pode existir uma grande quantidade de fluxos de dados que são considerados de integridade normal. Isto é, pode existir uma grande quantidade de dados que fluem no módulo ou fluem a partir de aplicações hospedadas no módulo que não exigem interfaces de I/O de rota dupla (e a

Petição 870190059930, de 27/06/2019, pág. 27/40

16/25 sobrecarga associada para executar a validação de dados de rota cruzada). A primeira realização possibilita que os fluxos de dados de integridade normal sejam fornecidos para ambas as rotas de computação a partir de uma fonte de integridade normal. Esta otimização pode ser implementada através de um parâmetro de configuração que indica cada fluxo de dados (por exemplo, cada enlace virtual de ARINC664 parte 7 destinado para ou enviado a partir de uma aplicação hospedada) como de integridade normal ou alta.

[0041] Em uma possível implementação da primeira realização para o uso em uma aeronave comercial, os exemplos dos serviços que necessitam fornecer equivalência de dados de entrada em múltiplas rotas consistem em: chamadas API de I/O ARINC653 parte 1 (por exemplo, portas de enfileiramento e amostragem); chamadas API de I/O ARINC653 parte 2 (por exemplo, pontos de acesso de serviço e sistema de arquivos); chamadas API de I/O OS (por exemplo, comunicação inter-processo POSlX); e outras chamadas API (por exemplo, plataforma específica).

[0042] O TM assegura que todas as rotas de computação recebam um valor de tempo equivalente para a mesma solicitação, até se as solicitações estiverem em tempo assimétrico (devido à sincronização livre entre as rotas de computação). Sob este aspecto, o tempo é um tipo especial de dados de entrada para a aplicação hospedada, à medida que seu valor é produzido/controlado pelo módulo como oposto ao que é produzido por outra aplicação hospedada ou uma LRU externa ao módulo. A Figura 5 mostra um diagrama de blocos do TM 400 e os sinais que este transmite para as rotas e recebe a partir das rotas de um módulo de rotas múltiplas, de acordo com a primeira realização.

[0043] Em essência, o TM assegura que cada rota de computação obtenha o mesmo tempo exato que corresponde à solicitação que foi feita por outra rota. Uma memória temporária extensa 1 (por exemplo, uma

Petição 870190059930, de 27/06/2019, pág. 28/40

17/25 memória temporária que armazena somente uma entrada de tempo) retém o valor de tempo que irá ser entregue para ambas as rotas, uma vez que ambas tenham emitido uma solicitação por tempo. Se uma rota de computação estiver “esperando” que outra rota emita uma solicitação de tempo por um período de tempo significante (provavelmente como resultado de um erro na outra rota), é usado um mecanismo temporizador watchdog (watchdog timer) (não mostrado) para esta rota para detectar e responder a esta condição de erro.

[0044] O TM, de acordo com a primeira realização, pode ser implementado no módulo através da lógica hardware/software (por exemplo, em um FPGA no elemento de I/O em combinação com o software do módulo que controla o acesso ao FPGA). A fim de fornecer um tempo sincronizado eficiente, o TM pode ser acessível em um modo de “usuário” (de modo que uma chamada de sistema não seja exigida).

[0045] Em uma possível implementação da primeira realização para o uso em uma aeronave comercial, o TM é solicitado quando a aplicação hospedada faz as seguintes chamadas API: chamadas API de ARINC653 parte 1 e parte 2 aplicáveis (por exemplo, Get_Time); chamadas API de POSlX aplicáveis (por exemplo, APIs temporizadores); e outras chamadas de API (por exemplo, plataforma específica).

[0046] O TM é solicitado quando o software de plataforma tem uma necessidade por tempo de sistema. O TM, conforme mostrado na Figura 5, inclui uma memória temporária de tempo. O TM recebe sinais de tempo solicitado a partir de cada rota, e emite os dados de tempo para cada rota. Um tempo atual é fornecido ao TM por meio de uma unidade de hardware de tempo.

[0047] A memória temporária de tempo pode ser implementada como uma memória temporária extensa N (por exemplo, uma memória temporária capaz de armazenar N valores de tempo), em oposição a uma

Petição 870190059930, de 27/06/2019, pág. 29/40

18/25 memória temporária extensa 1, em uma implementação alternativa da primeira realização. Isto pode fornecer uma otimização de desempenho se for determinado que haja um potencial para uma grande quantidade de assimetria/desvio entre as rotas de computação, se for desejado minimizar o número de pontos de sincronização (que corresponde aos pontos nos quais uma rota precisa aguardar a outra rota alcançar).

[0048] A Figura 6 mostra um diagrama de blocos do CRM 500 e os sinais que são transmitidos para as rotas e recebidos a partir das rotas de um módulo de rotas múltiplas, de acordo com a primeira realização. O CRM possibilita que as regiões críticas dentro das múltiplas rotas sejam identificadas e sincronizadas através das rotas de computação. Estas regiões críticas são, essencialmente, regiões dentro do software que não podem ser obtidas por preempção por quaisquer outras linhas de execução dentro do mesmo contexto de processamento. Determinadas épocas geradas pela aplicação hospedada e software do módulo irão interagir com o CRM para sincronizar propriamente através de todas as rotas de computação. O CRM assegura que todas as rotas entrem e saiam do estado CR do módulo de uma maneira sincronizada.

[0049] Conforme pode ser visto no diagrama de blocos, na Figura 6, a lógica CRM exige três conjuntos de eventos de entrada para um módulo de 2 rotas: a solicitação de rota 1 para entrar ou sair uma região crítica, a solicitação de rota 2 para entrar ou sair uma região crítica e interrupções de módulo. Cada rota pode gerar uma solicitação para entrar uma região crítica pelo software que funciona na rota ou pelo hardware na rota (por exemplo, interrupção de hardware). Cada rota pode gerar uma solicitação para sair de uma região crítica pelo software que funciona na rota ou pelo hardware na rota. Para um módulo de 2 rotas, o CRM tem um único evento de saída, o evento crítico serializado. O evento crítico serializado inclui a serialização de eventos de mudança de estado de região crítica e interrupções temporizadas. Todas as

Petição 870190059930, de 27/06/2019, pág. 30/40

19/25 rotas de computação irão executar as mesmas transições de estado com base nos eventos críticos serializados. Para um módulo de processamento de Nrotas, de modo que N seja um número inteiro maior ou igual a dois, o CRM suporta as solicitações de N entrada para entrar ou sair de uma região crítica, interrupções de módulo e 1 evento crítico serializado, o qual é dado saída para todas as N rotas. Deve ser evidente para um técnico no assunto que o CRM poderia serializar os eventos críticos adicionais com base na implementação do módulo. Deve ser evidente também para um técnico no assunto que o CRM poderia ser estendido a suportar os múltiplos níveis de regiões críticas, a fim de suportar tais coisas como sistemas de operação de múltiplos níveis (por exemplo, modo de usuário, modo de supervisor).

[0050] O CRM pode ser implementado como: uma combinação de lógica de hardware (por exemplo, um arranjo de portas programável em campo - Field Programmable Gate Array) e/ou lógica de software.

[0051] Em geral, o CRM, de acordo com a primeira realização, é solicitado (através da solicitação de entrada/saída de CR e interrupções de módulo) nos seguintes casos: quando os dados estão sendo manipulados, os quais poderiam ser uma entrada para uma linha de execução que é diferente da linha (ou processo) que está atualmente funcionado (o CRM assegura a atomicidade através de todas as rotas de computação); Quando os dados (que incluem o tempo) entram ou são emitidos a partir do software; Quando o software tenta modificar sua linha de execução; Quando a linha de execução está modificando os dados, os quais se exigem que sejam persistentes através de uma reinicialização do módulo; Quando um evento ocorre o qual gera uma interrupção de módulo.

[0052] A Figura 7 mostra um exemplo de como o CRM, em cooperação com os outros mecanismos do processador de I/O, irá atenuar o cenário mostrado na Figura 1.

Petição 870190059930, de 27/06/2019, pág. 31/40

20/25 [0053] No sistema da Figura 7, as rotas 1 e 2 são livremente sincronizadas em funcionamento que inclui a adição das unidades de OM e CRM, descritas no presente documento. Neste caso, livremente sincronizado significa que a rota 1 poderia estar em qualquer lugar a partir de menos que uma instrução à frente ou atrás da rota 2, a qualquer número de instruções à frente ou atrás da rota 2. Para o exemplo mostrado na Figura 7, a rota 1 está “à frente” da rota 2.

[0054] Na etapa 1, processo 1 na rota 1, é chamada a API de preempção bloqueada de ARINC 653 antes de ajustar um Booleano global para verdadeiro. A chamada para a preempção bloqueada gera uma solicitação para a entrada de uma região crítica (CR). Contudo, a rota 1 não é deixada prosseguir no estado de “preempção bloqueada” até depois que a rota 2 também chame a API de preempção bloqueada de ARINC 653, a qual gera uma solicitação de entrada de uma região crítica (CR), após, o CRM envia um evento crítico serializado para ambas as rotas.

[0055] Na etapa 2, quando uma interrupção de temporizador ocorre, (interrupções de módulo, conforme mostrado na Figura 6), é gerada uma solicitação de entrada de uma CR. O CRM não pode permitir que a interrupção de temporizador provoque uma comutação de contexto em nenhuma rota, devido ao fato de que isto não pode gerar outro evento crítico serializado até que cada rota tenha gerado uma solicitação de saída de uma CR.

[0056] Na etapa 3, em algum momento no futuro, a rota 1 desbloqueia a preempção e a rota 2 bloqueia e desbloqueia a preempção (o qual gera solicitações de saída da CR). Neste momento, ambas as rotas têm atualizado com sucesso os dados globais e a preempção de prioridade (a qual inicia o processo 2 em ambas as rotas) pode agora ocorrer através do CRM que entrega o próximo evento crítico serializado.

Petição 870190059930, de 27/06/2019, pág. 32/40

21/25 [0057] Na etapa 4, o processo 2 em ambas as rotas lê o Booleano e envia uma saída (Verdadeiro). A unidade de gerenciamento de saída de dados (OM) verifica que ambas as saídas das rotas são iguais. Conforme pode ser visto na Figura 7, o CRM atenua o cenário mostrado na Figura 1.

[0058] A Figura 8 mostra um exemplo de como o CRM, em cooperação com OM, irá atenuar o cenário mostrado na Figura 2.

[0059] No sistema da Figura 8, o mesmo software com dois processos (processo 1 e processo 2) está em execução em ambas as rotas 1 e 2, de uma maneira livremente sincronizada. Neste caso, livremente sincronizado significa que a rota 1 poderia estar em qualquer lugar a partir de menos que uma instrução à frente ou atrás da rota 2, a qualquer número de instruções à frente ou atrás da rota 2. Para o exemplo mostrado na Figura 8, a rota 1 está “à frente” da rota 2.

[0060] Na etapa 1, o processo 1 na rota 1 (um processo de segundo plano de baixa prioridade) envia uma solicitação de entrada de uma região crítica ao CRM de modo que possa começar uma transação de saída na porta FOO e o CRM permite que a rota 1 comece sua transação de saída. O processo 1 na rota 2 tem enviado também uma solicitação de entrada de uma região crítica ao CRM e tem iniciado uma transação de saída na porta FOO, porém está “atrás” da rota 1. O processamento na rota 1 está no momento em que FOO tem sido emitido a partir da rota, mas FOO não tem sido ainda emitido a partir da rota 2. Devido à introdução de CRM no módulo, o CRM não irá permitir que a rota 1 saia da região crítica até que o processo 1 na rota 2 tenha também completado a mesma transação de saída e solicitado a saída da região crítica.

[0061] Na etapa 2, uma interrupção de temporizador ocorre enquanto a rota 1 está esperando sair da região crítica e a rota 2 está ainda na região crítica executando sua transação de saída.

Petição 870190059930, de 27/06/2019, pág. 33/40

22/25 [0062] Na etapa 3, uma vez que ambas as rotas tenham completado suas transações de I/O e tenham enviado uma solicitação de saída da região crítica, a interrupção serializada pode ser entregue e o processo 2 em ambas as rotas começa a funcionar. Após este momento, o processo 2 pode reiniciar seguramente o processo 1 (em ambas as rotas). Conforme pode ser visto na Figura 8, a adição de CRM atenua a condição de falha que ocorreu no cenário mostrado na Figura 2.

[0063] O OM valida os fluxos de dados de alta integridade, os quais são emitidos a partir do software em todas as rotas de computação. Se um erro for detectado nos fluxos de dados de saída, o OM irá evitar a saída dos dados e irá fornecer uma indicação de erro.

[0064] Deve-se notar que pode existir um grande número de dados que são considerados de integridade normal. Isto é, pode existir um grande número de dados (e as aplicações de software como um todo) que não exigem elemento de I/O de rota dupla (e a sobrecarga associada para executar as comparações de rota cruzada). O sistema e método, de acordo com a primeira realização, possibilitam a saída dos dados de integridade normal a partir de uma das rotas de computação (e as saídas a partir de outra rota de computação são ignoradas). Em uma possível implementação da primeira realização, um parâmetro de configuração designa os dados específicos ou aplicação hospedada completa como alta integridade ou normal.

[0065] O método e sistema, de acordo com a primeira realização suportam as exigências para a alta integridade e disponibilidade na fonte. Além disso, devido ao fato de que os pontos de sincronização tenham sido desviados para o estado do software que está em funcionamento na plataforma, a primeira realização pode ser estendida a suportar processadores diferentes.

[0066] O desempenho da primeira realização pode ser limitado pela quantidade de dados que podem ser razoavelmente sincronizados e

Petição 870190059930, de 27/06/2019, pág. 34/40

23/25 verificados no plano de I/O. Se isto for um problema, o desempenho pode ser otimizado mediante a utilização da distinção (no sistema) entre as aplicações de software e dados de alta integridade e integridade normal.

[0067] O projeto e implementação das unidades de CRM, TM, IM e OM não dependem das capacidades do hardware personalizadas (ASICs, FPGAs personalizados) ou atributos das capacidades do microprocessador atuais e/ou talvez obsoletas. Deste modo, os módulos que são construídos de acordo com a primeira realização irão exibir os seguintes atributos benéficos: habilidade de utilizar os microprocessadores do estado da técnica que contêm controladores de memória integrados, múltiplas malhas de captura de fase (PLLs - Phase Lock Loops) com diferentes circuitos de recuperação de clock, etc. (Isto irá permitir que o desempenho do módulo seja prontamente aumentado (através de atualizações do microprocessador) sem exigir um novo projeto significante dos componentes do módulo que fornecem CRM, TM, IM e OM.); A frequência das épocas de sincronização (isto é, sobrecarga) deveria ser menor do que na arquitetura de sincronia (lockstep) em nível de instrução. Deste modo, todos os mecanismos de sincronização deveriam ser diretamente acessíveis para o software que necessita acessá-los (nenhuma chamada de sistema adicional é exigida). Portanto, a sobrecarga adicional devido à sincronização deveria estar na ordem de poucas instruções em cada época.

[0068] Outros benefícios do sistema e método, de acordo com a primeira realização, são fornecidos. Os aperfeiçoamentos de desempenho deveriam estar em escala diretamente com os aperfeiçoamentos do desempenho do hardware. Isto é, isto não exige hardware especial que possa colocar muitas restrições na interface entre o processador e os subsistemas de memória. As aplicações hospedadas completas (DO-178B nível B, C, D, E) podem ser capaz de serem identificadas como integridade normal. Quando isto é feito, os elementos de IM, TM, CRM e OM serão desabilitados para todos os

Petição 870190059930, de 27/06/2019, pág. 35/40

24/25 dados e controle associado a esta aplicação hospedada, todas as transações irão ocorrer somente em uma rota de computação e a outra rota de computação pode ficar no estado inativo durante este momento. Não será somente este benefício de desempenho, mas isto pode resultar também em uma redução do consumo de energia (geração de calor) se o processador na rota de computação inativa puder ser colocado em um modo de “repouso” durante as janelas de tempo de integridade normal.

[0069] Esta primeira realização possibilita que o integrador do sistema se beneficie da noção das aplicações hospedadas de integridade normal mediante a utilização do tempo vago na rota de computação inativa para executar uma aplicação hospedada diferente. Isto pode resultar em aperfeiçoamentos do desempenho para os sistemas com uma grande quantidade de aplicações hospedadas de integridade normal.

[0070] O sistema e método, de acordo com a primeira realização, proporcionam por si próprios a capacidade de executar rotas de computação dupla independentes, duplicando, assim, de maneira eficaz, o desempenho do módulo no modo de integridade normal.

[0071] O sistema e método, de acordo com a primeira realização, suportam processadores diferentes em diferentes rotas de computação no módulo. Neste caso, pode ser possível (por exemplo) que a unidade de ponto flutuante dos processadores diferentes possa fornecer diferente comportamento de arredondamento/truncamento, o qual pode resultar em dados levemente diferentes que estão fora das rotas de computação diferentes. Consequentemente, uma comparação de dados aproximados (em oposição a uma comparação de dados exatos) pode ser utilizada para determinadas classes de fluxos de dados de saída, para que suporte diferentes processadores.

[0072] As interações de aplicação de software com os

Petição 870190059930, de 27/06/2019, pág. 36/40

25/25 mecanismos que empregam IM, TM, CRM e OM podem ser construídas em quaisquer APIs de sistema de operação (isto é, nenhuma API “especial” será exigida). Portanto, acredita-se que o sistema e método, de acordo com a primeira realização, apliquem somente restrições mínimas sobre os desenvolvedores de aplicação de software.

[0073] Espera-se que o impacto sobre o integrador de sistema (e/ou ferramentas) seja somente o fato de que os dados de configuração de I/O terão atributos (opcional) para identificar os fluxos de dados e as aplicações hospedadas, como alta integridade ou integridade normal.

[0074] Esta descrição escrita utiliza os exemplos para apresentar a invenção, que inclui o melhor modo, e também para possibilitar que qualquer técnico no assunto faça e utilize a invenção. O escopo patenteável da invenção é definido pelas reivindicações e pode incluir outros exemplos que ocorrerem aos técnicos no assunto. Tais outros exemplos se destinam a ser incluídos no escopo das reivindicações, se tiverem elementos estruturais que não se diferem da linguagem literal das reivindicações, ou se incluem elementos estruturais equivalentes com diferenças insubstanciais das linguagens literais das reivindicações.

Claims (6)

1. Reivindicações

   1. SISTEMA DE MÓDULO DE PROCESSAMENTO DE COMPUTADOR, com N-rotas de alta integridade, N sendo um número inteiro maior ou igual a dois, o sistema compreendendo:

   um elemento de aplicação hospedada (310) e um elemento de I/O (320) por rota de processamento;

   uma unidade de gerenciamento de tempo (TM) (400) configurada para determinar um valor de tempo equivalente para uma solicitação feita pelo software que funciona em cada uma das N rotas de processamento, independente de quando a solicitação é de fato recebida e age sobre cada uma das N rotas de processamento;

   uma unidade de gerenciamento de regiões críticas (CRM) configurada para possibilitar que as regiões críticas dentro da rota respectiva sejam identificadas e sincronizadas através de todas as N rotas de processamento;

   uma unidade de gerenciamento de entrada de dados (IM) configurada para assegurar que cada rota respectiva receba exatamente o mesmo conjunto de dados de alta integridade, conforme todas as outras N rotas de processamento, e para emitir, de outra forma, uma condição de erro;

   uma unidade de gerenciamento de saída de dados (OM) configurada para determinar se a saída da rota respectiva é exatamente o mesmo conjunto de dados de alta integridade que todas as outras N rotas de processamento, e para emitir, de outra forma, uma condição de erro;

   caracterizado pelas regiões críticas identificadas pelo CRM corresponderem às regiões dentro do software que não podem ser obtidas por preempção por quaisquer outras linhas de execução separados de uma linha de execução que está funcionando.
2. 2. MÓDULO, de acordo com a reivindicação 1, caracterizado

   Petição 870190059930, de 27/06/2019, pág. 38/40

   2/2 pelo TM compreender uma memória temporária extensa 1.
3. 3. MÓDULO, de acordo com a reivindicação 1, caracterizado pelo TM compreender M memórias temporárias extensas 1, M sendo um número inteiro maior ou igual a dois.
4. 4. MÓDULO, de acordo com a reivindicação 1, caracterizado por tanto os dados de alta integridade como os dados de integridade normal fluírem sobre as N rotas de processamento e que somente os dados de alta integridade são operados pelo módulo de alta integridade.
5. 5. MÓDULO, de acordo com a reivindicação 1, caracterizado pelo TM ser implementado como uma máquina de estado finito.
6. 6. MÓDULO, de acordo com a reivindicação 1, caracterizado pelo CRM ser implementado como uma máquina de estado finito.