1 / 137

RTOS Real-Time Operating Systems

RTOS Real-Time Operating Systems. Conteúdo. Conceitos Complexidade de uma aplicação Características do Kernel Comunicação e sincronização Desempenho Tolerância à falhas Exemplos. Conceitos. São sistemas que satisfazem à fortes condições de tempo de resposta  correção lógica + temporal

rene
Download Presentation

RTOS Real-Time Operating Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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)

More Related