Os sistemas computacionais estão presentes em diversas áreas de nosso cotidiano. Fazemos uso deles quando realizamos uma transação bancária via Internet, dirigimos nosso carro ou escutamos música com um tocador de CD portátil. De fato, com a proliferação dos sistemas dedicados de controle, grande parte dos dispositivos que usamos contam com um processador digital, que é responsável pelo controle de suas funcionalidades.

Nesse conjunto de aplicações, destaca-se um grupo de sistemas que são limitados pelo tempo, os chamados sistemas em tempo-real. Como os sistemas anteriores, esses também realizam tarefas de controle e processamento de informações, mas com um diferencial: suas respostas ao ambiente devem ser retornadas em tempo hábil ou o sistema irá entrar em um estado inconsistente de funcionamento.

Um exemplo comum de sistema em tempo-real é o computador de controle de uma usina nuclear. As tarefas de controle dos processos desse tipo de sistema são extremamente complexas e exigem máxima confiabilidade. As ações realizadas pelo controle devem ser executadas em tempo correto ou um desastre ocorrerá. “Sistemas em tempo-real são aplicados ou estão engajados em atividades do mundo real, as quais são inerentemente complexas” (CARNEIRO, 2001, p.58). Será usado o termo sistema em tempo-real em um sentindo bem amplo, referindo-se ao sistema inteiro, incluindo o ambiente, o software e hardware do computador.

Os sistemas em tempo-real podem ser encontrados em várias outras áreas de aplicação, como:

• Sistemas de navegação para veículos;
• Controle de tráfego aéreo;
• Sistemas de monitoramento de vida;
• Controle de processos industriais;
• Sistemas distribuídos de multimídia.

Neste artigo, serão abordados os principais conceitos dos sistemas em tempo-real: suas características, classificação e principais linguagens de desenvolvimento.

1. CONCEITOS DE TEMPO-REAL

“O funcionamento correto de sistemas em tempo-real depende não somente do resultado lógico da computação, mas também do tempo em que os resultados são produzidos” (STANKOVIC, 1988, p.10).

Um sistema em tempo-real é basicamente composto por um sistema de controle, interfaces de entrada e saída e um ambiente, explicados a seguir:

• Sistema de controle – é responsável por responder aos estímulos do ambiente em tempo hábil. “É dito reativo porque sua tarefa primária é responder ou reagir aos sinais do ambiente” (SHAW, 2001, p.1).
• Interfaces de entrada e saída – são as portas de comunicação entre o sistema de controle e o sistema controlado. Geralmente, são sensores, atuadores, receptores de sinais de rádio, entre outros.
• Sistema controlado – é o ambiente com que o computador interage (cf. STANKOVIC, 1996, p. 206).

Então, sistemas em tempo-real são sistemas computacionais que monitoram, controlam ou respondem a ambientes externos. Além disso, devem cumprir várias restrições de tempo impostas pelo comportamento do sistema externo (cf. SHAW, 2001, p.1).

O fato de fornecerem resposta em tempo hábil requer que os sistemas em tempo-real tenham o comportamento determinístico. Além disso, é necessário que outros aspectos entrem na especificação de projetos em tempo-real. São eles:

• Previsibilidade – em vez de ser rápido (que é um termo relativo), a mais importante propriedade de um sistema em tempo-real deve ser sua previsibilidade, que definese como: seu comportamento funcional e temporal deve ser tão determinístico quanto impõe as especificações do sistema (cf. STANKOVIC, 1988, p.11). 
• Confiabilidade – está relacionada à exatidão no funcionamento do sistema, ou seja, a falha do sistema é que pode gerar uma resposta fora do tempo esperado;
• Desempenho – o sistema deve ser eficiente o suficiente para lidar com a complexidade inerente ao ambiente de comportamento em tempo-real;
• Compactação – geralmente as soluções de sistemas em tempo-real são embarcadas, o que implica recursos reduzidos de processamento, memória e fontes de alimentação.

1.2. Interações entre o Sistema de Controle e o Ambiente

O sistema de controle interage com o ambiente usando as informações disponibilizadas por vários sensores. É imperativo que o estado do ambiente, como percebido pelo sistema de controle, seja consistente como o real estado do ambiente. Então, o monitoramento periódico do ambiente e o processamento temporizado das informações dos sensores são necessários (cf. STANKOVIC, 1996, p. 206).

As restrições de tempo mais comuns para tarefas em sistemas em tempo-real são as periódicas, as aperiódicas e as esporádicas. Segundo STANKOVIC (1996, p. 206), estas são as definições para tarefas em sistemas em tempo-real:

• Tarefa periódica – é uma tarefa que é ativada a cada “T” unidades de tempo. O seu limite de execução para cada ativação pode ser menor, igual ou maior do que o período “T”.
• Tarefa aperiódica – é uma tarefa ativada em períodos indeterminados.
• Tarefa esporádica – é uma tarefa aperiódica com a restrição adicional de possuir um intervalo mínimo entre ativações de tarefas.

Analisando o exemplo dado por LI & YAO (2003, p.11) sobre as interações entre os sistemas de controle e sistemas controlados, vê-se que ele é baseado em um sistema de defesa em tempo-real para navios de guerra. O objetivo do sistema é destruir os projéteis lançados contra a embarcação, antes que eles a atinjam. O sistema é composto por um sistema de radar – que rastreia e procura por alvos em potencial e repassa a localização do alvo ao D&C constantemente – um sistema de Decisão e Comando (D&C) – que deve caracterizar o grau de ameaça, calcular a trajetória a partir das informações do sistema de radar e apontar as armas, através do sistema de controle de armamentos, para a área calculada e as ativar até que o alvo seja eliminado – e um sistema de controle de armamentos. O sistema de controle é o sistema D&C, os sistemas controlados são o sistema de radar e o sistema de controle de armamentos, que são também interfaces com o ambiente externo.

A comunicação entre o sistema de radar e o D&C é aperiódica. Apenas quando um alvo for detectado é que o radar irá passar suas informações para o D&C. Por outro lado, a comunicação entre o sistema de armamentos e o D&C, depois da detecção do alvo, é periódica, visto que o D&C deve constantemente atualizar a posição das armas, em altíssima freqüência.

2.TIPOS DE SISTEMAS EM TEMPO-REAL

Os sistemas em tempo-real podem ser classificados em relação ao cumprimento de seus prazos de resposta ao ambiente, os deadlines. Deadline é o tempo limite que o sistema deve responder e/ou atuar para garantir sua consistência, sendo uma meta que deve ser perseguida e alcançada sempre.

Alguns sistemas são mais tolerantes às perdas de deadlines, ou seja, eles continuam em funcionamento mesmo não retornando suas respostas em tempo correto. É claro que o acúmulo de faltas pode levar o sistema para um estado inconsistente. Geralmente, esses sistemas contam o número de faltas ocorridas e, a partir de certo valor, acionam uma rotina de proteção e/ou correção. “Esses sistemas são chamados de soft real-time, em que a perda ocasional de um deadline é aceitável” (TANENBAUM, 2001, p.19).

Um bom exemplo de sistema em tempo-real soft é um aparelho de DVD. O aparelho de DVD realiza algumas atividades, tais como ler e decodificar o disco DVD, enviar as informações de vídeo e som para as respectivas saídas e receber comandos através do controle remoto. É aceitável que o decodificador perca algum deadline quando o aparelho é submetido a uma rápida série de comandos do usuário. A penalidade é uma momentânea, mas visível, distorção do vídeo ou do áudio.

Por outro lado, existem sistemas que um deadline não alcançado significa grande prejuízo econômico e/ou humano. Esses sistemas são do tipo hard real-time; um sistema de navegação de mísseis teleguiados é um bom exemplo do mesmo. O sistema deve ser constantemente realimentado com novas posições, de modo que possa desviar dos obstáculos ambientais e ainda atingir seu alvo. Caso o comando de reposicionamento não seja processado no tempo desejado, o míssel poderá colidir com uma montanha, ou pior, com habitações civis. “Se a ação deve acontecer absolutamente em um certo momento (ou em certo intervalo), temse um sistema em tempo-real hard ” (TANEBAUM, 2001, p.19).

Não se tem como caracterizar, de modo preciso, um sistema em tempo-real como hard ou soft. A maioria dos sistemas se encontra em algum lugar entre essas duas definições (cf. SHAW, 2001, p.2). Um sistema em tempo-real seria uma composição de tarefas hard e soft.

O projetista deve ter essa idéia bem clara na mente quando for escolher a estratégia de escalonamento e prioridade dos processos do sistema. “Design ar prioridades de tarefas não é um exercício trivial, por causa da complexidade natural dos sistemas em tempo-real” (LABROSSE, 2001, p.73). Uma estratégia mal formulada pode acarretar em perdas contínuas de deadlines.

Por exemplo, o processo que controla os sensores de ambiente, responsáveis por detectar obstáculos, do míssel teleguiado deve ter maior prioridade do que o processo que faz a comunicação com a central base. É fácil perceber o porquê: se a leitura dos sensores é feita de forma “lenta”, o sistema de navegação estará sendo alimentado com dados antigos, o que acarretará em uma possível colisão não desejada. Um atraso na comunicação com a central base não significa um grande prejuízo para o objetivo do sistema, que é atingir o alvo.

3.CARACTERÍSTICAS DE UM SISTEMA EM TEMPO-REAL

Algumas características são inerentes aos sistemas de comportamento em tempo-real, porém nem todos os sistemas em tempo-real irão apresentar todas estas características. A seguir, algumas delas são apresentadas:

• Requisitos de tempo determinísticos – “ deadlines e outras asserções concernentes a tempo são expressas em termos de valores fixos e exatos, ao invés de medidas médias” (SHAW, 2001, pg. 3). O motivo é que variações no tempo de execução das tarefas significam falhas de sistema, principalmente se o sistema for hard.
• Execução Concorrente – Sistemas em tempo-real devem lidar com a concorrência natural das tarefas, que faz parte do mundo externo conectado ao sistema (cf. SHAW, 2001, p. 3). Além disso, a concorrência pode ser usada para aumentar o desempenho do sistema, usando-se processadores em paralelo.
• Confiabilidade e tolerância a faltas – “Confiabilidade pode ser entendida como a probabilidade de um sistema funcionar corretamente em um intervalo de tempo completo, o qual depende da aplicação em questão” (CARNEIRO, 2001, p. 6). Porém, nenhum sistema é perfeitamente confiável e falhas podem ocorrer. “Tolerância a faltas está relacionada com o reconhecimento e gerenciamento das falhas” (SHAW, 2001, p. 3).
• Tamanho e Complexidade – As dificuldades no desenvolvimento de software estão diretamente ligadas ao tamanho e à complexidade de programas. Sistemas em tempo-real são aplicados ou estão engajados em atividades do mundo real, as quais são inerentemente complexas (cf. CARNEIRO, 2001, p. 58). Esta complexidade é passada para o software de controle. Por isso, as linguagens de desenvolvimento para tempo-real devem fornecer facilidades para decompor sistemas complexos em módulos independentes, que são mais facilmente manipulados.
• Manipulação de Números Reais – Diversas atividades de controle industrial fazem uso de controle por realimentação, que manipula dados associados à saída do sistema, realimentado-os à entrada para posterior comparação e geração de um sinal de erro (cf. CARNEIRO, 2001, p. 59). Então, um sistema em tempo-real deve ser hábil a lidar com matemática complexa.

4. LINGUAGENS DE DESENVOLVIMENTO PARA APLICAÇÕES EM TEMPO-REAL

As linguagens serão apresentadas de acordo com suas facilidades para sistemas em tempo-real, não cabendo ao escopo deste trabalho um detalhamento mais profundo.

Real-Time UML

A Linguagem Unificada de Modelagem (UML) é uma linguagem usada para expressar construções e relacionamentos de sistemas complexos. Iniciou como uma resposta do Grupo de Modelagem de Objetos (OMG) a uma requisição de uma linguagem padrão de modelagem orientada a objetos.

Vem sendo usada em projetos de sistemas comercias, distribuídos, web services, dentre outros, com bastante sucesso. A UML possui um mecanismo de extensão da linguagem que permite flexibilizar sua notação para aplicações mais específicas.

A UML é mais completa do que outras linguagens no seu suporte para sistemas complexos e é particularmente preparada para sistemas embarcados em tempo-real (cf. DOUGLASS, 2001, p. 14).

Suas maiores características são:

• Modelo de objetos;
• Casos de uso e cenários;
• Modelagem comportamental com diagramas de estados;
• Empacotamento de vários tipos de entidades;
• Representação de tarefas e sincronização de tarefas;
• Modelos de topologia física;
• Modelos da organização do código fonte;
• Suporte a padrões de projetos orientados a objetos.

No trabalho de SELIC & RUMBAUGH (1998), encontram-se algumas extensões para modelagem de sistemas em tempo-real. O diagrama de estados da UML fornece poderosas ferramentas para o projetista de sistema modelar as restrições de tempo do sistema. E como o diagrama é uma máquina de estados finita, pode-se obter um modelo matemático de fácil comprovação do sistema.

OCCAM

OCCAM é uma linguagem para aplicações científicas e de engenharia, para processos de controle industrial e para sistemas embarcados. OCCAM foi originalmente projetado para transputer (contração entre transistor e computer), uma arquitetura microprocessada, desenvolvida pelo INMOS, que suporta concorrência e sincronização.

A OCCAM possui características especiais para solução de problemas de programação concorrente (cf. CARNEIRO, 2001, p.35) e a semântica formal da linguagem auxilia a transformação e validação dos programas em modelos matemáticos.

Em OCCAM, as partes de um programa são tomadas como processos que executam suas funções e terminam. Pode-se ter mais de um processo sendo executado concorrentemente e processos podem trocar mensagens entre si (cf. CARNEIRO, 2001, p.35).

A comunicação é feita através de um construtor especial da linguagem chamado canal. Um canal é um caminho unidirecional de comunicação entre dois processos concorrentes e é implementado na prática usando regiões alocadas de memória, se os processos estão residentes no mesmo transputer, ou por links de comunicação dos transputers, se os processos comunicantes estiverem em diferentes transputers.

HANDEL C

Handel – C é uma linguagem de programação parecida com C projetada para fornecer compilação de programas em implementações sincrônicas de hardware, geralmente baseadas em FPGA. Desta forma, desenvolvedores de software podem, com uma curva de aprendizagem curta, implementar projetos em hardware.

As implementações em hardware têm como principal vantagem a performance, isto é, é possível se conseguir um paralelismo verdadeiro em um programa escrito em Handel – C. Cada instrução é executada simultaneamente em blocos separados de hardware, a linguagem permite primitivas de sincronização entre blocos paralelos de execução chamadas canais de comunicação (cf. AUBURY et al, 2000, p.11).

Quando um bloco paralelo é encontrado, ocorre uma divisão na execução das instruções e cada novo ramo segue executando simultaneamente. Após o término da execução de cada ramo, o fluxo do programa segue de forma seqüencial. A Figura 1 ilustra a situação. O procedimento de comunicação através de um canal pode ser exemplificado da seguinte maneira: um ramo paralelo libera o dado sobre o canal e o outro ramo lê o dado deste canal; a comunicação através de canais é sincronizada (cf. CARNEIRO, 2001, p. 45). O paralelismo e concorrência são importantes pois os eventos do mundo real podem ocorrer simultaneamente.

ADA

A ADA é uma linguagem desenvolvida pelo Departamento de Defesa Americano com o intuito de prover uma solução robusta para projetos de aplicações críticas. Foi originalmente desenvolvida no início da década de 80 (ADA 83) e então revisada e melhorada para a linguagem ADA 95, que foi a primeira linguagem de programação orientada a objetos padronizada internacionalmente (ISO).

A ADA possui características fortes de modularização que auxiliam na construção de grandes sistemas, fornecendo ainda métodos de encapsulamento de informações. Além disto, a ADA disponibiliza recursos avançados de concorrência: as tarefas ADA podem comunicar entre si implicitamente, através de regiões compartilhadas de memória, ou explicitamente por meio de rendezvous.

O rendezvous em ADA possui as seguintes características: comunicação não armazenada e sincronizada, identificação assimétrica – a tarefa fonte conhece a identidade da tarefa destino, mas o contrário é falso, fluxo de dados bidirecional (cf. CARNEIRO, 2001, p. 36).

Em ADA, as primitivas de comunicação e sincronização são baseadas em passagens de mensagens, todas as ações de processos simples são atômicas, desde que não existam variáveis compartilhadas e o próprio processo não comunique durante a ação. Esta característica é importante para as fases de avaliação e confinamento de danos e recuperação de erros de sistemas tolerantes a faltas (cf. CARNEIRO, 2001, p. 37).

A ADA possui recursos de gerenciamento de tarefas inerentes a sua especificação, as tarefas em ADA possuem prioridades e seguem a política de escalonamento preemptivo, a tarefa em execução cede o direito de execução para a tarefa de maior prioridade e pronta para executar. Segundo ISO (2001), as implementações de ADA tem permissão de definir recursos adicionais e definir políticas de alocação correspondentes a estes. Tais recursos devem ter uma implementação definida na política de despacho de tarefas, que gerencia a alocação de tarefas nas filas de estado de tarefas.

Real-Time JavaTM

A Plataforma Java foi desenvolvida pela Sun Microsystems como uma solução portável, orientada a objetos, distribuída e segura para o desenvolvimento de aplicações comerciais. Devido a sua portabilidade, Java vem sendo utilizada em diversos ambientes, desde aplicações para dispositivos embarcados até aplicações corporativas (cf. GOSLING, 1996).

Os princípios que norteavam o projeto de Java eram discordantes com os requisitos de aplicações em tempo-real. A independência de sistema operacional e hardware implicaram em pouco detalhamento nas questões de comportamento de threads, sincronização, gerenciamento de memória e interrupções, entrada e saída.

Tendo em vista isso, a Java Community Process (JCP), a pedido da IBM, organizou um grupo de experts da indústria da computação para produzir e publicar a Especificação de Java para Tempo-Real (RTSJ). Os trabalhos do grupo foram focados em sete áreas principais: escalonamento de threads, gerenciamento de memória, sincronização e compartilhamento de recursos, gerenciamento de eventos assíncronos, transferência de controle assíncrona, terminação assíncrona de threads e acesso à memória física.

Segue algumas características interessantes de Real-Time Java encontradas em BOLLELA et al (2000): “A RTSJ definiu o conceito de objeto escalonável, que é um objeto que implementa a interface schedulable. A instância do objeto Scheduler é responsável por escalonar os objetos da classe schedulable. Existe espaço na especificação para o usuário definir seus próprios algoritmos de escalonamento, o padrão é o preemptivo com 28 prioridades. O gerente de memória heap de Java, comumente chamado de coletor de lixo, é considerado como um empecilho para a programação em tempo-real devido ao seu comportamento imprevisível. A solução encontrada foi permitir a alocação de memória fora da área de heap do coletor de lixo, isso é conseguido através de áreas de memória que possuem características específicas em relação a duração dos objetos alocados nela. Threads esperando por um recurso são organizadas seguindo a ordem de elegibilidade, ou seja, através da prioridade que foi designada pelo desenvolvedor do sistema. A RTSJ também definiu proteções contra o problema de inversão de prioridades, bastante comum em sistemas em temporeal”.

Referências

AUBURY, Matthew; PAGE, Ian; RANDALL, Geoff; SAUL, Jonathan; WATTS, Robin.
Handel-C Language Reference Guide. Oxford University Computing Laboratory, 1996.

BOLLELA, Greg; BROSGOL, Bem; FURR, Steve; HARDIN, David; DIBBLE, Peter;

GOSLING, James; TURNBULL, Mark. The Real-Time Specification for JavaTM.

Massachussetts: Addison-Wesley, 1 Ed. 2000.

CARNEIRO, P. Régis. Gerenciador de Processos para Aplicações em Tempo-Real: Uma Experiência com Arquitetura DSP (Processador de Sinal Digital), Fortaleza, 2001.

Dissertação de Mestrado em Engenharia Elétrica apresentada ao Departamento de Engenharia Elétrica da Universidade Federal do Ceará.

GOSLING, James; MCGIHON, Henry. The Java Language Enviroment, 1996. Disponível em http://java.sun.com/docs/white/langenv/ .

LABROSSE, Jean j. Embedded Systems Building Blocks. San Francisco: CMP Books, 2. ed. 2002.

LI, Qing; YAO, Caroline. Real-time concepts for Embedded Systems. San Francisco: CMP Books, 1. ed. 2003.

SHAW, Alan C. Real-time Systems and Software. New York: John Wiley & Sons, 1. ed. 2001.

SELIC, Bran; RUMBAUGH, Jim. Using UML for Modeling Complex Real-Time Systems. 1998.

STANKOVIC, John A. Misconceptions About Real-Time Computing. IEEE Computer: out. 1988.

STANKOVIC, John A. Real-Time and Embedded Systems. ACM Computing Surveys. V. 28, n. 1, mar. 1996.
TANENBAUM, Andrew S. Modern Operational Systems. New York: Prentice Hall, 3. Ed. 2000.

Este artigo é uma compilação, efetuada pelo autor, do capítulo 2 do seguinte trabalho: Estudo Comparativo de Kernels de Sistemas Operacionais em Tempo-Real – Fortaleza, 2005. Monografia de graduação do curso Tecnólogo em Telemática apresentada ao Centro Federal de Educação Tecnológica do Ceará.

 

Otávio Alcântara

Otávio Alcântara é Tecnólogo em Telemática pelo CEFET-CE e especializado em desenvolvimento de software em tempo real para sistemas embarcados.