LRM Prof. Mantovani ← Aulas da disciplina
Semana 12 · Aula 12 de 14

Sistemas operacionais de tempo real e embarcados

Características de um RTOS (determinismo e latência), tempo real rígido versus flexível e o estudo de caso do FreeRTOS em microcontrolador — com simulador de tempo real.

📚 Sistemas Operacionais🧪 1 simulador(es)📝 mini-quiz ao final
Objetivos da aula

O que você vai aprender

1

Definir tempo real e diferenciar rígido (hard) de flexível (soft).

2

Identificar as métricas de um RTOS: latência, jitter, determinismo e WCET.

3

Descrever a arquitetura e as primitivas do FreeRTOS em um microcontrolador.

4

Avaliar a escalonabilidade de tarefas periódicas por Rate Monotonic.

1 · Motivação

Quando "rápido em média" não basta

Um airbag deve inflar entre 15 e 30 ms após a colisão. Um sistema que dispara em 5 ms na média, mas ocasionalmente em 80 ms, é inútil — ou pior, perigoso. Aqui, a média não importa: importa o pior caso.

Sistemas de tempo real trocam a busca pela maior vazão média pela garantia de prazos. Eles preferem ser previsíveis a ser velozes. Esta aula define o que isso significa, quais métricas medem essa previsibilidade e como um RTOS minúsculo como o FreeRTOS a entrega em microcontroladores de poucos KB.

2 · Mapa

O que veremos nesta aula

Tempo real:
rígido × flexível→Métricas:
latência, jitter, WCET→FreeRTOS→Escalonabilidade
(RM)

Do conceito de prazo às métricas que o quantificam, terminando num kernel real e no teste que diz se um conjunto de tarefas cabe no tempo.

3 · Conceito

Tempo real rígido e flexível

Tempo real. A correção depende não só do resultado, mas de quando ele é produzido: o sistema deve cumprir prazos (deadlines).
Rígido (hard). Perder um prazo é falha catastrófica (airbag, controle de voo, marca-passo).
Flexível (soft). Perder um prazo degrada a qualidade, mas é tolerável (streaming, jogos).
🔑
RTOS não significa "rápido": significa previsível. Prefere-se um pior caso conhecido e limitado a uma média baixa com variância alta.
4 · Explicação

Determinismo: o pior caso é tudo

O coração do tempo real é o determinismo: a garantia de que toda operação termina dentro de um limite de tempo conhecido. Para provar que um sistema cumpre seus prazos, o engenheiro precisa do WCET (Worst-Case Execution Time) de cada tarefa — quanto ela leva no pior cenário possível.

O problema é que muitos recursos que melhoram a média pioram o pior caso e tornam o WCET difícil de calcular: caches (acerto ou erro?), pipelines com predição de desvio, paginação para disco, coleta de lixo. Por isso, em tempo real rígido, esses recursos são desabilitados, controlados ou substituídos por alternativas previsíveis (memória fixa, sem swap, sem GC).

5 · Exemplo

Três tarefas periódicas e sua utilização

Utilização de uma tarefa periódica = tempo de execução ÷ período. A soma indica quanto da CPU é consumido:

TarefaPeríodo (T)Execução (C)Utilização (C/T)
Ler sensor10 ms2 ms0,20
Atualizar display40 ms8 ms0,20
Registrar log100 ms10 ms0,10
Total0,50

Utilização total de 0,50 (50%) está bem abaixo do limite de Rate Monotonic (~0,78 para 3 tarefas), então o conjunto é escalonável por RM.

6 · Interativo

Passo a passo: latência de uma interrupção em RTOS

Passo 1
O sensor dispara uma interrupção — o evento físico acontece em t0.
Passo 2
Se interrupções estiverem desabilitadas (seção crítica), a CPU só atende ao reabilitá-las: parte da latência.
Passo 3
A ISR executa, salvando contexto e identificando a fonte do evento.
Passo 4
A ISR libera (signal) a tarefa de tratamento, que se torna pronta.
Passo 5
O escalonador, sendo a tarefa a de maior prioridade, a coloca na CPU: a resposta ocorre em t1. A latência total é t1 − t0.
7 · Conceito

Latência, jitter e WCET

Latência de interrupção. Tempo entre o evento físico e o início do seu tratamento.
Jitter. Variação da latência entre ocorrências sucessivas. Em controle, o jitter pode ser pior que uma latência alta porém constante.
WCET. Tempo de execução no pior caso de uma tarefa — base para provar escalonabilidade.
8 · Explicação

Escalonamento preemptivo por prioridade

O escalonador típico de um RTOS é preemptivo por prioridade fixa: a tarefa pronta de maior prioridade roda sempre; se uma de prioridade ainda maior fica pronta, ela preempta a atual imediatamente. Isso garante que a tarefa mais urgente nunca espere por uma menos urgente.

As prioridades costumam ser atribuídas por Rate Monotonic (RM): período menor (maior frequência) recebe prioridade maior. RM é ótimo entre os esquemas de prioridade fixa e tem um teste de escalonabilidade simples: se a utilização total não passa do limite de Liu & Layland, o conjunto cumpre todos os prazos. Cuidado com a inversão de prioridade (Aula 6): mutexes em RTOS usam herança de prioridade para evitá-la.

9 · Analogia

O pronto-socorro com triagem

🚑 Analogia
Um RTOS é como um pronto-socorro com triagem rígida. Não importa quem chegou primeiro: o paciente mais grave (maior prioridade) é atendido na frente, interrompendo até um atendimento em curso se necessário (preempção). O hospital não promete "rápido em média"; promete que nenhum caso grave espera além de um limite. Previsibilidade no pior caso, não velocidade média.
10 · Comparação

RTOS × SO de propósito geral

AspectoRTOSSO de propósito geral
ObjetivoCumprir prazos (determinismo)Vazão e interatividade médias
EscalonadorPreemptivo por prioridade fixaJustiça, time-sharing
MemóriaEstática/fixa, sem swapVirtual, com paginação
TamanhoKB (FreeRTOS, Zephyr)MB a GB (Linux, Windows)
FocoPior caso (WCET)Caso médio
11 · Fluxo

O ciclo de uma tarefa periódica

Acorda no
período→Executa
(≤ WCET)→vTaskDelay /
bloqueia→Dorme até o
próximo período
💡
Uma tarefa periódica bem escrita executa rápido e dorme o resto do período, liberando a CPU para tarefas de menor prioridade. Usar vTaskDelayUntil (em vez de vTaskDelay) mantém o período exato, reduzindo o jitter acumulado.
12 · Aprofundamento

O teste de escalonabilidade RM

Limite de Liu & Layland. Para n tarefas periódicas independentes sob Rate Monotonic, se a utilização total U ≤ n·(2^(1/n) − 1), todos os prazos são cumpridos. O limite cai de 1,00 (n=1) para ~0,69 (n→∞).

Esse teste é suficiente, mas não necessário: um conjunto que ultrapassa o limite ainda pode ser escalonável (verifica-se então com análise de tempo de resposta, mais precisa). O EDF (prioridade dinâmica por prazo) atinge até 100% de utilização em uniprocessador, mas RM é preferido em embarcados pela simplicidade e previsibilidade da prioridade fixa.

13 · Interativo

Verifique seu entendimento

Por que o jitter pode ser mais prejudicial que uma latência alta porém constante em um laço de controle?

Algoritmos de controle podem ser projetados assumindo um atraso fixo e conhecido. Já a variação imprevisível da latência (jitter) desregula a malha de controle, pois a amostragem e a atuação ocorrem em instantes irregulares.
14 · Caso prático

FreeRTOS em um ESP32

O FreeRTOS é um kernel de tempo real minúsculo (poucos KB) muito usado em microcontroladores como ARM Cortex-M e ESP32. Oferece tarefas, escalonamento preemptivo por prioridade, filas, semáforos e mutex com herança de prioridade — tudo o que um sistema embarcado de tempo real precisa, sem MMU nem swap.

// criando uma tarefa periódica no FreeRTOS xTaskCreate(tarefaSensor, "sensor", STACK, NULL, PRIORIDADE, NULL); void tarefaSensor(void *p) { TickType_t ultimo = xTaskGetTickCount(); for(;;) { leSensor(); vTaskDelayUntil(&ultimo, pdMS_TO_TICKS(10)); // período fixo de 10 ms } }

Em um robô ou drone, tarefas como ler IMU (alta frequência), estabilizar (controle) e telemetria (baixa frequência) coexistem com prioridades RM, comunicando-se por filas.

15 · Erros comuns

Confusões frequentes

⚠️
Erros comuns nesta aula:
• Achar que RTOS = "SO mais rápido" — RTOS = previsível, não necessariamente veloz.
• Confundir latência (atraso) com jitter (variação do atraso).
• Esquecer a inversão de prioridade ao usar mutexes — habilite a herança.
• Usar vTaskDelay esperando período exato — o certo para período fixo é vTaskDelayUntil.
• Ignorar que o teste de RM é suficiente, não necessário.
16 · Dicas

Como projetar tarefas de tempo real

✅
Liste cada tarefa com seu período (T) e seu WCET (C). Calcule a utilização C/T de cada uma e some. Atribua prioridades por RM (menor T → maior prioridade). Verifique o limite de Liu & Layland; se passar, refine com análise de tempo de resposta. Mantenha ISRs curtas, evite alocação dinâmica em tempo real e fixe a memória. Simule no simulador de tempo real antes de ir ao hardware.
17 · Interativo

Revele a resposta

Por que caches e predição de desvio são um problema para o tempo real rígido?
Porque tornam o tempo de execução dependente do histórico e, portanto, imprevisível. A mesma instrução pode levar 1 ciclo (acerto de cache, predição correta) ou centenas de ciclos (falta de cache, predição errada e flush do pipeline). Para calcular o WCET com segurança, o engenheiro teria de assumir sempre o pior caso, o que desperdiça desempenho — ou usar análise estática complexa. Por isso, em sistemas rígidos críticos, esses recursos são desabilitados, restritos ou modelados com ferramentas de análise de WCET.
18 · Flashcards

Revisão relâmpago

Tempo real rígidovirar
Perder um prazo é falha catastrófica; o pior caso deve ser garantido.
Jittervirar
Variação da latência entre ocorrências; em controle, pode ser pior que latência alta constante.
WCETvirar
Tempo de execução no pior caso; base para provar escalonabilidade.
Rate Monotonicvirar
Prioridade fixa por período: menor período → maior prioridade. Ótimo entre prioridades fixas.
FreeRTOSvirar
Kernel RT minúsculo: tarefas, filas, semáforos e mutex com herança de prioridade.
19 · Conexões

Para onde isso leva

O tempo real recolhe fios de todo o curso:

  • O escalonamento RM e EDF vem da Aula 5; a inversão de prioridade e a herança, da Aula 6.
  • A proibição de swap (Aula 9) e a preferência por polling (Aula 10) garantem determinismo.
  • A MPU (Aula 8) protege tarefas sem o custo da MMU.
  • O projeto embarcado culmina nas apresentações da Aula 14.
20 · Síntese

Resumo da aula

🔑
Tempo real é sobre prazos: rígido (prazo perdido = catástrofe) ou flexível (degradação tolerável). O que importa é o determinismo — o pior caso — medido por latência, jitter e WCET, não pela média. O escalonador é preemptivo por prioridade fixa, com prioridades atribuídas por Rate Monotonic e validadas pelo limite de Liu & Layland. Recursos imprevisíveis (swap, GC, caches) são evitados. O FreeRTOS entrega tudo isso em poucos KB num microcontrolador.
Mão na massa · colaborativo

Atividade em grupo · Projetando tarefas de RTOS

Em trios, projetem um conjunto de tarefas periódicas para um microcontrolador.

⏱️ 30 min👥 trios🧩 projeto embarcado

Roteiro

  1. Definam 3 tarefas periódicas (ex.: ler sensor 100 Hz, atualizar display 10 Hz, log 1 Hz) com seus tempos de execução.
  2. Atribuam prioridades por Rate Monotonic.
  3. Calculem a utilização total e verifiquem a escalonabilidade.
  4. Simulem no simulador de tempo real e ajustem se houver perda de prazo.
Arquiteto de tarefasdefine períodos e prioridades
Analista de WCETestima os tempos de execução
Verificadortesta a escalonabilidade
📤 Entrega: Conjunto de tarefas com prioridades RM, utilização total e veredito de escalonabilidade.
Teste seu conhecimento

Mini-quiz · Aula 12

20 questões sobre esta aula. Escolha e veja a explicação na hora.

0/20

📌 Resumo — leve isto para a prova

  • Tempo real é sobre prazos: rígido (catastrófico) versus flexível (degradação).
  • RTOS prioriza determinismo (pior caso) sobre média; mede latência, jitter e WCET.
  • O escalonador é preemptivo por prioridade fixa; RM atribui prioridade por período.
  • O limite de Liu & Layland testa a escalonabilidade RM (suficiente, não necessário).
  • FreeRTOS é um kernel RT minúsculo com tarefas, filas e mutex com herança.