Faculdade Joaquim Nabuco

Curso Superior de Tecnologia em Redes de Computadores

Diogellys Stéffason Barros da Silva

Dayanne Maria Silva de França

Lyanderson Kennedy da Silva

José Augusto Soares da Silva

João Braz da Silva Júnior

Pesquisa Sobre sistemas

Operacionais de Tempo Real (RTOS)

Recife 2013

Diogellys Stéffason Barros da Silva

Dayanne Maria Silva de França

Lyanderson Kennedy da Silva

José Augusto Soares da Silva

João Braz da Silva Júnior

Pesquisa Sobre sistemas

Operacionais de Tempo Real (RTOS)

Pesquisa Sobre Sistemas

Operacionais de Tempo Real (RTOS)

Pela Faculdade Joaquim Nabuco

Orientador:

Professor Tiago Marques.

Recife 2013

SUMÁRIO

01 Introdução-----------------------------------------------------------------------------01

02 VxWorks -------------------------------------------------------------------------------01

03 Propósitos do VxWorks -----------------------------------------------------------02

04 Arquitetura do sistema-------------------------------------------------------------02

05 Sistemas utilizando VxWorks----------------------------------------------------10

06 Referências----------------------------------------------------------------------------12

PESQUISA SOBRE O SISTEMA OPERACIONAL DE TEMPO REAL (RTOS)

Alunos:

Lyanderson Kennedy da Silva (Lyanderson_kenedy@hotmail.com) Faculdade Joaquin Nabuco.

Dayanne Maria Silva de França (dayanne_daylinda@hotmail.com) Faculdade Joaquin Nabuco.

Diogellys Stéffason Barros da Silva (diopcb@hotamil.com.com) Faculdade Joaquin Nabuco.

José Augusto Soares da Silva (j.augusto_ss@yahoo.com.br) Faculdade Joaquim Nabuco.

João Braz da Silva Júnior (jjuniorbboy1930@gmail.com) Faculdade Joaquin Nabuco.

Orientador:

Professor Tiago Marques.

Palavras Chaves: Sistema Operacional de Tempo Real, RTOS, VxWorks,

Wind River Systems, Sistemas Embarcados, Curiosity.

1. Introdução.

1.1 Sistemas Operacionais em Tempo Real (RTOS)

Os RTOS são sistemas operacionais destinados à execução de múltiplas

tarefas onde o tempo de resposta a um evento (externo ou interno) é crítico e

deve ser tão menos quanto o sistema exigir. Num RTOS uma aplicação é

divida em diversas tarefas independentes. Cada uma dessas tarefas tem uma

prioridade conforme a importância da mesma. O tempo de processamento é

divido de forma que cada tarefa é executada em uma fatia de tempo. Cabe ao

SO controlar a comutação de tarefas, através de um agendador que decide

qual será a próxima tarefa a ser executada.

2. VxWorks

VxWorks é um sistema operacional de tempo real similar ao Unix

produzido e vendido pela Wind River Systems de Alameda, Califórnia, EUA.

Foi criado no começo dos anos 80, quando os fundadores da Wind River

resolveram usar seus conhecimentos adquiridos em sistemas de tempo

real. Eles tomaram algumas decisões fundamentais sobre como um sistema

de tempo real embarcado deveria ser e assim criaram o produto, que desde

então já teve 6 versões principais. Assim como outros sistemas

operacionais de tempo-real, o VxWorks contém um kernel multitarefa com

escalonamento preemptivo, rápida resposta às interrupções, meios de

comunicação entre processos e meios para sincronização, e sistemas de

arquivos. As características do VxWorks são o gerenciamento de memória

compatível com POSIX, facilidades para multiprocessadores, um shell para

interface de usuário, depurador com capacidade simbólica/código fonte, e

monitor de performance. VxWorks geralmente é empregado em sistemas

embarcados. Diferentemente dos sistemas Unix tradicionais, o

desenvolvimento no VxWorks é feito numa máquina hospedeira rodando

Unix ou Windows, compilando cruzado (cross-compiling) o software para

máquina alvo. A tarefa de execução é feita no alvo, mas pode ser feita no

hospedeiro, através de um simulador de alvo (VxSim).

3. Propósitos do VxWorks

Permitir multitarefa (Kernel).

Máquina virtual para E/S.

Gerenciamento de memória

Compartilhamento e controle de acesso a recursos.

4. Arquitetura do sistema

A filosofia da Wind River é de utilizar dois sistemas operacionais

complementares e cooperativos, deixando que cada um faça o que tem de

melhor. De um lado está a máquina host, que roda um sistema operacional

comum, como por exemplo, o Windows, e é utilizada para desenvolvimento de

aplicativos apenas. Do outro lado temos a máquina target, que roda o VxWorks

e lida com as tarefas de tempo real. Apenas um pequeno agente de debug esta

residente na target, todo o resto de desenvolvimento do software roda na host.

Desta maneira, a máquina host serve apenas como uma plataforma de

desenvolvimento de software. É nela que deve ser rodado o TORNADO, que é

o ambiente de desenvolvimento da Wind River, e acompanha o VxWorks. Mas

é na máquina target que a aplicação em tempo real realmente funciona,

rodando totalmente em sistema operacional VxWorks. A

Fig. 1 exemplifica essa arquitetura de dois sistemas operacionais.

Fig. 1 - Arquitetura do sistema com host e target

No coração do VxWorks roda um micro-kernel (que nada mais é que um kernel

com o mínimo de funcionalidades possível) chamado de Wind. Este micro-

kernel suporta toda uma faixa de funções de tempo real incluindo multitarefas,

agendamento e comutação das tarefas, sincronização/comunicação entre

tarefas e manuseio de memória. Todas as outras funcionalidades são

implementadas, como processos. O VxWorks é bem expansível. Incluindo ou

excluindo diversos módulos, ele pode ser configurado para ser usado em

pequenos sistemas embarcados, com pesadas restrições de memória, até

sistemas mais complexos, onde são necessárias mais funções. Além disso,

módulos individuais também são expansíveis. Funções individuais podem ser

removidas da biblioteca, ou objetos de sincronização do kernel podem ser

omitidos se não forem necessários para uma aplicação.

Fig. 2 - Arquitetura de sistema do VxWorks

4.1 Recursos básicos do sistema

Manuseio de tarefas: O kernel de tempo real do VxWorks (Wind) um ambiente

básico de multitarefa. Cada tarefa tem seu próprio contexto, que é o ambiente

de CPU e os recursos do sistema que ela vê quando é agendada pelo kernel

para execução. Em uma mudança de contexto, o contexto da tarefa é salvo em

uma coisa chamada Bloco de controle de tarefa (Task Control Block, TCB). O

VxWorks oferece tanto um mecanismo de agendamento próprio (Wind

scheduling) como um agendamento POSIX. Dois algoritmos de agendamento

são disponibilizados:

- Agendamento prioritário preemptivo: este é o algoritmo default no Wind. Ele

garante que a CPU seja alocada para a thread com maior prioridade pronta

para rodar. Quando uma thread com uma prioridade maior que a que esta

rodando fica pronta para rodar, o kernel imediatamente muda o contexto para a

de maior prioridade. Para threads de prioridade igual, um agendamento por

uma FIFO é utilizado.

- Agendamento Round-Robin: este algoritmo é uma extensão do agendamento

prioritário preemptivo. Ele tenta compartilhar a CPU mais igualmente entre

todas as threads de prioridade igual. Para isso ele designa uma fatia de tempo

para as threads, e estas não podem ser executadas por mais que este tempo

determinado. Quando o tempo acaba, o kernel muda o contexto para outras

threads de mesma prioridade, e essas são executadas pelo mesmo tempo

designado.

As diferenças entre o agendamento POSIX e o Wind são as seguintes:

O agendamento POSIX é baseado em processos, e o Wind em tarefas.

No POSIX, quanto maior o número, maior a prioridade, já no Wind é o

contrário, quanto menor o número, maior a prioridade. Para toda thread

pode ser designado um nível de prioridade de 0 a 255 (256 níveis de

prioridade). O número de threads é limitado apenas pelo espaço em

memória. O VxWorks tem ainda um grande conjunto de funções

relacionadas às tarefas. Por exemplo, uma tarefa pode se proteger de

ser deletada inesperadamente, pode desativar o agendamento para que

a mesma não seja preemptada (manuseio de interrupções ainda irá

funcionar), etc.

4.2 Manuseios de memória

No VxWorks todas as chamadas de sistema e tarefas compartilham o mesmo

espaço de memória. Isso quer dizer que aplicações defeituosas podem

acidentalmente acessar recursos do sistema e comprometer a estabilidade de

todo o sistema. Porém, a Wind River oferece um componente adicional

(VxVMI), que deve ser comprado a parte, e permite que cada processo tenha

sua própria memória virtual. O VxWorks (sem o VxVMI) tem algum suporte

para proteção de memória. Mas os detalhes de como esses mecanismos

funcionam depende da plataforma que esta sendo utilizada. Para

processadores x86, por exemplo, o usuário pode configurar endereços de

memória como válidos ou inválidos. Se o processador tenta acessar um espaço

invalido, ou áreas que não estão mapeadas da memória, um erro é gerado.

Quando tarefas compartilham o mesmo espaço, elas são na verdade threads.

Para ser qualificada como um processo, uma tarefa deve ter seu próprio

espaço na memória. De acordo com as normas POSIX, um processo é um

espaço de memória com ao menos uma thread sendo executada e os recursos

de sistema para aquela thread.

4.3 Comunicações entre tarefas

O VxWorks fornece um rico conjunto de mecanismos para comunicação entre

tarefas, com destaque para alguns:

Memória compartilhada, para simples troca de dados.

Semáforos, para exclusão mútua e sincronização.

Filas de mensagens, para troca de informações entre as tarefas através

da CPU.

Sinais, para manuseio de interrupções.

4.4 Manuseios de Interrupções

Para conseguir repostas o mais rápidas possíveis a interrupções externas, os

serviços de rotinas de interrupção (Interrupt Routine Services, IRSs) rodam em

um contexto especial, fora do contexto das threads, para que desta maneira

não haja trocas de contexto de threads envolvidos. Em circunstancias normais,

todas as ISRs usam o mesmo stack de interrupções. Esse stack é alocado e

inicializado pelo sistema na hora em que o mesmo é ligado. Para evitar erros

no stack, o tamanho dele deve ser suficiente para lidar com o pior caso

possível de interrupções alojadas. Algumas arquiteturas não permitem um

stack de interrupções separado. Neste caso, as ISRs usam o stack da thread

interrompida. Isso significa que o stack das threads deve ser grande o

suficiente para lidar com o pior caso possível de interrupções mais o pior caso

possível de chamadas comuns.

4.5 Riquezas de APIs

Interface de programação de aplicativos (Application Programming Interface,

API) é um conjunto de rotinas e padrões estabelecidos por um software para

utilização de suas funcionalidades por programas aplicativos – isto é,

programas que querem usar os serviços de um software, por exemplo, mas

não querem se envolver em detalhes de implementação. De modo geral, a API

é composta por uma série de funções acessíveis somente por programação, e

que permitem utilizar características do software menos evidentes ao usuário

tradicional. As normas POSIX definem uma grande lista de APIs que um

sistema operacional deve ter, assim como um RTOS. O VxWorks suporta uma

grande parte das chamadas básicas de sistema da POSIX 1003.1b, incluindo

primitivas de processos e diretórios, primitivas de I/O, serviços de linguagem e

manuseio de diretórios. Além disso, o VxWorks aderiu as normas POSIX

1003.1b Extensão para Tempo Real, incluindo I/O assíncrono POSIX-

compliant, semáforos contadores, filas de mensagens, sinais, manuseio de

memória e controle de agendamento. A tabela mostra a porcentagem que o

VxWorks tem de APIs em relação aos determinados pelas normas POSIX.

Tabela 1 - Riqueza de APIs

Mecanismos Riqueza de

APIs

Manuseio de threads 94 %

Clock 57 %

Timer de intervalo 100 %

Tamanho de bloco fixo de partição de

memória

73 %

Tamanho de blocos não fixo de

memória

82 %

Manuseio de interrupções 38 %

Semáforo contador 70%

Semáforo Binário 100 %

Mutex 92 %

Variável condicional 0 %

Flags de evento 0 %

Sinais POSIX 100 %

Fila de mensagem 81 %

Mailbox 0 %

Porcentagem Geral 63 %

O VxWorks tem a maior porcentagem geral de todos os RTOS

atualmente.

4.6 Ferramentas e método de desenvolvimento

A Wind River tem um ambiente integrado de desenvolvimento para aplicações

embarcadas chamado Tornado. Ele é um ambiente totalmente open source,

isto é pode ser customizado e estendido pelos desenvolvedores. Sua interface

aberta faz com que seja possível integrá-lo com outras ferramentas de

desenvolvimento de terceiros.

O Tornado vem com um extensivo conjunto de ferramentas. Além de

ferramentas tradicionais como compiladores e debbugers, ele também fornece

ferramentas para realizar análises de dados de tempo real (Stethescope),

ferramentas para detectar falta de memória e ferramentas de recuperação de

código. Para ajudar os desenvolvedores de sistemas embarcados com

hardwares customizados, a Wind River também oferece o VxSim, que é uma

ferramenta de prototipagem e simulação para o Tornado/VxWorks. Ele permite

uma simulação do VxWorks no computador host. Com essa ferramenta, o

desenvolvimento de aplicativos pode começar antes de se ter o hardware

disponível.

5 Sistemas utilizando VxWorks.

5.1 VxWorks, o sistema operacional do robô Curiosity.

Robô Curiosity que está explorando Marte

Dois computadores de bordo idênticos foram instalados no Curiosity, identificados simplesmente como A e B. Cada um possui um processador PowerPC RAD 750, com 200 MHz, 256 GB DRAM, 256 KB EPROM e 2GB de memória flash. Durante o trabalho do Curiosity somente um dos computadores

permanece ativo, enquanto o outro assume o papel de backup. A troca entre os computadores pode ser feita a qualquer momento, mas ela não é periódica. Os computadores podem operar os instrumentos e os atuadores sem qualquer alteração no código enviado pelo controle da missão. A única diferença está nas câmeras de engenharia. Cada computador possui seu próprio conjunto de câmeras, e é exclusivo. O computador B não pode usar as câmeras do computador A e vice-versa. Esses computadores controlam todas as fases da missão, desde a fase de cruzeiro interplanetário até as operações na superfície, trocando apenas de modo de operação. Quando pousou ele estava configurado como nave espacial, após o SkyCrane liberar o robô na superfície (este também controlado pelos computadores do Curiosity) ele trocou seu estado para as operações de superfície. Também há o modo de segurança, nesse modo todos os instrumentos e atuadores são desligados a sonda fica a espera de contato do controle da missão. Esse estado é provocado geralmente por falha de software.

Um software embarcado roda sobre o sistema operacional de tempo real

(RTOS) VxWorks multitarefa, usado desde 1997 na missão Mars Pathfinder.

Desenvolvido pela Wind River Systems, pode rodar em processadores x86( e

x86-64), PowerPc e ARM, com um ou mais núcleos, e executa programas em

Ada, C, C++ e Java. Além de ser o sistema operacional das sondas de

superfície também roda na Mars Reconaissance Orbiter, no Airbus A400M e no

ASIMO. No total o software contém 2,5 milhões de linhas de código, totalmente

em C, e pode ser atualizado a qualquer momento.

5.2 Outros Produtos que utilizam VxWorks

A Boing usa como sistema operacional em sua aeronave 787.

O router wireless WRT54G da Linksys.

Novas câmeras digitais semiprofissionais (como Kodak, Casio).

Diversos cable-modems também utilizam VxWorks, como os Motorola

SurfBoard.

Soluções médicas da Siemens.

E diversos outros...

Referências:

Carlos. E Morimoto-Introdução Sobre Sistemas Embarcados. Guia do

Hardware. Net (http://www.hardware.com.br/).

Sistemas Operacionais Modernos 3º Edição – Andrew S. Tanenbaum.

http://www.compromissodigital.com/2012/09/vxworks-o-sistema-operacional-do-

robo.html/

http://lunokhod.blogspot.com.br/2012/07/mars-science-laboratory-ou-

curiosity.html/

www.embarcados.com.br/

http://pt.wikipedia.org/