Sistema operacional de tempo real(vx works)

1. 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

2. 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

3. 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

4. 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.

5. 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

6. 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

7. 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é

8. 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

9. 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.

10. 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.

11. 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

12. 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 73 %
memória
Tamanho de blocos não fixo de 82 %
memória
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 %

13. 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.

14. 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.

15. 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.

16. 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/