Embed Size (px)
Citation preview
Sistema operacional de tempo-realOrigem: 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ção2. Sistemas operativos3. 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 kernel5. Serviços operativos de TR comerciais6. 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 preentivoNum 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 RealContents
[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
