RTOS Real-Time Operating Systems

1. RTOS Real-Time Operating Systems

2. Conteúdo • Conceitos • Complexidade de uma aplicação • Características do Kernel • Comunicação e sincronização • Desempenho • Tolerância à falhas • Exemplos

3. Conceitos • São sistemas que satisfazem à fortes condições de tempo de resposta  correção lógica + temporal • Precisão e desempenho estão fortemente ligados • Estão preparados para o tratamento de entradas assíncronas • Previsíbilidade no pior caso de carga e falhas

4. Aplicações • Controle de um processo de fabricação • Controle de tráfego aéreo • Treinamento militar • ...

5. Composição SistemaControlador • computador • pessoas ambiente • sensores SistemaControlado • chão de fábrica

6. Composição Aplicação hardware S.O. • botões • sensores primitivas para gerenciamento de tarefas, comunicação e sincronização entre processos

7. Conceitos básicos • Interrupção: é um sinal de hardware que gera um evento • Evento: ocorrência que faz o programa ter um comportamento não seqüencial Assíncrono: Síncrono: evento

8. Conceitos Básicos • Falha: um sistema falha quando não atende aos requisitos pré-estabelecidos • Tempo de resposta: tempo decorrente entre a entrada de um conjunto de dados e a saída de todas as respostas associadas. • Sincronização: condição para que uma tarefa atinja uma condição específica • Deadline : tempo limite para execução de uma tarefa

9. Características • Vínculos temporais • periódico • x vezes num período T • de t em t • Mais freqüente • não periódico • deadline para início e/ou fim • Mais complexo • Implementação • reativo: interação com ambiente • especialista: hardware próprio

10. Dimensionamento • Granularidade do deadline T fim tarefa ativa tarefa quanto menor T ou quanto menor deadline-T (tight deadline) menor a granularidade

11. Dimensionamento • Rigor do deadline • Hard: • não adianta executar após um deadline; • crítico • Ex. controle de temperatura de uma usina nuclear • Soft: • pode sobreviver após um deadline • Ex. robô em uma fábrica; monitoramento periódico de uma aeronave

12. Dimensionamento • Confiabilidade • Deadline garantido através de pré alocação de recursos • Problema: O que realmente é crítico? • Tamanho do sistema • totalmente carregado na memória • fases carregadas antes da execução

13. Dimensionamento • Ambiente determinístico: • controlado; • estático. • ex. linha de montagem • Ambiente não determinístico: • dinâmico. • ex. robô em marte

14. Sistema Operacional • Princípios • O fator tempo deve fazer parte dos fundamentos do sistema • Balanceamento entre flexibilidade e previsibilidade • Disponibilidade dos recursos necessários

15. Sistema Operacional • Exigências • Ser rápido; • Ser previsível; • Ser confiável; • Ser adaptável; • Ser tolerante a falhas.

16. Sistema Operacional • Otimizações • Troca de contexto rápida • Tamanho reduzido • Resposta rápida à interrupções • Tratamento temporal • Relógio de tempo real • Escalonamento por prioridade • Primitivas para administração temporal (pausa/retorno/atraso)

17. Sistema Operacional • Concorrência • Modelo de tarefas  (tempo de execução, período,deadline) Tempo de execução Deadline Inicio Período

18. Sistema Operacional • Primitivas Kernel • Criação de tarefas • Eliminação de tarefas • Suspensão de tarefas • Reativação de tarefas • Mudança de prioridade • Retardo

19. Sistema Operacional • Implementações • Pooled Loop • mais simples; • teste contínuo de um flag para verificar a ocorrência de um evento. ; • Não há escalonamento (uma única tarefa) nem mecanismos de sincronização.

20. Sistema Operacional • Interrupções • há troca de contexto • podem ser periódicas ou não periódicas • prioridade mais alta interrompe mais baixa Ex. usina nuclear • Problema: starvation nada é mais importante que o controle de temperatura

21. Sistema Operacional • Escalonamento O que fazer com multiplos processos de mesma prioridade? 1. Impedir que isso aconteça (simples); cada processo tem uma prioridade 2. Time slice 3. Processos com a mesma prioridade não interrompem outros

22. Sistema Operacional • Escalonamento Rate-Monotonic Processos mais freqüêntes tem maior prioridade Periodo Prioridade 10 1 (maior) 12 2 15 3 20 4 (menor)

23. Sistema Operacional • Características • produz escalas em tempo de execução • deadline = período • tempo de computação é conhecido e constante • tempo de troca de contexto ~ 0 • tarefas periódicas e independentes • escalonabilidade ( calculo de utilização na fase de projeto) U =  Ci / Pi <= n ( 21/n – 1)

24. RMS Missing a Deadline • p1 = (10,20,20) p2 = (15,30,30) utilization is 100% 1 2 Would have met the deadline if p2 = (10,30,30), utilization reduced 83% P2 misses first deadline

25. Sistema Operacional • Escalonamento EDF (earliest deadline first) Processos com deadline mais próximo recebem maior prioridade • Assume as mesmas premissas do RM • Reordenação da fila a cada nova execução

26. EDF Meeting a Deadline • p1 = (10,20,20) p2 = (15,30,30) utilization is 100% 1 2 P2 takes priority because its deadline is sooner

27. Sistema Operacional • Comparação RM x EDF

28. Sistema Operacional • RM garante até 69% de utilização e EDF garante 100% • EDF é mais complexo e pode gerar um overhead inaceitável • RM e EDF assumem que não há interação entre os processos, que é uma simplificação muito forte.

29. Sistema Operacional • Problemas com concorrência: • Inversão de prioridade • Solução • Aumento temporário de prioridade do processo quando obtem um recurso 1 2 Process 1 tries to acquire lock for resource Process 1 preempts Process 2 Process 2 acquires lock on resource Process 2 begins running

30. Outras Características • Desempenho • Tempo de reposta • Pooled Loop TR= S + F + P S=sinalização do hardware (ns) F=verificação do flag (s) P=processamento (ms) • Interrupção TR = L + C + S + P L=tempo de interrupção C=tempo de troca de contexto S=tempo de escalonamento P=processamento

31. Outras Características • Tempo de carga • analisador lógico • Caminho crítico • Software pronto e hardware disponível • contagem de instruções • Quando ainda é cedo para o analisador lógico • Aproximadamente o código final • Simulador para determinar o tempo de cada instrução.

32. Outras Características • Carga de memória Percentual de memória utilizada analisador lógico • Comunicação Transferência de informações entre tarefas • Área Comum De Memória • Troca De Mensagem

33. Tolerância a Falhas Habilidade de continuar executando após falha de hardware ou software • Espacial: redundância de hardware+software • Temporal: algoritmo • (checkpoint, logs, replicação)

34. Estudo de caso: STRAD • Baseado em processador 8088/8086 • Primitivas: • concorrência de processos (baseada em prioridade) • Temporização • Sincronização • Exclusão mútua • Escalonamento: • processo corrente é o que está pronto com mais alta prioridade • Comunicação entre processos: • troca de mensagem

35. Estudo de Caso: QNX • kernel (8KB) • Multitarefa • Escalonamento preemptivo baseado em prioridades • Rápida troca de contexto • Comunicação através de troca de mensagens

36. Estudo de Caso: QNX • kernel • Comunicação entre processos • Mensagem: comunicação bloqueante • Proxies: comunicação não bloqueante(utilizada quando não há necessidade de resposta ou emissor não quer ficar bloqueado • Sinais: comunicação assíncrona

37. Estudo de Caso: QNX • Comunicação de baixo nível via rede • Um circuito virtual é estabelecido quando um processo deseja enviar uma mensagem através da chamada ao sistema qnx_vc_attach(). • Esta função cria uma identificação virtual (VID) para cada ponta do circuito, isto é, uma para o transmissor e uma para o receptor, porém a identificação criada na máquina transmissora equivale à receptora e vice-versa

38. Estudo de Caso: QNX • Escalonamento de processos • FIFO • Round Robin • Adaptativo (default) • Reduz a prioridade de 1 quando consome a fatia de tempo. • Aumenta a prioridade de 1 quando o processo que teve sua prioridade reduzida permanece na fila de prontos por mais de um minuto. • Se um processo é bloqueado, a prioridade original é restaurada. • Tratamento de interrupções

39. Estudo de Caso: QNX • Processos adicionais • Gerenciador de processos • Gerenciador do sistema de arquivos • Gerenciador de dispositivos • Gerenciador de rede

40. Estudo de Caso: QNX • Primitivas de Tempo • Criação de timer • Sleep until completion • Notify with proxy • Notify with signal • Alarme absoluto / relativo • Remoção de timer • Precisão(500s até 50 ms)

41. Estudo de Caso: QNX • Funções comuns • Sistema de arquivos • Segurança • Rotinas de tratamento de interrupções

42. Inicialização do QNX em um microcontrolador Élan SC400

43. Referências • D. Ripps, Guia de Implementação para programação em Tempo Real, Cap. I e II, Editora Campus, 1993. • P. Laplante, Real Time Systems Design and Analysis - an engineer’s handbook, Cap. I, III, VI, VII, VIII, IX, XI, IEEE Press, 1992. • A. Freedman, and R. Lees, Real Time Computer Systems, Cap. I, Crane Russak & Company, 1977. • J. Stankovic, Real Time Computing, University of Massachusetts, 1992. • Yodaiken, The RT-Linux approach to hard real-time, Departament of Computer Science, New Mexico Institute of Technology • J.ª Stankovic et al, Strategic Directions in real-time and embedded systems, ACM Computing Surveys, vol28, n 4, December, 1996. • Romulo de Oliveira, Jean-Marie Farines, Jonidas S Fraga, Sistemas de Tempo Real, Escola de Computação 2000.

44. CSE 537sTinyOS source code and programming Xiaorui Wang Most slides are modified from Berkeley TinyOS introduction

45. Roadmap • TinyOS Overview • A simple Counter program • Sending and receiving message through sensor network • Event driven Sensor data • Posting a task • TOSSIM: Simulator on PC • Programming Environment

46. TinyOS Overview • Application = scheduler + graph of components • Compiled into one executable • Event-driven architecture • Single shared stack • No kernel/user space differentiation Main (includes Scheduler) Application (User Components) Actuating Sensing Communication Communication Hardware Abstractions Modified from D. Culler et. Al., TinyOS boot camp presentation, Feb 2001

47. Messaging Component Internal State Internal Tasks Commands Events TinyOS component model • Component has: • Frame (storage) • Tasks: computation • Interface: • Command • Event • Frame: static storage model - compile time memory allocation (efficiency) • Command and events are function calls (efficiency) Modified from D. Culler et. Al., TinyOS boot camp presentation, Feb 2001

48. How TinyOS works : Scheduling • Two-level scheduling ( Event and Task ) • Single shared stack ( used by both interrupt and function call) • Scheduler is simple FIFO with bounded number of pending task. • Task can NOT preempt each other. • Event has high priority than Task. Event can preempt task • Event can preempt each other, once enabled • When idle , scheduler shut down node except for clock Modified from Tian He et. Al., TinyOS source code and programming, U of Virginia

49. Event implementation Event is independent of FIFO scheduler. • Lowest level events are supported directly by Hardware interrupt • Software events propagate from lower level to upper level through function call. INTERRUPT(_output_compare2_){ // Hardware Timer Event Handler … TOS_SIGNAL_EVENT(CLOCK_FIRE_EVENT)( ); //Software Event … }

50. TinyOS Commands,Events and Tasks { ... status = TOS_CALL_COMMAND(name)(args) ... } Function call Function Call { ... status = TOS_SIGNAL_EVENT(name)(args) ... } { ... TOS_POST_TASK(name)(args) } Fun. Pointer FIFO Queue TOS_EVENT(name)(args) { ... return status; } TOS_COMMAND(name)(args) { ... return status; } TOS_TASK(name)(args) { ... return status; } Real implementation: #define TOS_COMMAND(command_name) TOS_CALL_COMMAND(command_name) #define TOS_EVENT(event_name) TOS_SIGNAL_EVENT(event_name)