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çãoentre 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

 1.3.1 Definições:

o 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