Diferenças entre tempo real rígido, tempo real flexível e tempo real firme?

Eu li as definições para as diferentes noções de tempo real e os exemplos fornecidos para sistemas de tempo real hard e soft fazem sentido para mim. Porém, não há uma explicação ou exemplo real de um sistema de tempo real firme. De acordo com o link acima:

Empresa: Perdas 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.

Existe uma distinção clara entre o tempo real da empresa e o tempo real do hard ou do soft, e há um bom exemplo que ilustra essa distinção?

Nos comentários, Charles pediu que eu enviasse wikis de tag para as novas tags. O exemplo de um "sistema firme em tempo real" que forneci para ofirme em tempo realtag era um sistema de servir leite. Se o sistema fornecer leite após o tempo de expiração, o leite é considerado "inútil". Pode-se tolerar comer cereal sem leite, mas a qualidade da experiência é degradada.

Esta é apenas a ideia que formei na minha cabeça quando li inicialmente a definição. Estou procurando um exemplo muito melhor e talvez uma definição melhor de empresa em tempo real que melhore minha noção a respeito.

Tempo real difícil significa que você deve cumprir absolutamente todos os prazos. Muito poucos sistemas têm esse requisito. Alguns exemplos são sistemas nucleares, algumas aplicações médicas, como marca-passos, um grande número de aplicações de defesa, aviônica, etc.

Os sistemas de tempo real firmes / suaves podem perder alguns prazos, mas, eventualmente, o desempenho degradará se muitos forem perdidos. Um bom exemplo é o sistema de som do seu computador. Se você perder alguns bits, não é grande coisa, mas perder muitos e eventualmente degradará o sistema. Similares seriam os sensores sísmicos. Se você perder alguns pontos de dados, não é grande coisa, mas você tem que capturar a maioria deles para entender os dados. Mais importante ainda, ninguém vai morrer se não funcionar corretamente.

A linha é confusa, porque até mesmo um marcapasso pode estar um pouco desligado sem matar o paciente, mas essa é a essência geral.

É como a diferença entre quente e morno. Não existe uma divisão real, mas você sabe disso quando a sente.

Hard Real-Time

A definição de tempo real difícil considera qualquer prazo perdido como uma falha do sistema. Esta programação é amplamente utilizada em sistemas de missão crítica, onde a falha em obedecer às restrições de tempo resulta em perda de vidas ou propriedades.

Exemplos:

• O voo 447 da Air France caiu no oceano depois que um mau funcionamento do sensor causou uma série de erros no sistema. Os pilotos estolaram a aeronave enquanto respondiam a leituras de instrumentos desatualizadas. Todos os 12 tripulantes e 216 passageiros morreram.

• A espaçonave Mars Pathfinder foi quase perdida quando uma inversão de prioridade causou reinicializações do sistema. Uma tarefa de prioridade mais alta não foi concluída a tempo devido ao bloqueio por uma tarefa de prioridade mais baixa. O problema foi corrigido e a espaçonave pousou com sucesso.

• Uma impressora jato de tinta possui uma cabeça de impressão com software de controle para depositar a quantidade correta de tinta em uma parte específica do papel. Se um prazo for perdido, o trabalho de impressão será arruinado.

Tempo Real Firme

A definição firme em tempo real permite prazos raramente perdidos. Nessas aplicações, o sistema pode sobreviver a falhas de tarefas, desde que estejam adequadamente espaçadas; no entanto, o valor da conclusão da tarefa cai para zero ou se torna impossível.

Exemplos:

• Sistemas de fabricação com linhas de montagem de robôs em que perder um prazo resulta na montagem inadequada de uma peça. Desde que as peças danificadas não sejam frequentes o suficiente para serem capturadas pelo controle de qualidade e não sejam muito caras, a produção continua.

• Um decodificador de decodificadores de cabo digital para marcações de tempo para quando os quadros devem aparecer na tela. Como os frames são sensíveis à ordem de tempo, um prazo perdido causa instabilidade, diminuindo a qualidade do serviço. Se o quadro perdido ficar disponível mais tarde, ele só causará mais instabilidade para exibi-lo, portanto, é inútil. O visualizador ainda pode aproveitar o programa se o jitter não ocorrer com muita frequência.

Soft Real-Time

A definição de tempo real flexível permite prazos frequentemente perdidos e, desde que as tarefas sejam executadas em tempo hábil, seus resultados continuam a ter valor. Tarefas concluídas podem ter valor crescente até o prazo final e valor decrescente após ele.

Exemplos:

• As estações meteorológicas possuem diversos sensores para leitura de temperatura, umidade, velocidade do vento, etc. As leituras devem ser feitas e transmitidas em intervalos regulares, porém os sensores não são sincronizados. Mesmo que a leitura do sensor possa ser antecipada ou tardia em comparação com as outras, ainda pode ser relevante, desde que esteja perto o suficiente.

• Um console de videogame executa software para um mecanismo de jogo. Existem muitos recursos que devem ser compartilhados entre suas tarefas. Ao mesmo tempo, as tarefas precisam ser concluídas de acordo com a programação para que o jogo seja executado corretamente. Contanto que as tarefas estejam sendo completamente pontuais, o jogo será agradável e, caso contrário, poderá demorar um pouco.

^{Siewert: Sistemas e componentes incorporados em tempo real.
Liu & Layland: Algoritmos de escalonamento para multiprogramação em um ambiente de tempo real rígido.
Marchand & Silly-Chetto: Programação dinâmica de tarefas aperiódicas suaves e tarefas periódicas com saltos.}

Depois de ler a página da Wikipedia e outras páginas sobre computação em tempo real. Eu fiz as seguintes inferências:

1> Para um sistema de tempo real Hard , se o sistema falhar em cumprir o prazo, mesmo depois de o sistema ser considerado com falha.

2> Para um sistema de tempo real Firme , mesmo que o sistema não cumpra o prazo, possivelmente mais de uma vez (ou seja, para várias solicitações), o sistema não é considerado como tendo falhado. Além disso, as respostas para as solicitações (respostas a uma consulta, resultado de uma tarefa, etc.) não valem nada uma vez que o prazo para essa solicitação específica tenha passado ( a utilidade de um resultado é zero após seu prazo ). Um exemplo hipotético pode ser um sistema de previsão de tempestade (se uma tempestade for prevista antes da chegada, o sistema fez seu trabalho; a previsão após o evento já ter acontecido ou quando está acontecendo não tem valor).

3> Para um sistema de tempo real Soft , mesmo se o sistema não cumprir o prazo, possivelmente mais de uma vez (ou seja, para várias solicitações), o sistema não é considerado como tendo falhado. Mas, neste caso, os resultados das requisições não têm valor sem valor para um resultado após seu deadline, não é zero , ao contrário, se degrada com o passar do tempo após o deadline. Ex .: Streaming de áudio e vídeo.

Aqui está um link para um recurso que foi muito útil.

É comum associar uma grande catástrofe à definição de hard real-time, mas isso não é relevante. Qualquer falha em atender a uma restrição rígida de tempo real simplesmente significa que o sistema está quebrado. A gravidade do resultado quando algo é rotulado como "quebrado" não é material para a definição.

Firm e soft simplesmente deixam de ser automaticamente declarados quebrados ao deixar de cumprir um único prazo.

Para um bom exemplo de tempo real rígido, a partir da página vinculada:

Os primeiros sistemas de videogame, como o Atari 2600 e os gráficos vetoriais Cinematronics, tinham requisitos difíceis de tempo real por causa da natureza dos gráficos e do hardware de temporização.

Se algo no loop de geração de vídeo perdesse apenas um único prazo, a tela inteira apresentaria falhas, o que seria intolerável, mesmo que raro. Isso seria um sistema quebrado e você o levaria de volta à loja para um reembolso. Portanto, é difícil em tempo real.

Obviamente, qualquer sistema pode estar sujeito a situações que não pode controlar, então é necessário restringir a definição para estar dentro das condições operacionais esperadas - observando que em aplicações críticas de segurança as pessoas devem se planejar para condições terríveis ("o refrigerante evaporou", " os travões falharam ", mas raramente" o sol explodiu ").

E não podemos esquecer que às vezes há uma condição operacional implícita "enquanto alguém está observando". Se ninguém te vir quebrando as regras (ou se eles quebraram, mas morrem antes de contar para alguém), e ninguém pode provar que você quebrou as regras depois do fato, então é o mesmo que se você nunca quebrasse as regras!

A maneira mais simples de distinguir entre os diferentes tipos de sistemas de tempo real é respondendo à pergunta:

Uma resposta atrasada do sistema (após o prazo) ainda é útil ou não?

Portanto, dependendo da resposta que você obter para esta pergunta, seu sistema pode ser incluído em uma das seguintes categorias:

1. Difícil : Não, e as respostas atrasadas são consideradas uma falha do sistema

Este é o caso em que o não cumprimento do prazo tornará o sistema inutilizável. Por exemplo, o sistema que controla o sistema de airbag do carro deve detectar o acidente e encher rapidamente o saco. Todo o processo leva mais ou menos um vigésimo quinto de segundo. Assim, se o sistema, por exemplo, reagir com 1 segundo de atraso, as consequências podem ser mortais e não haverá benefício em ter a mala cheia depois de o carro já ter batido.

2. Firme : Não, mas respostas atrasadas não são necessárias uma falha do sistema

Este é o caso quando o cumprimento do prazo é tolerável, mas afetará a qualidade do serviço. Como um exemplo simples, considere um sistema de criptografia de vídeo. Normalmente a senha de criptografia é gerada no servidor (Head end de vídeo) e enviada para o decodificador de sinais do cliente. Este processo deve ser sincronizado para que normalmente o decodificador receba a senhaantes de começar a receber os quadros de vídeo criptografados. Neste caso, um atraso pode levar a falhas de vídeo, uma vez que o decodificador não é capaz de decodificar os frames porque ainda não recebeu a senha. Neste caso, o serviço (filme, um jogo de futebol interessante, etc.) pode ser afetado pelo não cumprimento do prazo. Receber a senha com atraso neste caso não é útil uma vez que os frames criptografados com a mesma já causaram as falhas.

3. Soft : Sim, mas o serviço do sistema está degradado

A partir da descrição da Wikipedia, a utilidade de um resultado diminui após seu prazo . Isso significa que obter uma resposta do sistema fora do prazo ainda é útil para o usuário final, mas sua utilidade diminui após atingir o prazo. Um exemplo simples para este caso é um software que controla automaticamente a temperatura de uma sala (ou edifício). Neste caso, se o sistema tiver alguns atrasos na leitura dos sensores de temperatura, será um pouco lento para reagir a mudanças bruscas de temperatura. Porém, no final ele vai acabar reagindo à mudança e ajustando de acordo a temperatura para mantê-la constante, por exemplo. Portanto, neste caso, a reação retardada é útil, mas degrada a qualidade do serviço do sistema.

Um soft real time é mais fácil de entender, em que mesmo que o resultado seja obtido após o prazo, os resultados ainda são considerados válidos.

Exemplo: Navegador da Web - Solicitamos determinado URL, leva algum tempo para carregar a página. Se o sistema demorar mais do que o esperado para nos fornecer a página, a página obtida não é considerada inválida, apenas dizemos que o desempenho do sistema não correspondeu ao esperado (sistema apresentou baixo desempenho!).

No sistema de tempo real difícil , se o resultado for obtido após o prazo, o sistema é considerado como tendo falhado completamente.

Exemplo: No caso de um robô realizando algum trabalho como rastreamento de linha, etc. Se um obstáculo surgir em seu caminho e o robô não processar essa informação dentro de um prazo programado (quase instantâneo!), O robô falhou em sua tarefa (o sistema do robô também pode ser completamente destruído!).

No sistema de tempo real firme , se o resultado da execução do processo vier após o prazo, descartamos esse resultado, mas o sistema não é considerado como falhado.

Exemplo: comunicação por satélite para monitoramento da posição inimiga ou alguma outra tarefa. Se a estação de computador terrestre para a qual os satélites enviam os quadros periodicamente estiver sobrecarregada, e o quadro atual (pacote) não for processado a tempo e o próximo quadro surgir, o pacote atual (aquele que perdeu o prazo) não importa se o processamento foi concluído (ou feito pela metade ou quase concluído) é descartado / descartado. Mas o computador terrestre não é considerado como tendo falhado completamente.

Para definir "soft real-time", é mais fácil compará-lo com "hard real-time". A seguir, veremos que o termo "tempo real da empresa" constitui um mal-entendido sobre "tempo real suave".

Falando casualmente, a maioria das pessoas implicitamente tem um modelo mental informal que considera a informação ou um evento como sendo "em tempo real"

• se, ou na medida em que, se manifestar a eles com um atraso (latência) que pode estar relacionado à sua moeda percebida

• ou seja, em um período de tempo em que a informação ou evento tenha valor aceitavelmente satisfatório para eles.

Existem várias definições ad hoc diferentes de "tempo real rígido", mas nesse modelo mental, tempo real rígido é representado pelo termo "se". Especificamente, supondo que as ações em tempo real (como tarefas) tenham prazos de conclusão, o valor aceitavelmente satisfatório do evento em que todas as tarefas concluídas é limitado ao caso especial de todas as tarefas cumprirem seus prazos.

Os sistemas hard real-time fazem suposições muito fortes de que tudo sobre o aplicativo, o sistema e o ambiente é estático e conhecido a 'priori - por exemplo, quais tarefas, que são periódicas, seus horários de chegada, seus períodos, seus prazos, que eles venceram não tem conflitos de recursos e, em geral, a evolução do tempo do sistema. Em um sistema de controle de voo de aeronave ou sistema de frenagem automotiva e em muitos outros casos, essas suposições podem geralmente ser satisfeitas para que todos os prazos sejam cumpridos.

Este modelo mental é deliberadamente e muito utilmente geral o suficiente para abranger hard e soft em tempo real - soft é acomodado pela frase "na medida em que". Por exemplo, suponha que o evento de conclusão da tarefa tenha um valor abaixo do ideal, mas aceitável se

• não mais que 10% das tarefas perdem seus prazos
• ou nenhuma tarefa atrasa mais de 20%
• ou o atraso médio de todas as tarefas não é mais do que 15%
• ou o atraso máximo entre todas as tarefas é inferior a 10%

Todos esses são exemplos comuns de casos soft em tempo real em muitas aplicações.

Considere a aplicação de uma única tarefa de pegar seu filho depois da escola. Isso provavelmente não tem um prazo real, em vez disso, há algum valor para você e seu filho com base em quando o evento ocorre. Muito cedo desperdiça recursos (como seu tempo) e muito tarde tem algum valor negativo porque seu filho pode ser deixado sozinho e potencialmente em perigo (ou pelo menos ser incomodado).

Ao contrário do caso especial de tempo real rígido estático, o tempo real soft faz apenas as suposições específicas de aplicativos mínimas necessárias sobre as tarefas e o sistema, e incertezas são esperadas. Para pegar seu filho, você tem que dirigir até a escola e o tempo para fazer isso é dinâmico, dependendo do clima, das condições do tráfego, etc. Você pode ficar tentado a provisionar demais o seu sistema (ou seja, permitir o que você espera que seja o pior caso, tempo de condução), mas, novamente, isso está desperdiçando recursos (seu tempo e ocupando o veículo da família, possivelmente negando o uso por outros membros da família).

Esse exemplo pode não parecer caro em termos de desperdício de recursos, mas considere outros exemplos. Todos os sistemas de combate militar são suaves em tempo real. Por exemplo, considere realizar um ataque de aeronave a um veículo terrestre hostil usando um míssil guiado com atualizações à medida que o alvo manobra. A satisfação máxima para completar as tarefas de atualização do curso é alcançada por um ataque destrutivo direto no alvo. Mas uma tentativa de provisionar recursos em excesso para garantir esse resultado costuma ser muito cara e pode até ser impossível. Nesse caso, você pode ficar menos, mas suficientemente satisfeito se o míssil atingir perto o suficiente do alvo para desativá-lo.

Obviamente, os cenários de combate têm muitas incertezas dinâmicas possíveis que devem ser acomodadas pelo gerenciamento de recursos. Os sistemas soft em tempo real também são muito comuns em muitos sistemas civis, como a automação industrial, embora, obviamente, os militares sejam os mais perigosos e urgentes para se obter um valor aceitável e satisfatório em.

A pedra angular dos sistemas de tempo real é a "previsibilidade". O caso de tempo real difícil está interessado em apenas um caso especial de previsibilidade - ou seja, que todas as tarefas cumprirão seus prazos e o valor máximo possível será alcançado por aquele evento. Esse caso especial é denominado "determinístico".

Existe um espectro de previsibilidade. Determinística (determinismo) é um ponto final (previsibilidade máxima) no espectro de previsibilidade; o outro ponto final é a previsibilidade mínima (não determinismo máximo). A métrica e os pontos finais do espectro devem ser interpretados em termos de um modelo de previsibilidade escolhido; tudo entre esses dois pontos finais são graus de imprevisibilidade (= graus de não determinismo).

A maioria dos sistemas de tempo real (ou seja, os soft) têm previsibilidade não determinística, por exemplo, dos tempos de conclusão das tarefas e, portanto, dos valores obtidos a partir desses eventos.

Em geral (em teoria), a previsibilidade e, portanto, o valor aceitavelmente satisfatório, pode ser feita tão perto do ponto final determinístico quanto necessário - mas a um preço que pode ser fisicamente impossível ou excessivamente caro (como em combate ou talvez até mesmo em pegar seu filho na escola).

O soft real-time requer uma escolha específica do aplicativo de um modelo de probabilidade (não o modelo frequentista comum) e, portanto, o modelo de previsibilidade para raciocinar sobre latências de eventos e valores resultantes.

Voltando à lista de eventos acima que fornecem um valor aceitável, agora podemos adicionar casos não determinísticos, como

• a probabilidade de que nenhuma tarefa perca seu prazo por mais de 5% é maior que 0,87. (Observe o número de critérios de programação expressos lá.)

Em uma aplicação de defesa antimísseis, dado o fato de que no combate o ataque sempre leva vantagem sobre a defesa, qual destes dois cenários de computação em tempo real você prefere:

• porque a destruição perfeita de todos os mísseis hostis é muito improvável ou impossível, atribua seus recursos defensivos para maximizar a probabilidade de que tantos dos mísseis hostis mais ameaçadores (por exemplo, com base em seus alvos) sejam interceptados com sucesso (interceptação próxima conta porque pode mover o míssil hostil para fora do curso);

• Reclame que este não é um problema de computação em tempo real porque é dinâmico em vez de estático, e os conceitos e técnicas tradicionais de tempo real não se aplicam e parece mais difícil do que estática em tempo real rígido, então você não está interessado nisso .

Apesar dos vários mal-entendidos sobre o tempo real soft na comunidade de computação em tempo real, o tempo real soft é muito geral e poderoso, embora potencialmente complexo em comparação com o tempo real rígido. Os sistemas soft em tempo real resumidos aqui têm uma longa história de sucesso de uso fora da comunidade de computação em tempo real .

Para responder diretamente à pergunta do OP:

Um sistema rígido em tempo real pode fornecer garantias determinísticas - mais comumente que todas as tarefas cumprirão seus prazos, a interrupção ou o tempo de resposta da chamada do sistema será sempre menor que x, etc. - SE E SOMENTE SE suposições muito fortes forem feitas e estiverem corretas tudo o que importa é estático e conhecido a 'priori (em geral, tais garantias para sistemas de tempo real hard são um problema de pesquisa aberto, exceto para casos bastante simples)

Um sistema soft real-time não oferece garantias determinísticas, ele se destina a fornecer a melhor pontualidade probabilística analiticamente especificada e realizada e a previsibilidade de oportunidade que são viáveis ​​nas atuais circunstâncias dinâmicas, de acordo com critérios específicos da aplicação.

Obviamente, o tempo real de disco rígido é um caso especial simples de tempo real flexível. Obviamente, as garantias analíticas não determinísticas soft em tempo real podem ser muito complexas de fornecer, mas são obrigatórias nos casos de tempo real mais comuns (incluindo os mais perigosos de segurança crítica, como combate), uma vez que a maioria dos casos em tempo real são dinâmicos, não estático.

"Firm real-time" é um caso especial mal definido de "soft real-time". Não há necessidade desse termo se o termo "soft real-time" for entendido e usado corretamente.

Eu tenho uma discussão mais detalhada e muito mais precisa de tempo real, tempo real rígido, tempo real flexível, previsibilidade, determinismo e tópicos relacionados em meu site real-time.org.

tempo real - Pertencente a um sistema ou modo de operação em que a computação é realizada durante o tempo real em que ocorre um processo externo, para que os resultados da computação possam ser usados ​​para controlar, monitorar ou responder ao processo externo em tempo maneira. [Padrão IEEE 610.12.1990]

Eu sei que essa definição é antiga, muito antiga. Não consigo, no entanto, encontrar uma definição mais recente do IEEE (Institute of Electrical and Electronics Engineers).

Considere uma tarefa que insere dados da porta serial. Quando novos dados chegam, a porta serial dispara um evento. Quando o software atende a esse evento, ele lê e processa os novos dados. A porta serial tem um hardware para armazenar dados de entrada (2 no MSP432, 16 no TM4C123) de forma que se o buffer estiver cheio e mais dados chegarem, os novos dados serão perdidos. Este sistema é rígido, firme ou flexível em tempo real?

É difícil em tempo real porque se a resposta atrasar, os dados podem ser perdidos.

Considere um aparelho auditivo que insere sons de um microfone, manipula os dados de som e, em seguida, envia os dados para um alto-falante. O sistema geralmente apresenta jitter pequeno e limitado, mas ocasionalmente outras tarefas no aparelho auditivo fazem com que alguns dados atrasem, causando um pulso de ruído no alto-falante. Este sistema é rígido, firme ou suave em tempo real?

É firme em tempo real porque causa um erro que pode ser percebido, mas o efeito é inofensivo e não altera significativamente a qualidade da experiência.

Considere uma tarefa que envia dados para uma impressora. Quando a impressora está ociosa, ela dispara um evento. Quando o software atende a esse evento, ele envia mais dados para a impressora. Este sistema é rígido, firme ou suave em tempo real?

É um tempo real suave porque quanto mais rápido ele responde, melhor, mas o valor do sistema (largura de banda é a quantidade de dados impressos por segundo) diminui com a latência.

UTAustinX: UT.RTBN.12.01x Redes Bluetooth em tempo real

Talvez a definição esteja errada.

Pela minha experiência, eu separaria os dois como sendo dependentes de hardware e software.

Se você tem 200 ms para atender a uma interrupção orientada por hardware, é isso que você tem. Você coloca 300ms de código ali e o sistema não está quebrado, não foi desenvolvido. Você será desligado antes de terminar. Seu código não funciona ou não é adequado para o propósito. Muitos sistemas têm períodos de processamento definidos de forma rígida. Vídeo, telecomunicações etc.

Se você estiver escrevendo um aplicativo em tempo real, isso pode ser considerado suave . Se o tempo acabar, você pode esperar menos carga da próxima vez, pode ajustar o sistema operacional, adicionar um pouco de memória ou até mesmo atualizar o hardware. Você tem opções.

Olhar para isso de uma perspectiva UX não é útil. Um Skoda pode não estar quebrado se falhar, mas um BMW com certeza estará.

A definição foi se expandindo ao longo dos anos em detrimento do termo. O que agora é chamado de tempo real "difícil" é o que costumava ser chamado simplesmente de tempo real. Portanto, os sistemas nos quais as janelas de tempo perdidas (em vez de prazos de tempo unilaterais) resultariam em dados incorretos ou comportamento incorreto devem ser considerados em tempo real. Sistemas sem essa característica seriam considerados não em tempo real.

Isso não quer dizer que o tempo não seja de interesse em sistemas de tempo não real, apenas significa que os requisitos de tempo em tais sistemas não resultam em resultados fundamentalmente incorretos.

Os sistemas de tempo real rígido usam a versão preemptiva do agendamento de prioridade, de modo que as tarefas críticas sejam agendadas imediatamente, enquanto os sistemas de tempo real soft usam a versão não preemptiva do agendamento de prioridade, o que permite que a tarefa atual seja concluída antes que o controle seja transferido para a prioridade mais alta tarefa, causando atrasos adicionais. Assim, os prazos das tarefas são seguidos de forma crítica em sistemas de tempo real Hard, enquanto em sistemas de tempo real soft eles não são tratados com tanta seriedade.