Sistema operacional de tempo real – Wikipédia, a enciclopédia livre

 Nota: "STR" redireciona para este artigo. Para a equipe italiana de F-1, veja Scuderia Toro Rosso.

Esta página cita fontes, mas que não cobrem todo o conteúdo. Ajude a inserir referências (Encontre fontes: ABW  • CAPES  • Google (N • L • A)). (Setembro de 2020)

As referências deste artigo necessitam de formatação. Por favor, utilize fontes apropriadas contendo título, autor e data para que o verbete permaneça verificável. (Dezembro de 2013)

Um Sistema operativo em tempo real ^{(português europeu)} ou Sistema operacional de tempo real ^{(português brasileiro)} (RTOS da sigla anglo-saxónica Real Time Operating System) é um sistema operacional/operativo destinado à execução de múltiplas tarefas onde o tempo de resposta a um evento (externo ou interno) é pré-definido; não importando, como é comum pensar-se, se a velocidade de resposta é elevada ou não. Esse tempo de resposta é chamado de prazo da tarefa e a perda de um prazo, isto é, o não cumprimento de uma tarefa dentro do prazo esperado, caracteriza uma falha do sistema. Outra característica dos sistemas de tempo real é a sua interação com o meio ao redor. Os STR tem que reagir, dentro de um prazo pré-definido, a um estímulo do meio. Por exemplo, em um hospital, o sistema que monitora os batimentos cardíacos de um paciente deve avisar os médicos caso haja alteração nos batimentos. Outro aspecto importante dos STR é a previsibilidade. O sistema é considerado previsível quando podemos antecipar seu comportamento independentemente de falhas, sobrecargas e variações de hardware.

Um RTOS facilita a concepção de um sistema em tempo real, mas não garante que o resultado final seja um sistema de tempo real, para tal é necessário que o programa nele implementado tenha sido corretamente desenvolvido. Um RTOS não tem que ter necessariamente um elevado débito nas saídas, ou um elevado número de saídas, no entanto, tem que garantir que certas tarefas sejam executadas em um determinado intervalo de tempo. Um RTOS é mais eficaz e é mais valorizado pela forma previsível e rápida na resposta a um evento, do que pela quantidade de dados que processa. Os fatores chave em um STR são, então, fornecer latências de interrupções e de alternância de tarefas mínimas.

Existem tipicamente duas arquiteturas:

O desenho baseado no evento, ou escalonamento prioritário, alterna as tarefas somente, quando uma tarefa de maior prioridade necessita de ser executada, denominando-se preemptividade.

O desenho baseado na partilha de tempo alterna as tarefas segundo os tiques do relógio do processador.

O desenho que se baseia na partilha de tempo, alterna entre tarefas mais frequentemente daquilo que é realmente necessário, no entanto dá a estas a ilusão de terem o monopólio do processador.

Os processadores mais antigos, necessitavam de muitos ciclos de relógio para alternarem entre tarefas, sendo que nesse intervalo de tempo não executavam nada. Então os RTOS dessa época tentavam minimizar o desperdício de tempo do processador através da diminuição de alternância entre tarefas. Os processadores mais recentes demoram muito menos tempo para mudarem de uma tarefa para outra. Quase todos os RTOS de hoje em dia implementam uma junção destes dois tipos de desenhos.

Como os demais sistemas operacionais, os RTOS têm uma fila onde se inserem todas as tarefas que estão prontas para serem executadas. Essa lista é conhecida como fila de prontos.

Os algoritmos de escalonamento desses sistemas visam, principalmente, satisfazer os requisitos temporais dos comandos dados pelo usuário. Como cada sistema implementa, na maioria das vezes, algoritmos de escalonamento diferentes, alguns são aptos para determinadas tarefas enquanto outros são melhores para outras aplicações. O RTLinux, utilizado nas indústrias para controle e automação, permite que um programador escreva seu próprio algoritmo de escalonamento.

Os algoritmos de escalonamento dos STR podem ser classificados em estáticos e dinâmicos. O primeiro é utilizado apenas em situações onde o trabalho a ser realizado e seus requisitos temporais são conhecidos previamente. O algoritmo estático mais implementado é o escalonamento por taxas monotônicas (rate monotonic scheduling – RMS).

O RMS atribui prioridades aos processos dependendo do número de vezes que eles serão executados por segundo. Quanto maior a frequência de execução, maior a prioridade. O escalonamento por taxas monotônicas é preemptivo.

Os algoritmos de escalonamento dinâmicos não atribuem prioridades fixas aos processos. As decisões de escalonamento são tomadas em tempo de execução e as prioridades dos processos podem mudar. Os critérios para essas decisões variam de algoritmo para algoritmo. O algoritmo de escalonamento dinâmico mais utilizado é o “prazo mais curto primeiro” (Earliest Deadline First – EDF).

O EDF escolhe na fila de prontos o processo que tenha o prazo de vencimento mais curto. Se chegar na fila um processo que tenha um prazo menor ainda, ocorrerá preempção. Ao contrário do RMS, o EDF não necessita que os processos sejam periódicos. O EDF tem a grande vantagem de ser capaz de manter a CPU todo o tempo ocupada; porém o algoritmo é extremamente complexo.

Os STR são classificados, basicamente, em:

- Críticos (hard RTS - também chamados de rígidos)

- Não-Críticos (soft RTS - também chamados de moderados)

A severidade da pena pelo não cumprimento das tarefas num determinado intervalo de tempo é o fator que os distingüe.

O STR Crítico é aquele que tem um comportamento determinístico, ou seja, o prazo para execução de uma tarefa (deadline) não pode ser violado. Se o sistema de um freio ABS, por exemplo, falhar ou demorar demais para responder, uma pessoa poderá se machucar. Essa classe de STR tem que ser ultra confiável, ou seja, o tempo médio entre falhas tem que ser maior que 10 elevado a 9 horas. Outros exemplos de STR Rígido são: o sistema embarcado de navegação de uma aeronave, o sistema embarcado de proteção de linhas de alta tensão. Em ambos os exemplos, se o sistema falhar, pessoas poderão se machucar.

O STR Não-Crítico é aquele que também tem o tempo como parâmetro fundamental, mas uma falha é aceitável. O sistema que funciona em um leitor de DVD não é crítico, pois o não cumprimento de uma tarefa em resposta e um evento em um determinado intervalo de tempo não provoca danos irreversíveis. Ao contrário dos sistemas críticos, esses sistemas normalmente trabalham com um grande volume de dados.

Em um STR rígido os cálculos efetuados pelo processador depois de findado o prazo da tarefa são pouco ou nada úteis; já nos STR moderados a utilidade dos dados lidos pelo processador e dos cálculos efetuados não é considerada nula depois do prazo da tarefa terminar

Os RTS rígidos são inflexíveis, pois o prazo da tarefa (deadline) não pode ser ultrapassado. Já os RTS moderados oferecem alguma flexibilidade no não cumprimento de prazos das tarefas que executam. Em um RTS moderado pode-se efetuar um cálculo estatístico, para obter o grau de validade e utilidade dos dados lidos depois do prazo da tarefa terminar.

A partilha de recursos é delicada de se usar num ambiente multitarefas, como tal um cuidado acrescido deve ter-se em consideração. Quando uma tarefa está a utilizar um dado recurso, a ler, ou a escrever, convém bloquear as outras tarefas de utilizarem esse mesmo recurso; se tal não for feito os resultados podem ser imprevisíveis. Os métodos utilizados para uma eficiente partilha de recursos incluem:

• Mascaramento temporário / Desabilitar interrupções
• Semáforos binários
• Mensagens trocadas

O mascaramento temporário consiste em desabilitar temporariamente os serviços de atendimento às interrupções efectuados pelo processador. Enquanto as interrupções estão desabilitadas, uma tarefa pode passar uma seção crítica de uma dado programa embarcado sem ser interrompida, ou seja, obtém temporariamente o monopólio de uma dado recurso. Como tal, o código inserido numa seção crítica deve ser curto, e deve durar poucos ciclos de relógio; se tal não for feito, as rotinas de interrupção precisarão esperar algum tempo até serem atendidas, o que provoca um aumento da latência de interrupção.

Um semáforo binário tem os estados de bloqueado ou desbloqueado. É usado para partilhar recursos, e para comunicação entre tarefas. Enquanto uma tarefa utiliza um dado recurso pode bloquear um semáforo; outra tarefa antes de utilizar esse recurso verifica o estado do semáforo, e se estiver bloqueado, não utiliza o recurso. Pode esperar que, o recurso fique liberto, ou pode executar outras funções.

Surgem no entanto alguns problemas relacionados com os semáforos binários, entre os quais a prioridade invertida e o entrave.

Na prioridade invertida uma tarefa de alta prioridade é obrigada a esperar porque uma tarefa de baixa prioridade bloqueou um semáforo. Se uma tarefa de baixa prioridade bloquear um semáforo, impede que uma tarefa que verifica o estado desse semáforo, seja executada, mesmo sendo de prioridade superior.

Um solução pode ser, atribuir temporariamente uma prioridade elevada, à tarefa que está a bloquear o semáforo, por forma a que esta desimpeça o recurso o mais rapidamente possível.

Num entrave, duas ou mais tarefas bloqueiam uma série de semáforos binários e esperam infindavelmente pelo desbloqueio de outros semáforos, criando assim ciclos infinitos. Se uma tarefa A bloquear o semáforo f1 e depois esperar pelo desbloqueio do semáforo f2, e uma tarefa B estiver bloqueada no semáforo f1 para desbloquear o semáforo f2, cria-se um entrave.

Outra forma de partilha de recursos assenta no envio de mensagens. Neste paradigma, um recurso específico é gerido por apenas uma tarefa, e as outras tarefas interrogam sobre o estado do recurso através de mensagens. Normalmente o sistema que assenta na troca de mensagens não causa entraves, e tem um comportamento mais estável que o sistema baseado nos semáforos.

• TI-RTOS - TI-RTOS é um SO criado pela Texas Instruments (TI) para uso em uma grande variedade de processadores embarcados.
• X-Real Time Kernel - um STR desenvolvido pela eSysTech voltado a processadores ARM
• FreeRTOS - um RTOS de código aberto e que já foi portado para diversas plataformas (ARM, MSP430, PIC, etc).
• QNX - RTOS comercial bastante utilizado em aplicações embarcadas.
• RTA-OSEK - Um RTOS voltado a aplicações automotivas.
• AIX - Advanced Interactive eXecutive - Uma versão do Unix executados em computadores de médio porte da IBM.
• AMX - um STR fornecido pela KADAK
• CMX - fornecido pela CMX Company
• BRTOS Basic RTOS - Pequeno e robusto RTOS (ARM,AVR,PIC,MSP430)
• VxWorks - RTOS comercial líder de mercado da Wind River
• RHEL - Em sua versão Red Hat Enterprise Linux for Real Time^[1]
• Zephyr - RTOS Open-Source mantido pela Linux Foundation com foco em IOT^[2]

Referências

TANENBAUM, A. S. Sistemas Operacionais Modernos. 2ª ed. São Paulo, Pearson Prentice Hall, 2003.

• https://web.archive.org/web/20090530141523/http://www.decom.ufop.br/prof/luizm/cic180_4.doc acesso em 09-maio-2008
• https://web.archive.org/web/20090528030544/http://nunonunes.com/str/rtos.htm#cap3 acesso em 09-maio-2008
• http://www.das.ufsc.br/~romulo/livro-tr/cap1.pdf acesso em 09-maio-2008