1.38k likes | 1.57k Views
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
E N D
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 • 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
Aplicações • Controle de um processo de fabricação • Controle de tráfego aéreo • Treinamento militar • ...
Composição SistemaControlador • computador • pessoas ambiente • sensores SistemaControlado • chão de fábrica
Composição Aplicação hardware S.O. • botões • sensores primitivas para gerenciamento de tarefas, comunicação e sincronização entre processos
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
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
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
Dimensionamento • Granularidade do deadline T fim tarefa ativa tarefa quanto menor T ou quanto menor deadline-T (tight deadline) menor a granularidade
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
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
Dimensionamento • Ambiente determinístico: • controlado; • estático. • ex. linha de montagem • Ambiente não determinístico: • dinâmico. • ex. robô em marte
Sistema Operacional • Princípios • O fator tempo deve fazer parte dos fundamentos do sistema • Balanceamento entre flexibilidade e previsibilidade • Disponibilidade dos recursos necessários
Sistema Operacional • Exigências • Ser rápido; • Ser previsível; • Ser confiável; • Ser adaptável; • Ser tolerante a falhas.
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)
Sistema Operacional • Concorrência • Modelo de tarefas (tempo de execução, período,deadline) Tempo de execução Deadline Inicio Período
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
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.
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
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
Sistema Operacional • Escalonamento Rate-Monotonic Processos mais freqüêntes tem maior prioridade Periodo Prioridade 10 1 (maior) 12 2 15 3 20 4 (menor)
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)
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
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
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
Sistema Operacional • Comparação RM x EDF
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.
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
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
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.
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
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)
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
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
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
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
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
Estudo de Caso: QNX • Processos adicionais • Gerenciador de processos • Gerenciador do sistema de arquivos • Gerenciador de dispositivos • Gerenciador de rede
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(500s até 50 ms)
Estudo de Caso: QNX • Funções comuns • Sistema de arquivos • Segurança • Rotinas de tratamento de interrupções
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.
CSE 537sTinyOS source code and programming Xiaorui Wang Most slides are modified from Berkeley TinyOS introduction
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
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
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
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
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 … }
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)