Sistema Operacional De Tempo

Sistema operacional de tempo-real Origem: Wikipédia, a enciclopédia livre.

O Robô motorizado de pesquisa a Marte tem embutido Sistemas Operacionais de Tempo-Real

Um Sistema Operacional de Tempo Real (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 alarmar 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. Índice [esconder]

•

1 Filosofias de desenho

•

2 Escalonamento

•

3 Sistemas de tempo-real críticos e Não-Críticos

•

4 Comunicação entre tarefas, sincronização e partilha de recursos

o

4.1 Mascaramento temporário / Desabilitar interrupções

o

4.2 Semáforos binários

o

4.3 Mensagens

•

5 Exemplos de RTOS

•

6 Referências

[editar]Filosofias

de desenho

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-sepreemptividade. 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. [editar]Escalonamento 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 das tarefas. 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 freqüê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. [editar]Sistemas

de tempo-real críticos e Não-Críticos

Um caça F-16 tem embutido Sistemas de Tempo Real rígidos

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.

Os leitores de CD e de DVD possuem Sistemas de Tempo Real moderados.

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 ultraconfiá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 embebido de navegação de uma aeronave, o sistema embebido 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. [editar]Comunicação

entre tarefas, sincronização e partilha de recursos 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

[editar]Mascaramento

temporário / Desabilitar

interrupções 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 correr uma secção crítica de uma dado programa embebido, sem ser interrompida, ou seja obtém temporariamente o monopólio de uma dado recurso. Como tal, o código inserido numa secçã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 terão de esperar algum tempo até serem atendidas, o que provoca um aumento da latência de interrupção. [editar]Semáforos

binários

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 [editar]Mensagens 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. [editar]Exemplos

de RTOS

X-Real Time Kernel - um STR desenvolvido pela eSysTech voltado a processadores ARM [1] http://www.esystech.com.br FreeRTOS - um RTOS de código aberto e que já foi portado para diversas plataformas (ARM, MSP430, PIC, etc). Veja mais em: http://www.freertos.org/ QNX - RTOS comercial bastante utilizado em aplicações embarcadas. http://www.qnx.com RTA-OSEK - Um RTOS voltado a aplicações automotivas. http://en.etasgroup.com/products/rta/rta_osek_in_detail.shtml AIX - Advanced Interactive eXecutive - Uma versão do Unix executados em computadores de médio porte da IBM. [2] http://www.ibm.com/aix AMX - um STR fornecido pela KADAK [3] http://www.amx.com CMX - fornecido pela CMX Company [4] http://www.cmx.com

Sistemas Operativos de Tempo Real Conteúdo 1. Introdução 2. Sistemas operativos 3. Kernel de tempo real 3.1 Multitarefas 3.2 Kernel 3.3 Interrupções

3.4 Escalonador 3.4.1 não-preemtivo 3.4.2 preemtivo 4. Serviços do kernel 5. Serviços operativos de TR comerciais 6. Fontes de informação

Sistemas Operativos de Tempo Real Introdução Sistemas de tempo real são sistemas cujas características dependem do cumprimento de requisitos temporais e lógicos e onde as consequências do não cumprimento desses mesmos requisitos podem causar prejuízos nefastos, como sejam a segurança de pessoas. Nesta perspectiva, um Sistema Operativo de Tempo Real (SOTR) é uma aplicação multitarefa na qual várias tarefas críticas devem ser processadas em simultâneo. O sistema deve assegurar que as tarefas críticas sejam tratadas em tempo útil. O uso de SOTR simplifica o projecto de um sistema. De um modo geral, um sistema pode sempre ser decomposto num conjunto de processos. A função do SOTR é gerir esses processos atribuindo-lhes "espaço" para que cada um deles execute, sem que isso destrua a integridade temporal do sistema, isto é, prioridade para os processos críticos. De alguma forma, as duas palavras sublinhadas anteriormente sugerem o âmbito no qual reside a essência de SOTR:

gerir prioridades, Escalonar!

Sistemas Operativos

Um Sistema Operativo (SO) é um programa que controla a execução dos programas de aplicação dos utilizadores do sistema de computação. O SO fornece uma plataforma virtual de alto nível ao programador que esconde os detalhes do hardware faciitando o desenvolvimento de programas que usam os recursos do sistema. Deste modo, podemos afirmar que o sistema de computação se encontra distribuído por camadas da seguinte forma:

Aplicações do programador Sistema Operativo Hardware do sistema

Figura 1 Os sistemas que não usam SOTR são geralmente esquematizados conforme se mostra na figura 1. A estes sistemas chamamos foreground/background. Uma aplicação consiste num loop infinito que pede a cada modulo de aplicação para realizar/executar as operações que se desejam. Os modulos são executados sequencialmente (background) com rotinas do serviço de interrupções (ISRs) que lidam com eventos asincronos (foreground). Operações críticas deverão ser executads pelo ISRs de modo a garantir que estas serão executadas o mais rápido possível (também conhecido por "best effort"). Devido a este facto, ISRs são tendencialmente mais demoradas do que deveriam ser.A informação para um módulo background que é acessível por uma ISR só será processada quando a rotina background estiver apta para a executar. Neste caso a latência depende de quanto tempo o loop em background demora a ser executado.

Kernel de Tempo Real

Multitarefas Multitarefas é o processo que consiste em escalonar e distribuir o tempo do CPU entre várias/diferentes tarefas; um CPU único permite realizar diferentes tarefas sequenciais. O processo de multitarefas permite-nos estruturar uma aplicação num conjunto de tarefas mais pequenas e dedicadas que partilham o processador. Um dos aspectos mais importantes do processo de multitarefas é o facto de permitir ao programador da aplicação de lidar com situações mais complexas que são inerentes em aplicações de tempo real. Kernel’s de tempo real permitem que se torne mais fácil de realizar e de manter os programas de aplicação. Uma tarefa consiste num programa único que supõe estar a usar o CPU sozinho. A realização de uma aplicação de tempo real envolve a

divisão do trabalho que será feito em tarefas que serão responsáveis por uma porção do problema.

Kernel O kernel é a parte de um sistema de multitarefas que é responsável pela realização de tarefas e pela comunicação entre tarefas. Quando o Kernel decide correr uma tarefa diferente ele salvaguarda o contexto das tarefas correntes (ié, os registos do CPU) na stack destas tarefas; para cada uma das tarefas existe um espaço de memória dedicado à stack respectiva. Ao mudar de tarefa, é feito um updatedo conteúdo da actual e o conteúdo da stack da nova tarefa é resumido, assim como o código respectivo. O endereço da stack, em conjunto com outra informação é guardado numa estrutura de dados intitulada Task Control Block. O conjunto de todas as TCB’s é depois gerido pelo SOTR.

Interrupções Um aspecto importante nos sistemas de tempo real é o tempo entre um pedido de interrupção e o instante em que o código para lidar com esse pedido começa a ser processado.Um SOTR desactiva todos os pedidos de interrupção quando está a tratar uma tarefa crítica. Isto impede que sejam identificados pedidos de interrupção enquanto não acabar a execução do código em questão. Para que a latência de interrupção seja o mais pequena possível é necessário que as rotinas de interrupção (ISR's) sejam também pequenas. Um valor típico para o tempo máximo durante o qual as interrupções estão inibidas é 50us.

Escalonador Também conhecido por dispatcher , é a parte do Kernel responsável por decidir qual a tarefa que vai ser processada a seguir pelo CPU. Para a maior parte dos SOTR, o kernel é baseado numa estrutura de ordem de prioridade: cada tarefa tem uma prioridade associada de acordo com a sua importância. Deste modo, o controlo do CPU será atribuido à tarefa com prioridade mais elevada que está pronta a correr (runnable). Existem dois tipos: Escalonador não-preentivo Compete à tarefa que está a correr fazer algo para libertar o CPU. Quando uma tarefa com prioridade mais elevada está pronta a ser executada (ready to run), ainda que o ISR a faça pronta a correr, os recursos só lhe serão atribuidos quando a tarefa actual libertar o processador. É necessário que todas as tarefas cumpram limites temporais de apropriação dos recursos do CPU de modo a que a integridade temporal do sistema seja mantida, ou seja, a resposta a eventos críticos seja dada

em tempo útil. Escalonador preentivo Num escalonador deste tipo, se um evento transforma uma tarefa de prioridade mais elevada em ready to run, a tarefa actual é imediatamente suspensa e o CPU é cedido a esta tarefa. A maior parte dos SOTR emprega este tipo de escalonamento porque permite uma maior rapidez de resposta a eventos críticos.

Serviços do kernel Um dos serviços do kernel de tempo real mais comum é a gestão de semáforos. Um semáforo é um protocolo usado para controlo do acesso a recursos partilhados, assinalar a ocurrência de eventos ou sincronizar tarefas. Genericamente, é uma permissão que uma tarefa adequire para continuar a executar. Se o semáforo já estiver em uso, a tarefa é suspensa até que o semáforo seja libertado. A vantagem é que uma tarefa suspensa não gasta tempo do CPU. Um outro serviço é o estabelecimento de uma base de tempo que permita a uma tarefa atrasar-se um determinado número de tick's definidos por essa base de tempo (ver Noções gerais de Sistemas de Tempo Real, no capítulo 3). Outro serviço é a troca de mensagens entre mensagens ou entre mensagens e o ISR. Os dois tipos deste serviço mais comuns são o message mailbox e o message queue. O message mailbox é tipicamente uma variável do tipo apontador que o remetente deixa na mailbox para o destinatário, sendo o tipo de mensagem acordado entre os interlocutores. O message queue é utilizado para enviar mais do que uma mensagem; genericamente, consiste numa pilha de mailboxes

Sistemas Operativos de TR comerciais Existem actualmente vários produtos deste género, para plataformas de 8, 16 e 32 bit. Alguns destes produtos incluem kernel de tempo real, gestor de entrada/saída, interfaces gráficas do tipo windowz , um sistema de ficheiros, controlo de rede, Compiladores multi-plataforma, etc. A grande aposta é, no entanto, em sistemas embebidos de pequena dimensão. São utilizados em controlo de máquinas, intrumentação inteligente, robots, periféricos de computadores, equipamento de telecomunicações, etc. Geralmente, são construídos em plataformas de 8 bit. Com uma capacidade de endereçamento de 64K, não podem suportar SOTR de grande dependência de memória. Existem sistemas comerciais que

requerem apenas 1 a 3K de ROM. Alguns permitem até o controlo do tamanho da stack das tarefas, caso-a-caso, para permitir a redução da RAM necessária para a aplicação. Outras vantagens destes sistemas são: • • • • • • •

baixo preço; latência de interrupção reduzida; tempo de execução determinístico em todos os serviços do kernel; capacidade de gerir pelo menos 20 tarefas em simultâneo; criação e eliminação dinâmicas de tarefas; serviço de gestão de semáforos a definição de timeout's e delay's para os serviços do kernel;

tudo isto à custa de um acréscimo de apenas 1 a 5% do tempo de processamento do CPU. Os benefícios de usar SOTR podem ser reconhecidos pela capacidade de desenvolver um sem número de aplicações que beneficiam dos seus atributos sem que haja necessidade de alterar o software.

Fontes de informação De entre os projectos de desenvolvimento com divulgação na web seleccionaram-se os seguintes pela sua relevância e pela focagem dos aspectos relativos a SOTR. Encontram-se ordenados pela quantidade de informação disponibilizada. Real Time Linux - Na perspectiva de open source que caracteriza este grupo, não se poderia pedir mais. Desde o código fonte até às FAQ's, está lá tudo. The Maruti Project - Projecto do departamento de ciencias da computação da universidade de Maryland - USA. Menos suporte mas informação qb. Mais do que o que lá está só através do contacto com os responsáveis do projecto. LinuxWorks - Embeeded Linux - Demasiado comercial mas um bom exemplo de como se faz actualmente uma grande aposta em sistemas embebidos

Sistemas de Tempo Real Neste artigo descrevemos os conceitos de um Sistema de Tempo Real e as principais motivações para sua utilização, definindo sua arquitetura básica e critérios para a escolha de um Sistema Operacional de Tempo Real disponível no mercado. Sérgio Prado

Os sistemas computacionais estão presentes em diversas áreas do nosso cotidiano e têm evoluído de forma exponencial nos últimos anos. Novos microprocessadores com novos recursos computacionais, operando em freqüências maiores, com maior capacidade de memória e várias interfaces de comunicação de I/O embutidas num único chip, tudo isso a um custo baixo e acessível. Essa evolução tem aumentado a complexidade dos projetos de sistemas embarcados, que por

conseqüência tem exigido novos níveis de abstração em soluções de software que possam interagir com o hardware da forma mais eficiente possível. Dentro deste contexto, destaca-se um grupo de sistemas que são limitados pelo tempo, chamados Sistemas de Tempo Real. Além de executarem as tarefas de controle e processamento de informações, eles possuem a característica de que suas respostas ao ambiente devem ser dadas em um tempo hábil o suficiente para que o sistema não entre em um estado inconsistente. Um Sistema de Tempo Real é, portanto, o software que gerencia os recursos computacionais do microprocessador, com o objetivo de garantir que todos os eventos sejam atendidos dentro de suas restrições de tempo, e gerenciados da forma mais eficiente possível. O software responsável pelo gerenciamento dos recursos computacionais também é chamado de Kernel (ou núcleo) do Sistema de Tempo Real, e conhecido no mercado como RTOS (Real-Time Operation System) ou Sistema Operacional de Tempo Real. Para entendermos a importância de um Sistema de Tempo Real, precisamos entender o conceito de restrição de tempo para eventos ou tarefas computacionais.

Sistemas em Tempo Real Contents [hide]

•

1 Sistemas de Tempo Real:

o

1.1 Sistema Operacional de Tempo Real (SOTR):

o

1.2 Diferença entre um SO convencional e um SOTR:

o

1.3 Kernel de Tempo Real

 o

1.3.1 Definições:

1.4 Tipos de Escalonador



1.4.1 Escalonador não-preemptivo



1.4.2 Escalonador preentivo

o

1.5 Funcionamento de um Sistema de Tempo Real

o

1.6 Deadline

o

1.7 Linux em Tempo Real

[edit]

Sistemas de Tempo Real: Um sistema de tempo real é um sistema em que o desempenho correto de uma aplicação é avaliada não somente pela sua resposta correta, mas também pelo tempo gasto para obter tal resposta. Um sistema de tempo real tem sempre que cumprir prazos, sendo limitado pelo tempo de resposta esperado. O tempo de resposta de uma aplicação é o intervalo de tempo entre a recepção de um estímulo, normalmente vindo de uma interrupção de hardware, até quando a aplicação produz um resultado baseado no estímulo. Estes resultados podem ser atos como abrir uma válvula em uma aplicação de controle industrial, desenhar um quadro de

gráficos em uma simulação visual ou processar um pacote de dados numa aplicação de aquisição de dados. [edit]

Sistema Operacional de Tempo Real (SOTR): Um sistema operacional de tempo real é uma aplicação multitask na qual várias tarefas críticas devem ser processadas em simultâneo. O sistema deve assegurar que as tarefas críticas sejam tratadas em tempo útil. Essencialmente, um SOTR faz duas coisas: definir prioridades e escalonar as tarefas de acordo com essas prioridades. [edit]

Diferença entre um SO convencional e um SOTR: A principal diferença entre os dois tipos de sistemas é que o SO convencional tentará realizar operações críticas da maneira mais rápida possível (“best effort”), geralmente esperando a instrução anterior terminar de ser realizada, enquanto que o SOTR garantirá a realização deste serviço no período determinado para a realização do mesmo. [edit]

Kernel de Tempo Real Um kernel de um SOTR deve apresenta as seguintes características: -> Ser multitarefa; -> Aceitar interrupções; -> Possuir um escalonador que lide com tarefas críticas. [edit]

Definições: Multitarefa: processo que consiste em escalonar e distribuir o tempo do CPU entre várias tarefas, podendo um único CPU realizar tarefas seqüenciais. Interrupções: instrução que deve ser realizada sem uma previsão antecipada, fazendo com que a CPU mude seu contexto atual para a realização da mesma, retornando após sua conclusão. Escalonador: é a parte do Kernel responsável por decidir qual a tarefa que vai ser processada a seguir pela CPU. [edit]

Tipos de Escalonador

Para a maior parte dos SOTRs, o kernel é baseado numa estrutura de ordem de prioridade: cada tarefa tem uma prioridade associada de acordo com a sua importância. Deste modo, o controle do CPU será atribuído à tarefa com a prioridade mais elevada que está pronta para ser executada. Dentre os escalonadores, temos dois tipos: [edit]

Escalonador não-preemptivo É de responsabilidade da tarefa que está sendo executada realizar um procedimento para liberar a CPU. Desta forma, mesmo quando uma tarefa com prioridade maior que a atual está pronta para ser executada, ela só poderá ocorrer depois que a anterior indicar a CPU que sua execução já foi concluída. É necessário que todas as tarefas cumpram limites temporais de apropriação dos recursos da CPU de modo a garantir a integridade temporal do sistema, sendo possível assim responder a eventos críticos em tempo hábil. [edit]

Escalonador preentivo Num escalonador deste tipo, se um evento tornar uma tarefa de prioridade mais elevada em pronta para ser executada, a tarefa atual é imediatamente suspensa e o CPU é cedido a esta tarefa. A maior parte dos SOTRs empregada este tipo de escalonador porque permite uma maior rapidez de resposta a eventos críticos. [edit]

Funcionamento de um Sistema de Tempo Real O aspecto mais importante nos sistemas de tempo real é a execução da tarefa em tempo hábil. Mas não só o tempo de execução é levado em conta nesse cálculo do tempo, há também a chamada latência: o tempo entre um pedido de interrupção e o instante em que o código para lidar com esse pedido começa a ser processado. Um SOTR desativa todos os pedidos de interrupção quando está tratando uma tarefa crítica. Isto impede que sejam identificados pedidos de interrupção enquanto não acabar a execução do código em questão. Para que a latência de interrupção seja o menor possível é necessário que as rotinas de interrupção sejam também pequenas. Um valor típico para o tempo máximo durante o qual as interrupções ficaram inibidas é de 50 us. [edit]

Deadline Deadline é o tempo máximo para o sistema realizar uma determinada ação, em função de um determinado estímulo a partir do qual se contabiliza a deadline.

Um deadline é considerado hard se o resultado de ser ultrapassado o tempo limite é catastrófico, como a mudança de cores de um semáforo, os controles dos estímulos de um marcapasso, etc. Nos sistemas em que há pelo menos uma hard deadline são chamados de Hard Real Time. Os sistemas opostos são os chamados softs, que trabalham com o método do “best effort”, neste caso é suposto que se uma deadline é ultrapassada não ocorrerá nenhuma catástrofe. Logo, existe uma certa margem de manobra.

[edit]

Linux em Tempo Real Linux tem desempenho favorável para aplicações normais, mas ele não é desenhado para resposta determinística. Porém, melhoramentos no kernel estão disponíveis para ajudar ou garantir o determinismo, exigência básica para um sistema de tempo real. Desta forma, o Linux não é um sistema operacional real time porque não pode assegurar sempre um desempenho determinístico e porque na média e no tempo de pior caso é longe do tempo requerido por muitas aplicações real time. Um técnica para tornar o Linux um real time system é a instalação de um novo kernel que atuará em conjunto com o até então utilizado. As tarefas chegam nesse kernel real time que diferenciará as assinaladas como de tempo real e as com prioridade normal. Fazendo com que as real time tasks tenham total prioridade em detrimento das tarefas não críticas.

O que é a Tecnologia de Tempo Real? Visão geral Vários testes, controles e aplicações de projeto exigem desempenho em tempo real. Esse tutorial analisa os conceitos básicos de sistemas de tempo real. Conteúdo

1. Introdução aos Sistemas de Tempo Real 2. Desempenho em Tempo Real 3. Controle em Tempo Real 4. Resposta a Eventos em Tempo Real 5. Tecnologia de Tempo Real da NI

Introdução aos Sistemas de Tempo Real

Os sistemas operacionais de tempo real foram projetados para resposta a eventos e sistemas de controle de malha fechada. Aplicações de resposta a eventos, como um sistema de airbag automotivo, necessitam de uma resposta a um estímulo em um determinado espaço de tempo. Sistemas de controle de malha fechada, como um sistema de controle de velocidade automotiva, processam continuamente o feedback do sistema para ajustar uma saída. Ambos os sistemas exigem a realização de uma operação dentro de um tempo determinado. Esse tipo de desempenho é chamado de determinístico. Sistemas de tempo real podem ser classificados como “soft” ou “hard”. Para sistemas de tempo real do tipo soft, a utilidade de um sistema geralmente é inversamente proporcional ao tempo de resposta após um determinado prazo ter sido perdido. Por exemplo, quando pressionamos um botão do telefone para atender uma chamada, a conexão deve ser estabelecida logo após o botão ter sido apertado. Contudo, o prazo não é tão crítico e pequenos atrasos podem ser tolerados. Sistemas de tempo real do tipo “hard” são aqueles em que a utilidade do sistema torna-se zero em caso de perda do prazo. Uma unidade de controle de motores automotivos (ECU - automotive engine control unit) deve processar sinais de entrada e calcular a temporização da faísca da vela dentro de um prazo. Se houver perda desse prazo, o motor não irá operar corretamente. A utilidade de uma tarefa após a perda de prazo depende se o sistema de tempo real é do tipo “soft” ou do tipo “hard”, como mostrado na Figura 1. Sistemas operacionais como o Microsoft Windows e o MAC OS fornecem uma excelente plataforma para desenvolvimento e execução de aplicações não críticas de medição e controle. Contudo, por serem sistemas operacionais projetados para um propósito geral, eles não são ideais para executar aplicações que necessitem de um desempenho determinístico ou de um maior tempo sem falhas. Sistemas operacionais de propósito geral são otimizados para executar uma variedade de aplicações simultaneamente, assegurando que todas aplicações recebam um tempo de processamento. Esses sistemas operacionais também devem responder a interrupções de periféricos como mouse e teclado. O usuário tem controle limitado sobre o modo como essas tarefas são manipuladas pelo processador. Como resultado, tarefas de alta prioridade podem ser interrompidas para que tarefas de baixa prioridade sejam executadas, fazendo com que seja impossível garantir um tempo de resposta constante para suas aplicações críticas. Em contraste, sistemas operacionais de tempo real proporcionam a capacidade de priorizar tarefas, para que as tarefas mais críticas possam sempre ter controle do processador quando necessário. Essa propriedade possibilita a criação de aplicações com resultados que podem ser previstos.

Figura 1. Diferença entre tecnologia de tempo real Hard e Soft

Sistemas operacionais de tempo real são necessários quando o processador está envolvido em operações como controle de malha fechada e tomada de decisão em tempo crítico. Essas aplicações necessitam que decisões temporizadas sejam feitas baseadas em dados recebidos. Por exemplo, um equipamento de entradas e saídas amostra um sinal de entrada e o envia diretamente para a memória. Então, o processador deve analisar o sinal e enviar a resposta adequada ao equipamento de entradas e saídas. Nessa aplicação, o software deve estar envolvido na malha; portanto, você precisa de um sistema operacional de tempo real para garantir resposta dentro de um espaço de tempo fixo. Além disso, aplicações que necessitam de tempo de execução extendido ou operações autônomas são geralmente implementadas com sistemas operacionais de tempo real. Desempenho em Tempo Real O equívoco mais comum associado ao desempenho em tempo real é dizer que ele aumenta a velocidade de execução do programa. Apesar de ser verdade em alguns casos, a aplicação é melhorada proporcionando temporização precisa e previsível. Com essas melhorias, você pode determinar o tempo exato quando certo evento ocorrerá. Controle em Tempo Real Com controle em tempo real, é possível monitorar e simular continuamente um sistema físico. Aplicações de controle em tempo real executam repetidamente uma tarefa definida pelo usuário com um intervalo de tempo específico entre cada execução. A maioria dos sistemas de controle em tempo real monitora um sistema físico, comparam o estado atual com o estado desejado e então simulam o sistema físico baseando-se nessa comparação. O tempo que leva para que essa malha execute é considerado o tempo de ciclo da malha. O tempo de ciclo da malha de controle varia baseado na complexidade do sistema. O determinismo mede a consistência do intervalo de tempo especificado entre os eventos. Muitos algoritmos de controle, como o PID, requerem um comportamente muito determinístico. Por exemplo, um elevador move-se gradualmente para o andar correto por causa do comportamento determinístico da malha de controle. Sem o determinismo, o evelador chega ao andar correto, porém sem estabilidade. Em todos os sistemas de tempo real há uma quantidade de erro chamada jitter. O jitter é outra maneira de medir o determinismo de um sistema de tempo real. Você pode calculá-lo como a diferença máxima entre qualquer atraso individual de tempo e o atraso de tempo desejado em um sistema, como mostrado na Figura 2.

Figura 2. Um Exemplo de Diagrama de Jitter Resposta a Eventos em Tempo Real Com resposta a eventos em tempo real é possível responder a um simples evento dentro de um dado

espaço de tempo. O sistema de tempo real garante algum tempo máximo de resposta a um evento único. O evento pode ser tanto periódico quanto aleatório. Um exemplo de uma aplicação de resposta a um evento em tempo real é um sistema de monitoração de segurança. Se uma planta entra em um estado de perigo, o sistema de tempo real deve responder a este evento dentro de um espaço de tempo garantido. A latência é usada para descrever o tempo que leva para se responder a um evento. É similar ao determinismo em aplicações de controle em tempo real. Com resposta a eventos em tempo real, é garantido o pior caso de latência. Tecnologia de Tempo Real da NI Os módulos LabVIEW Real-Time e LabWindows™/CVI Real-Time são usados para se alcançar execução determinística confiável em hardware dedicado. Caso haja necessidade de um determinismo maior, o módulo LabVIEW FPGA, combinado com um hardware que inclua tecnologia de entradas e saídas reconfiguráveis (RIO – Reconfigurable I/O) oferece resposta de hardware em nanosegundos. Use o conjunto de software da National Instruments para:

· Desenvolver rapidamente aplicações determinísticas com programação gráfica ou ANSI C · Criar facilmente controles distribuídos e sistemas de monitoração · Eliminar o tempo gasto integrando diversas entradas e saídas

A National Instruments oferece uma variedade de hardware de tempo real que contém um processador embarcado executando um sistema operacional de tempo real para máxima confiabilidade e desempenho determinístico. É possível integrar uma vasta gama de entradas e saídas com hardware modular que possa ser expandido para atender a um grande número de canais para aquisição de dados e controle, condicionamento de sinais industriais e isolação segura.

Figura 3. A Tecnologia de Tempo Real da National Instruments