Computação em tempo real - Real-time computing

A computação em tempo real ( RTC ) é o termo da ciência da computação para sistemas de hardware e software sujeitos a uma "restrição de tempo real", por exemplo, de evento a resposta do sistema . Os programas em tempo real devem garantir a resposta dentro das restrições de tempo especificadas, geralmente chamadas de "prazos".

As respostas em tempo real costumam ser da ordem de milissegundos e, às vezes, de microssegundos. Um sistema não especificado como operando em tempo real geralmente não pode garantir uma resposta dentro de qualquer período de tempo, embora possam ser dados tempos de resposta típicos ou esperados . O processamento em tempo real falha se não for concluído dentro de um prazo especificado em relação a um evento; os prazos devem ser sempre cumpridos, independentemente da carga do sistema .

Um sistema em tempo real foi descrito como aquele que "controla um ambiente recebendo dados, processando-os e retornando os resultados com rapidez suficiente para afetar o ambiente naquele momento". O termo "tempo real" também é usado na simulação para significar que o relógio da simulação funciona na mesma velocidade que um relógio real, e no controle de processos e sistemas corporativos significa "sem atraso significativo".

O software em tempo real pode usar um ou mais dos seguintes: linguagens de programação síncronas , sistemas operacionais em tempo real e redes em tempo real, cada um dos quais fornece estruturas essenciais nas quais construir um aplicativo de software em tempo real.

Os sistemas usados ​​para muitas aplicações de missão crítica devem ser em tempo real, como para o controle de aeronaves fly-by-wire ou freios antibloqueio , os quais exigem resposta mecânica imediata e precisa.

História

O termo tempo real deriva de seu uso na simulação inicial , na qual um processo do mundo real é simulado a uma taxa que correspondeu à do processo real (agora chamada de simulação em tempo real para evitar ambigüidade). Os computadores analógicos , na maioria das vezes, eram capazes de simular em um ritmo muito mais rápido do que em tempo real, uma situação que poderia ser tão perigosa quanto uma simulação lenta se não fosse também reconhecida e considerada.

Minicomputadores, particularmente na década de 1970 em diante, quando construídos em sistemas embarcados dedicados , como scanners DOG ( Digital on-screen graphic ), aumentaram a necessidade de respostas orientadas por prioridade de baixa latência para interações importantes com dados de entrada e, portanto, sistemas operacionais como Data geral 's RDOS (real-Time Disk Operating System) e RTOS com fundo e agendamento de primeiro plano , bem como digital Equipment Corporation ' s RT-11 datam desta época. O agendamento em primeiro plano permitia tempo de CPU de tarefas de baixa prioridade quando nenhuma tarefa em primeiro plano precisava ser executada, e dava prioridade absoluta em primeiro plano para threads / tarefas com a prioridade mais alta. Os sistemas operacionais em tempo real também seriam usados ​​para tarefas multiusuário de time-sharing . Por exemplo, o Data General Business Basic poderia ser executado em primeiro ou segundo plano de RDOS e introduziria elementos adicionais ao algoritmo de agendamento para torná-lo mais apropriado para pessoas interagindo por meio de terminais burros .

Uma vez, quando o MOS Technology 6502 (usado no Commodore 64 e Apple II ), e mais tarde quando o Motorola 68000 (usado no Macintosh , Atari ST e Commodore Amiga ) eram populares, qualquer pessoa podia usar seu computador doméstico como um computador em tempo real sistema. A possibilidade de desativar outras interrupções permitidas para loops codificados com temporização definida, e a baixa latência de interrupção permitiu a implementação de um sistema operacional em tempo real, dando à interface do usuário e às unidades de disco menor prioridade do que a thread em tempo real. Comparado a estes, o controlador de interrupção programável das CPUs Intel (8086..80586) gera uma latência muito grande e o sistema operacional Windows não é um sistema operacional em tempo real nem permite que um programa controle a CPU completamente e use seu próprio planejador , sem usar linguagem de máquina nativa e, portanto, superando todos os códigos de interrupção do Windows. No entanto, existem várias bibliotecas de codificação que oferecem recursos de tempo real em uma linguagem de alto nível em uma variedade de sistemas operacionais, por exemplo Java Real Time . O Motorola 68000 e os membros da família subsequentes (68010, 68020 etc.) também se tornaram populares entre os fabricantes de sistemas de controle industrial. Esta área de aplicação é aquela em que o controle em tempo real oferece vantagens genuínas em termos de desempenho e segurança do processo.

Critérios para computação em tempo real

Diz - se que um sistema está em tempo real se a exatidão total de uma operação depende não apenas de sua exatidão lógica, mas também do tempo em que ela é executada. Os sistemas de tempo real, bem como seus prazos, são classificados pela consequência do não cumprimento de um prazo:

  • Difícil  - perder um prazo é uma falha total do sistema.
  • Firme  - faltas de prazo não frequentes são toleráveis, mas podem degradar a qualidade de serviço do sistema. A utilidade de um resultado é zero após seu prazo.
  • Soft  - a utilidade de um resultado diminui após seu prazo, degradando a qualidade de serviço do sistema.

Assim, o objetivo de um sistema de tempo real rígido é garantir que todos os prazos sejam cumpridos, mas para sistemas de tempo real flexível o objetivo passa a ser o cumprimento de um determinado subconjunto de prazos, a fim de otimizar alguns critérios específicos do aplicativo. Os critérios específicos otimizados dependem da aplicação, mas alguns exemplos típicos incluem a maximização do número de prazos atendidos, minimizando o atraso das tarefas e maximizando o número de tarefas de alta prioridade atendendo seus prazos.

Os sistemas hard real-time são usados ​​quando é imperativo que um evento seja reagido dentro de um prazo estrito. Essas fortes garantias são exigidas de sistemas para os quais não reagir em um determinado intervalo de tempo causaria grandes perdas de alguma maneira, especialmente danificando os arredores fisicamente ou ameaçando vidas humanas (embora a definição estrita seja simplesmente que perder o prazo constitui falha do sistema ) Alguns exemplos de sistemas de tempo real hard:

  • O sistema de controle do motor de um carro é um sistema rígido em tempo real porque um sinal atrasado pode causar falha ou dano no motor.
  • Sistemas médicos, como marcapassos cardíacos . Mesmo que a tarefa de um marcapasso seja simples, por causa do risco potencial para a vida humana, sistemas médicos como esses normalmente são submetidos a testes e certificação completos, o que por sua vez requer computação em tempo real difícil para oferecer garantias prováveis ​​de que uma falha é improvável ou impossível.
  • Controladores de processos industriais, como uma máquina em uma linha de montagem . Se a máquina atrasar, o item na linha de montagem pode ficar fora do alcance da máquina (deixando o produto intocado), ou a máquina ou o produto pode ser danificado ao ativar o robô no momento errado. Se a falha for detectada, ambos os casos levariam à parada da linha de montagem, o que retarda a produção. Se a falha não for detectada, um produto com defeito pode passar pela produção ou pode causar danos em etapas posteriores da produção.
  • Os sistemas de tempo real hard normalmente são encontrados interagindo em um baixo nível com o hardware físico, em sistemas embarcados . Os primeiros sistemas de videogame, como o Atari 2600 e os gráficos vetoriais Cinematronics, tinham requisitos difíceis de tempo real devido à natureza dos gráficos e do hardware de temporização.
  • Softmodems substituem um modem de hardware por software executado na CPU de um computador. O software deve ser executado a cada poucos milissegundos para gerar os próximos dados de áudio a serem produzidos. Se esses dados estiverem atrasados, o modem receptor perderá a sincronização, causando uma longa interrupção quando a sincronização for restabelecida ou fazendo com que a conexão seja totalmente perdida.
  • Muitos tipos de impressoras têm requisitos rígidos de tempo real, como jato de tinta (a tinta deve ser depositada no momento correto quando a cabeça de impressão cruza a página), impressoras a laser (o laser deve ser ativado no momento certo enquanto o feixe varre o tambor rotativo), e matriciais e vários tipos de impressoras de linha (o mecanismo de impacto deve ser ativado no momento certo, pois o mecanismo de impressão fica alinhado com a saída desejada). Uma falha em qualquer um deles causaria a falta de saída ou a saída desalinhada.

No contexto de sistemas multitarefa , a política de agendamento é normalmente orientada por prioridade ( agendadores preventivos ). Em algumas situações, isso pode garantir um desempenho difícil em tempo real (por exemplo, se o conjunto de tarefas e suas prioridades forem conhecidos com antecedência). Existem outros agendadores de tempo real, como o monotônico de taxa, que não é comum em sistemas de uso geral, pois requer informações adicionais para agendar uma tarefa: a saber, uma estimativa limitada ou de pior caso de quanto tempo a tarefa deve ser executada . Existem algoritmos específicos para agendar tais tarefas difíceis em tempo real, como o prazo mais cedo primeiro , que, ignorando a sobrecarga da troca de contexto , é suficiente para cargas do sistema de menos de 100%. Novos sistemas de agendamento de sobreposição, como um agendador de partição adaptável, auxiliam no gerenciamento de grandes sistemas com uma mistura de aplicativos em tempo real e não em tempo real.

Os sistemas de tempo real firmes são definidos de forma mais nebulosa e algumas classificações não os incluem, distinguindo apenas sistemas de tempo real hard e soft. Alguns exemplos de sistemas de empresa em tempo real:

  • A máquina de linha de montagem descrita anteriormente como hard real-time poderia, em vez disso, ser considerada em tempo real firme . Um prazo perdido ainda causa um erro que precisa ser resolvido: pode haver um maquinário para marcar uma peça como defeituosa ou ejetá-la da linha de montagem, ou a linha de montagem pode ser interrompida para que um operador possa corrigir o problema. No entanto, enquanto esses erros não forem frequentes, eles podem ser tolerados.

Os sistemas de tempo real soft são normalmente usados ​​para resolver problemas de acesso simultâneo e a necessidade de manter vários sistemas conectados atualizados em situações de mudança. Alguns exemplos de sistemas soft em tempo real:

  • Software que mantém e atualiza os planos de vôo de aviões comerciais . Os planos de vôo devem ser mantidos razoavelmente atualizados, mas podem operar com a latência de alguns segundos.
  • Os sistemas de áudio e vídeo ao vivo também costumam ser em tempo real suave. Um quadro de áudio que é reproduzido atrasado pode causar uma breve falha de áudio (e pode fazer com que todo o áudio subsequente seja atrasado de forma correspondente, causando a percepção de que o áudio está sendo reproduzido mais lentamente do que o normal), mas isso pode ser melhor do que as alternativas de continuar reproduzir silêncio, estática, um quadro de áudio anterior ou dados estimados. Um quadro de vídeo que está atrasado normalmente causa ainda menos interrupções para os espectadores. O sistema pode continuar operando e também se recuperando no futuro usando metodologias de previsão e reconfiguração de carga de trabalho.
  • Da mesma forma, os videogames costumam ser suaves em tempo real, principalmente quando tentam atingir uma taxa de quadros alvo . Como a próxima imagem não pode ser computada com antecedência, pois depende de entradas do player, apenas um curto período de tempo está disponível para realizar toda a computação necessária para gerar um quadro de vídeo antes que esse quadro seja exibido. Se o prazo for perdido, o jogo pode continuar com uma taxa de quadros inferior; dependendo do jogo, isso pode afetar apenas seus gráficos (enquanto o jogo continua na velocidade normal), ou a jogabilidade em si pode ficar mais lenta (o que era comum em consoles de terceira e quarta gerações mais antigos ).

Tempo real em processamento de sinal digital

Em um processo de processamento de sinal digital em tempo real (DSP), as amostras analisadas (entrada) e geradas (saída) podem ser processadas (ou geradas) continuamente no tempo que leva para a entrada e saída do mesmo conjunto de amostras independente do processamento atraso. Isso significa que o atraso de processamento deve ser limitado mesmo se o processamento continuar por um tempo ilimitado. Isso significa que o tempo médio de processamento por amostra, incluindo overhead , não é maior do que o período de amostragem, que é o recíproco da taxa de amostragem . Este é o critério se as amostras são agrupadas em grandes segmentos e processadas como blocos ou são processadas individualmente e se há buffers de entrada e saída longos, curtos ou inexistentes .

Considere um exemplo de DSP de áudio ; se um processo requer 2,01 segundos para analisar , sintetizar ou processar 2,00 segundos de som, não é em tempo real. No entanto, se demorar 1,99 segundos, é ou pode ser transformado em um processo DSP em tempo real.

Uma analogia de vida comum é ficar em uma fila ou fila esperando o caixa em uma mercearia. Se a linha ficar cada vez mais comprida assintoticamente sem limites, o processo de verificação não ocorre em tempo real. Se o comprimento da linha for limitado, os clientes estão sendo "processados" e produzidos com a mesma rapidez, em média, à medida que são inseridos, o processo é em tempo real. O dono da mercearia pode fechar ou deve, pelo menos, perder negócios se não puder fazer o processo de checkout em tempo real; portanto, é fundamentalmente importante que esse processo seja em tempo real.

Um algoritmo de processamento de sinal que não consegue acompanhar o fluxo de dados de entrada com a saída ficando cada vez mais para trás da entrada não é em tempo real. Mas se o atraso da saída (em relação à entrada) é limitado em relação a um processo que opera por um tempo ilimitado, então esse algoritmo de processamento de sinal é em tempo real, mesmo que o atraso de throughput possa ser muito longo.

Ao vivo x tempo real

O processamento de sinal em tempo real é necessário, mas não suficiente por si só, para processamento de sinal ao vivo, como o que é exigido no suporte a eventos ao vivo . O processamento de sinal digital de áudio ao vivo requer operação em tempo real e um limite suficiente para o atraso de rendimento de modo a ser tolerável para os artistas usando monitores de palco ou monitores intra-auriculares e não perceptível como erro de sincronização labial pelo público também assistindo diretamente os artistas. Limites toleráveis ​​de latência para processamento ao vivo em tempo real é um assunto de investigação e debate, mas é estimado entre 6 e 20 milissegundos.

Atrasos de telecomunicações bidirecionais em tempo real de menos de 300 ms ("ida e volta" ou duas vezes o atraso unidirecional) são considerados "aceitáveis" para evitar "conversa" indesejada na conversa.

Tempo real e alto desempenho

A computação em tempo real às vezes é mal interpretada como computação de alto desempenho , mas esta não é uma classificação precisa. Por exemplo, um supercomputador enorme executando uma simulação científica pode oferecer um desempenho impressionante, mas não está executando uma computação em tempo real. Por outro lado, uma vez que o hardware e o software para um sistema de frenagem antibloqueio foram projetados para cumprir os prazos exigidos, nenhum ganho de desempenho adicional é obrigatório ou mesmo útil. Além disso, se um servidor de rede estiver altamente carregado com tráfego de rede, seu tempo de resposta pode ser mais lento, mas (na maioria dos casos) ainda terá sucesso antes de atingir o tempo limite (atingir seu prazo). Conseqüentemente, tal servidor de rede não seria considerado um sistema de tempo real: falhas temporais (atrasos, tempos limite etc.) são tipicamente pequenas e compartimentadas (com efeito limitado), mas não são falhas catastróficas . Em um sistema em tempo real, como o Índice FTSE 100 , uma desaceleração além dos limites costuma ser considerada catastrófica em seu contexto de aplicação. O requisito mais importante de um sistema em tempo real é uma saída consistente, não uma alta produtividade.

Alguns tipos de software, como muitos programas para jogar xadrez , podem se enquadrar em qualquer uma das categorias. Por exemplo, um programa de xadrez projetado para jogar em um torneio com um relógio precisará decidir sobre uma jogada antes de um determinado prazo ou perderá o jogo e, portanto, é um cálculo em tempo real, mas um programa de xadrez que pode ser executado indefinidamente antes de se mover não é. Em ambos os casos, no entanto, o alto desempenho é desejável: quanto mais trabalho um programa de xadrez de torneio puder fazer no tempo designado, melhores serão seus movimentos, e quanto mais rápido um programa de xadrez sem restrições for executado, mais cedo ele será capaz de mover. Este exemplo também ilustra a diferença essencial entre cálculos em tempo real e outros cálculos: se o programa de xadrez do torneio não tomar uma decisão sobre seu próximo movimento no tempo alocado, ele perde o jogo - ou seja, falha como um cálculo em tempo real - enquanto no outro cenário, o cumprimento do prazo é considerado desnecessário. O alto desempenho é indicativo da quantidade de processamento executada em um determinado período de tempo, enquanto o tempo real é a capacidade de concluir o processamento para produzir uma saída útil no tempo disponível.

Quase em tempo real

O termo "quase em tempo real" ou "quase em tempo real" (NRT), em telecomunicações e computação , refere-se ao intervalo de tempo introduzido, por processamento automatizado de dados ou transmissão de rede , entre a ocorrência de um evento e o uso do dados processados, como para fins de exibição ou feedback e controle. Por exemplo, uma exibição quase em tempo real representa um evento ou situação tal como existia na hora atual menos o tempo de processamento, quase o tempo do evento ao vivo.

A distinção entre os termos "quase em tempo real" e "tempo real" é um tanto nebulosa e deve ser definida para a situação em questão. O termo implica que não há atrasos significativos. Em muitos casos, o processamento descrito como "tempo real" seria mais precisamente descrito como "quase em tempo real".

Quase em tempo real também se refere ao atraso na transmissão em tempo real de voz e vídeo. Permite reproduzir imagens de vídeo, aproximadamente em tempo real, sem ter que esperar o download de um grande arquivo de vídeo inteiro. Bancos de dados incompatíveis podem exportar / importar para arquivos simples comuns que o outro banco de dados pode importar / exportar em uma base programada para que eles possam sincronizar / compartilhar dados comuns "quase em tempo real" uns com os outros.

A distinção entre "quase em tempo real" e "tempo real" varia, e o atraso depende do tipo e da velocidade da transmissão. O atraso quase em tempo real é normalmente de 1 a 10 segundos.

Métodos de design

Existem vários métodos para auxiliar o projeto de sistemas de tempo real, um exemplo dos quais é o MASCOT , um método antigo, mas muito bem-sucedido, que representa a estrutura simultânea do sistema. Outros exemplos são HOOD , Real-Time UML, AADL , o perfil Ravenscar e Real-Time Java .

Veja também

Referências

Leitura adicional

links externos