Trampo

Transcript

Introdução A ploriferação da tecnologia dos computadores afeta praticamente todas as áreas da humanidade. Mais e mais aplicações usam computadores que interagem com dispositivos externos, reagem a estímulos externos, e usualmente controlam o ambiente. Essas características requerem que o software seja projetado usando ferramentas e métodos além do comum. Elas requerem conhecimento de desenvolvimento de software para sistemas em tempo real. Pode-se citar como exemplos destes sistemas: equipamentos médicos, sistemas aviônicos, controle de tráfego aéreo, controle de armas, entre outros. Os desenvolvedores de software devem estar familiarizados com os conceitos básicos que distinguem um sistema de tempo real de sistemas onde estados críticos de tempo, segurança e resposta a estímulos externos não são importantes. Conceitos como tempo, concorrência, sincronização e comunicação, compartilhamento de recursos e manuseio de dispositivos externos são de extrema importância nestas aplicações. Os sistemas em tempo real devem garantir o funcionamento do sistema, de modo que uma mínima falha pode causar resultados catastróficos. 1. Sistemas Operacionais em Tempo Real 1. Sistemas Operacionais Um sistema operacional (SO) é um software que implementa as seguintes funções: Permitir multitarefa. Essa seção do SO é conhecida como kernel. Ela consiste em diversos processos que realizam funções como criação de novas tarefas, decisão de qual tarefa irá rodar em determinado momento, prover o mecanismo que comute o processador de uma tarefa para outra e prover os princípios que permitam o acesso controlado aos recursos compartilhados. Fornecer uma interface de máquina virtual para os componentes de Entrada/Saída (I/O) conectados ao computador. Isso significa que o SO deve conter software para servir de interface entre as aplicações do usuário e o hardware base sem que a aplicação tenha que saber nenhum detalhe de como o hardware funciona. Além disso, o SO deve controlar o acesso a este hardware, já que diversas tarefas em um sistema multitarefa podem estar requisitando os I/Os ao mesmo tempo. Esse é o principal fator pelo qual esta interface deve estar no SO. O SO fornece gerenciamento de memória. Este gerenciamento permite a alocação e desalocação de memória pelas tarefas de usuário. Finalmente, o sistema operacional fornece um software de controle de arquivos que permite que aplicativos manipulem os arquivos em dispositivos como disquetes ou discos rígidos sem ter que se preocupar com a alocação de blocos físicos na memória. Resumindo, o SO deve fornecer mecanismos para compartilhamento e controle de acesso a recursos. O termo recurso se refere tanto a coisas físicas (como uma impressora) ou até entidades de software (como uma estrutura de dados). Os sistemas operacionais podem ser divididos em duas grandes categorias baseado nas aplicações que eles podem servir: Sistemas em tempo real Sistemas não em tempo real Existem discussões para definir o que é um sistema de tempo real. Por exemplo, um sistema de agendamento de vôos é um sistema em tempo real? Obviamente quando um operador agenda algum vôo ele espera que o computador responda em alguns segundos. Ou seja, existe uma restrição de tempo que define até quanto à performance do computador é aceitável. Muitos cientistas da computação consideram esse como um exemplo de sistema de tempo real. Engenheiros por outro lado não considerariam esse como um sistema de tempo real. Um sistema de tempo real para engenheiros tem restrições de tempo pesadas em oposição a restrições de tempo leves. Uma restrição de tempo pesada é definida como uma restrição que se violada resultara no não comprimento de alguma função pelo sistema. Por exemplo, os aviões F-18 usam um sistema de computador para controlar seu sistema de acompanhamento de solo. O algoritmo que controla esse sistema deve ser executado precisamente 40 vezes pro segundo. Se essa precisão de tempo não é mantida o avião pode ficar instável e cair. Portanto este seria considerado um sistema em tempo real. Agora voltando ao sistema de agendamento de vôos. A restrição de tempo neste caso não é pesada – se o operador tiver que esperar um pouco de tempo a mais pela resposta isso não causará nenhum problema. O agendamento será feito da mesma maneira. 2. Sistemas Operacionais em Tempo Real (RTOS – Real Time Operation System) 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 (como o exemplo do avião F-18 já citado). 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. POSIX Quando se fala em sistemas operacionais, se fala também em POSIX. Este é o nome de uma família de normas relacionadas definidas pelo IEEE e designada formalmente por IEEE 1003. Essas normas dizem respeito ao desenvolvimento de sistemas operacionais. A normalização das especificações POSIX surgiu de um projeto, iniciado por volta de 1985, que tinha como objetivo normalizar a interface de programação de aplicativos (API – Application Programming Interface) de software desenvolvido para rodar em variantes do sistema operacional UNIX. O termo POSIX é uma sigla aproximada para Portable Operating System Interface, com o X representando uma herança do sistema UNIX. Essa norma define uma interface e ambiente para um sistema operacional padrão, incluindo um interpretador de comando, programas de utilidade comum que fornecem suporte à portabilidade de aplicações em nivel de código fonte. Além disso, as normas POSIX incluem suporte para portabilidade de aplicações com requisitos em tempo real, porém essas normais são opcionais para os sistemas de tempo real. Estes sistemas podem ser POSIX-compliant (que seguem essa normas) ou não. 3. VxWorks O VxWorks é um RTOS e 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. 1. 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 (retirado de www.windriver.com) 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 Vxorks 2. Recursos básicos do sistema 1. 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. 2. Manuseio 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. 3. Comunicação 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. Manuseio 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. 3. Riqueza 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 "73 % " "memória " " "Tamanho de bloco 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. 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. 4. Sistemas utilizando VxWorks Os Rovers de exploração de Marte Spirit e Opportunity, além de diversas espaçonaves, como por exemplo, a missão Deep Impact. A Boing pretende usar como sistema operacional eu sua nova aeronave 787. O router wireless WRT54G da Linksys. Novas cameras digitais semi-profissionais (como Kodak, Casio). Diversos cable-modems também utilizam VxWorks, como os Motorola SurfBoard. Soluções médicas da Siemens. E diversos outros... 5. Referências 1. RTOS Evaluation Project - VXWORKS/X86 5.3.1 – Disponível em: . 2. Yerraballi, R. - Real Time Operating Systems 3. VxWorks – Disponível em: . 4. Kornecki, A. J., Zalewski J., Eyassu D. – Learning Real-Time Programming Concepts through VxWorks Lab Experiments 5. Betz, R. – Introduction to Real Time Operating Systems – Department of Electrical and computer Engineering. University of Newcastle, Australia. 2001.