Um tempo não tão real: um ensaio sobre a evolução do ... · Un tiempo no tan real: un ensayo...

Um tempo não tão real: um ensaio sobre a evolução do termo e suas consequências sobre a vida, a engenharia e a operação de sistemas

A time not so real: an essay on the term’s evolution and its consequences on life, engineering and system operations Un tiempo no tan real: un ensayo sobre la evolución del término y sus consecuencias sobre la vida, la ingeniería y las operaciones del sistema

Mauricio Carvalho dos Santos

ResumoO acelerado processo de desenvolvimento tecnológico acarreta mudanças culturais das quais tardamos a nos dar conta.

Isto acontece com o conceito de tempo e de tempo real na mente dos atores envolvidos nos sistemas de informação com-plexos. Na esfera industrial, os sistemas informatizados se integram desde o sensor do “chão de fábrica” até os níveis mais elevados da hierarquia organizacional e este sinergismo associado ao ciclo de vida cria situações inesperadas. O conceito de tempo real tem evoluído ou se modificado com a tecnologia e os grupos culturais, sofrendo algumas vezes uma efetiva trans-formação do objeto e do conteúdo. O artigo procura avaliar estas mudanças, os cuidados decorrentes da evolução cultural, algumas das consequências perceptíveis e faz uma série de recomendações. Os impactos vão desde o nível da concepção de dispositivos de lógica embarcada até o projeto, construção e operação de instalações industriais complexas, como nos permite antever o futuro, dentre outros, os sistemas de automação das refinarias, as plataformas costa-fora assistidas ou desassistidas e os sistemas submarinos da Petrobras.

palavras-chave: n tempo n tempo real n sistema de tempo real n sistemas em linha n sistema operacional de tempo real n sistemas complexos n simulação n controle de processos n automação n cibernética n engenharia de software n engenharia de sistemas n ergonomia

AbstractThe rapid rate of technological development involves cultural changes, which we appear to be slow to appreciate. This ha-

ppens with the concept of time and real time in the minds of the people involved in complex information systems. In the indus-trial sphere, computerized systems are integrated from the “factory floor” sensor to the highest levels of the organizational hie-rarchy and this synergy associated with the life cycle creates unexpected situations. The concept of real time has evolved or been changed by technology and cultural groups sometimes undergoing an effective objective and content transformation. The article seeks to evaluate these changes, the warnings arising from the cultural evolution, some of the perceivable consequen-ces and makes a number of recommendations. The impacts range from the outset concept of logical devices to the design pro-

Boletim Técnico da Petrobras, Rio de Janeiro, v. 52, n. 1/3, p. 39-61, abr./ago./dez. 2009 n 39

ject, construction and operation of complex industrial facilities, as we can foresee, among other things, in the future automa-tion systems of refineries, off-shore manned or unmanned platforms and the subsea systems for Petrobras.

keywords: n time n real time n real time system n online systems n real-time operating system n complex systems n simulation n process control n automation n cybernetics n software engineering n engineering systems n ergonomics

ResumenEl rápido ritmo de desarrollo tecnológico implica en cambios culturales, que nos parecen ser lentos de apreciar. Esto acontece

con el concepto de tiempo y de tiempo real en la mente de las personas involucradas en los sistemas de información complejos. En el ámbito industrial, los sistemas informáticos están integrados desde el sensor del “piso de la fábrica” hasta los niveles más altos de la jerarquía de la organización y esta sinergia acoplada con el ciclo de la vida, crea situaciones inesperadas. El concepto de tiempo real ha evolucionado o ha sido cambiado por la tecnología y los grupos culturales a veces están sometidos a una trans-formación eficaz de objetivo y contenidos. El artículo trata de evaluar estos cambios, las advertencias que surgen de la evolución cultural, algunas de las consecuencias perceptibles haciendo una serie de recomendaciones. Los efectos van desde el concepto del inicio de los dispositivos lógicos para el proyecto de diseño, hasta la construcción y explotación del complejo de instalaciones industriales, como se puede prever, entre otras cosas, en los futuros sistemas de automatización de las refinerías, las plataformas off-shore tripuladas o no tripuladas y los sistemas submarinos de Petrobras.

palabras-clave: n tiempo n tiempo real n sistema de tiempo real n sistemas en línea n sistema operativo en tiempo real n sistemas complejos n simulación n control de procesos n automatización n cibernética n ingeniería de software n sistemas de ingeniería n ergonomía

IntroduçãoEstamos vivendo um novo tempo. Ao longo de cerca de

30 mil anos, a espécie humana apenas intuía o tempo pelos ciclos da natureza. Em contraste, hoje é possível entrar em uma sala de um lar ou escritório e encontrar três ou mais dis-positivos eletrônicos exibindo valores numéricos diferentes para o mesmo instante do tempo (quando não estão piscan-do 00:00:00).

Este artigo tem por objetivo chamar a atenção para uma questão da modernidade, qual seja, o significado de tempo e de tempo real, e das consequências destes sobre os sistemas cada vez mais sofisticados de produção de bens e serviços. Pela primeira vez na história da humanidade, em decorrência dos avanços da eletrônica e da informática, o tempo pode ser

tratado como uma variável manipulada. Dentro desta moderni-dade despontam novas formas de mal-entendidos e de poten-ciais desvios, falhas e até acidentes, em decorrência da litera-tura técnica, das especificações de requisitos, do projeto, da construção de simuladores1, na integração de redes de comu-nicação e na instalação de soluções complexas de controle de processos. A questão do tempo e do tempo real nos comple-xos sistemas de controle industriais pode criar situações se-melhantes a da atuação de um criminoso que usualmente não deixa pistas ou, quando as deixa (numa lista de operação), não repete o mesmo padrão no próximo crime!

A Questão do TempoO tempo não é exatamente uma variável, no sentido que

atribuímos ao espaço ou a outras variáveis medidas. Mui-

Um tempo não tão real: um ensaio sobre a evolução do termo e suas consequências sobre a vida,...

1. Simulador: são sistemas (usualmente programas de computador) que implementam modelos (do mundo físico) permitindo alguma forma de iteração dinâmica.

40 n Boletim Técnico da Petrobras, Rio de Janeiro, v. 52, n. 1/3, p. 39-61, abr./ago./dez. 2009

tas indagações podem ser feitas ao seu respeito, como por exemplo: O tempo existe ou é uma experiência humana? Qual será a “forma” do tempo, será ele cíclico, linear, curvo, relativo ou novas descobertas nos aguardam? Será o tempo homogêneo em todas as direções e em todo o tempo?

Uma investigação sobre a história do tempo é apresen-tada por Whitrow em seu livro “O que é tempo?” (Whitrow, 2003). Uma abordagem mais restrita a respeito do tempo sob o enfoque da física, dentre outros, pode ser encontrada nos livros de Hawking (Hawking 2000, 2006).

Esta compreensão moderna do tempo emerge da fron-teira tecnológica do ensino a distância em artigo de Baccarin (2004). Segundo este autor, conceituar o tempo é tarefa di-fícil, uma vez que este pode conter vários outros “tempos”, cada qual com sua característica própria e distinta. Para efei-to sistemático, é possível distinguir dois grupos bem distin-tos de pluralidades temporais: cronológicas e kairológicas. Inicialmente podemos dizer que chronos2 é o tempo do re-lógio e kairós3 é o tempo da sensibilidade. Sabemos a hora certa de um encontro pelo relógio: isto é chronos; mas, sa-ber a hora certa de falar o que deveríamos dizer, isto é kairós. A medida de precisão do chronos é expressa pelos ciclos do movimento pendular ou mesmo do relógio atômico. A medi-da de precisão do kairós está em divisarmos o precioso mo-mento, que corresponde à fina película que separa um “ainda não” de um “agora é tarde”. O chronos é tempo quantitati-vo, tempo do relógio, do calendário, o tempo contado que tem como metáforas a disciplina, a ordem, a harmonia e a perfeição. Deriva do aperfeiçoamento tecnológico, cuja ori-gem está nos primeiros relógios mecânicos na Idade Média até os atuais clock dos computadores pessoais, que expres-sam a velocidade e o poder de processamento. As experi-ências pós-modernas do tempo, o apoio e a influência das novas tecnologias, em especial as eletrônicas, permitem à sociedade moderna privilegiar os tempos pedagógicos4. Este tempo pedagógico confere uma dimensão temporal ao pro-cesso de aprendizagem, que deve superar em muito o tempo cronológico (horários). Notadamente, a aprendizagem trans-cende o tempo efetivamente dedicado a ela (como no laser e no sonho).

Os autores citados, corroborados por vários outros, dis-tinguem a existência de três tempos. Assim, existe um tem-po físico, cronológico, que sob certos limites se pode mensu-rar. Existe também o tempo percebido, em função de nossos relógios biológicos ou de relógios naturais que influenciam nossa percepção. Num sentido mais humano, existe tam-bém o tempo sentido, vivido, algumas vezes intuído, que de-termina uma tomada de decisão, uma narrativa, uma lem-brança e, em parte, o aprendizado.

As medidas de tempo que são feitas em um experimento decorrem do estabelecimento de uma relação entre dois fe-nômenos: o do estudo e o do dispositivo de tempo, ou seja, o do relógio. Usamos relógios para constatar a regularidade de fenômenos e escolhemos, para relógio, fenômenos que ob-servamos como regulares. De certa forma, todos os fenôme-nos contêm seu próprio relógio, com a sua métrica particular. Segundo Whitrow (2003), com o desenvolvimento dos re-lógios artificiais modernos, ultraprecisos (como o relógio de césio), adequados para medir com exatidão intervalos mui-to curtos de tempo, e no uso de relógios radioativos naturais, para determinar os intervalos muito longos, está implícita a suposição de que todos os átomos de um dado elemento comportam-se da mesma maneira, qualquer que seja o lu-gar ou a época.

O termo Tempo Fenomênico será empregado para ex-pressar o tempo cronológico associado à dinâmica interna de um fenômeno, em distinção aos tempos calculados por computador para simulação do mesmo fenômeno. O termo fenomênico significa “relativo ao fenômeno”, o que expressa suas características objetivas e subjetivas.

A consciência humana, no continuo de suas atividades, não divisa entre passado e futuro, estando corriqueiramente focada no agora. Assim, passa despercebido o fato de que todas as medidas registradas em nossos experimentos, os dados medidos que são utilizados para construir algoritmos ou estratégias, representam um tempo passado, enquanto o emprego que é feito dessas medidas corresponde a um tem-po futuro. O passado foi o tempo da medida, o futuro é o tempo do uso, do cálculo. O trânsito mental entre passado


2. Chronos: personagem da mitologia grega, filho de Urano e Gaia, historicamente têm sido associado a uma dimensão da temporalidade humana.3. Kairós: personagem da mitologia grega que representa um atleta de características obscuras; palavra grega que significa o momento certo.4. Tempo pedagógico: o tempo efetivamente dedicado ao processo de aprendizagem. Classicamente corresponde ao tempo em sala de aula. Modernamente está em debate.


e futuro ocorre num tempo imaginado. Modernamente, re-servamos o termo Tempo Virtual para o tempo dentro de um “universo virtual”, ou seja, construído eletronicamente (emu-lado). A figura 1 é uma representação pictórica da relação entre estes tempos, o fenômeno, o sistema e o ser humano. A “realidade virtual” corresponde ao envolvimento da consci-ência humana com o universo virtual através de uma interfa-ce imersiva. Reside aqui a intrigante questão: o universo vir-tual existe na ausência da consciência humana?

Dentre várias relações possíveis, a figura 1 expressa um “tempo virtual percebido” pela superposição do “tempo vir-tual” com o “homem no sistema” e com o “tempo kairoló-gico”; expressa a “consciência do tempo virtual mediada por artefatos” pela superposição do “universo fenomênico” com o “homem no sistema” e com o “tempo cronológico”; e expressa o “virtual como fenômeno lógico e eletrônico” pela superposição do “tempo virtual” com o “universo fe-nomênico” e com o “tempo cronológico” (se o virtual inde-pender de uma consciência humana). A representação con-tém, também, simplificações, como representar apenas o recorte do universo com o qual o sistema interage (univer-so fenomênico).

Diferenças de tempo penetram nossas medidas de forma mais sutil, como quando dois relógios são sincronizados, pois ambos os eventos são eventos distintos e sucessivos. A sin-

cronização exige uma troca de informação e, portanto, um lap-so. O tempo da ação de sincronização permanece como um resíduo, na forma de uma antecipação ou retardo. Nossa men-te compensa estas distorções e assincronismos e nos leva a trabalhar como se não existissem intervalos entre sincronis-mos. No papel, ou no universo virtual do computador, temos o poder de tratar passado e futuro como se fossem um mesmo instante. Por exemplo, no instante “agora” o algoritmo calcula com dados colhidos no instante anterior (passado) a posição do objeto num instante posterior (futuro). No entanto, a posi-ção real do objeto no agora, para este algoritmo, permanece desconhecida e a verdadeira posição no futuro não depende apenas da precisão dos cálculos mas, dentre outras incerte-zas, da própria medida de tempo e da sincronização entre ar-tefatos. Não é usual considerar incertezas em relação ao tem-po na avaliação ou projeto de um algoritmo de controle.

Num cenário como o de uma unidade experimental de pro-cesso químico, modernamente controlado, existem diferentes tempos envolvidos: cada módulo microprocessado possui seu próprio relógio; cada módulo de programa determina tempos de execução; cada fenômeno do processo físico-químico apre-senta sua dinâmica e tempos intrínsecos; cada operador reage segundo seus tempos: biológico e cognitivo; e em cada treina-mento, cada treinando5 tem seu tempo pedagógico.

Além destes conceitos, existe também a semântica do tempo em computação, como encontramos em Farines (2000)i onde o tempo cronológico recebe diferentes identificações:

• Tempo na Execução (recurso a ser gasto durante a exe-cução de um programa, como outros recursos físicos ou lógicos) e o Tempo na Programação (grandeza a ser manipulada pelo programa, como outros tipos de vari-áveis); na execução, o tempo intervém de forma implí-cita, enquanto que na programação, ele pode ser visto de forma implícita ou explícita;

• Tempo Lógico (definido a partir de relações de prece-dência entre eventos, o que permite o estabelecimen-to de ordens causais sobre um conjunto de eventos) e o Tempo Físico (tempo métrico que permite expressar quantitativamente à distância entre eventos e estabe-lecer ordens totais entre eles);

Figura 1 – Relação entre os tempos, o fenômeno, o sistema e o ser humano.

Figure 1 – Relationship between the times: the phenomenon, the system and human beings.

Figura 1 – Relación entre los tiempos: el fenómeno, el sistema y los seres humanos.


5. Treinando, aqui empregado dada a perspectiva do treinamento continuado.


• Tempo Denso (segue a natureza uniforme e contínua do tempo físico, e é isomorfo ao conjunto dos números re-ais) e o Tempo Discreto (simplificação geralmente acei-ta do Tempo Denso, porém, isomorfo em relação ao conjunto dos números naturais positivos);

• Tempo Global (noção abstrata que permite ao usuá-rio de um sistema distribuído ter acesso a um instante de referência único em qualquer parte do sistema) e o Tempo Local (observável localmente nos diferentes nós de um sistema distribuído); tanto o tempo global quan-to o tempo local podem ser físicos ou lógicos;

• Tempo Absoluto (referência estabelecida a partir de um evento global) e Tempo Relativo (tem como referência um evento local); o tempo absoluto é sempre global, enquanto o tempo relativo é sempre local.

Complementando esta classificação, o mesmo autor des-taca que o tempo cronológico é relativo e depende do obje-to e de referenciais, e também que o tempo pode ser um ins-tante ou um intervalo válido.

Um Tempo não tão RealEmpregamos como termo técnico a expressão “tempo

real” em nossas atividades de modelagem, simulação, con-trole e programação. No entanto, se estendermos a reflexão sobre o tempo, feita anteriormente, precisamos nos pergun-tar se é possível precisar o termo tempo real num ambien-te multidisciplinar (do conjunto das disciplinas requeridas no projeto, na construção ou integração, e no uso ou operação). Precisamos também verificar se, mesmo dentro do nosso campo restrito, não o empregamos de forma dúbia e, talvez, até nos equivoquemos na aplicação do conceito.

Ao longo de quase toda a história da humanidade a ex-

pressão tempo real esteve associada à experiência do tempo cronológico, tendo por alternativa o tempo irreal, imaginário ou transcendental. Com a modernidade, ao longo das duas grandes guerras mundiais, o computador eletrônico analógi-co se tornou operacional. Apresentava uma velocidade iné-

dita para a época, como na solução das equações de um modelo matemático, como o calculo de tiro antiaéreo6. Usu-almente o computador analógico era tão rápido, ou seja, o tempo de simulação tão pequeno, que o termo tempo real passou a ser empregado para designar a simulação que era ajustada para evoluir segundo o tempo do processo físico real que estava sendo simulado. Deste modo, o termo “tem-po real” se contrapunha ao novo conceito de tempo, o tem-po simulado acelerado. Já na década de 1950 surgem as primeiras publicações e especificações onde o termo tem-po real é empregado para designar uma simulação que res-ponde segundo o tempo do processo físico. Durante cerca de quatro décadas, o significado técnico de tempo real ficou restrito à comunidade dos técnicos que lidavam com simu-lação com dispositivos eletrônicos (analógicos ou digitais).

Recordar o estágio da tecnologia eletrônica no início da computação analógica ajuda na compreensão da distinção en-tre retardo e espera, numa simulação computacional. De certa forma, podemos dizer que, na computação analógica, o algo-ritmo é o computador. Isto significa que o ajuste do algoritmo para o tempo do fenômeno é feito pela introdução de um re-tardo no algoritmo. Nos modernos computadores digitais, usu-almente este ajuste é feito pela introdução de uma espera no programa, que assim pode aproveitar o tempo ganho com a si-mulação acelerada para outras atividades. Deste modo, retar-do é uma alteração temporal introduzida no algoritmo, alteran-do seu estado intrínseco com consequência sobre o “tempo simulado”, enquanto espera é uma alteração temporal introdu-zida no programa. Complementando a conceituação, o mode-lo do fenômeno físico contempla atrasos inerentes a dinâmica do fenômeno, tais como o chamado tempo morto. Concluindo: atraso é parte do modelo, retardo é uma manipulação do algo-ritmo e espera é um artifício de programação.

Não é muito fácil encontrar esta questão do tempo real sendo tratada na literatura de simulação de processos quí-micos. Recorrendo a outras áreas, Pettersson (1999), defi-ne um sistema em tempo real como um sistema computa-cional cuja ‘corretude’7 (correctness) depende não apenas da


6. O computador analógico nos idos de 1943 corrigia a posição do canhão antiaéreo a partir de informações do rastreio da aeronave (ótico ou radar). Este computador não era dotado de memória como nos digitais (as versões com esta capacidade são chamados de híbridos), sendo assim, a resposta do calculo é a posição do canhão. Como o tiro é uma ação humana independente, o algoritmo tinha que ser executado de forma a disponibilizar o resultado no instante preciso, posicionando continuamente o canhão, ou seja, em tempo real para o tiro.7. Corretude é um neologismo empregado em computação ao invés do termo correção para evitar a frequente ambiguidade de significados: “tornar correto”, “verificar se está correto” e “estar correto”. Significa que o algoritmo ou código executam de forma eficaz.


saída (output), mas também do instante no qual esta saída é produzida. Por esta definição, um sistema de tempo real é um sistema que reage no instante adequado em relação a outro sistema, processo, equipamento ou ser vivo. Instante adequado significa que o momento da reação de um siste-ma de tempo real pode não ser o tempo do real, da realida-de, do relógio (chronos). Como, por exemplo, um simulador de treinamento com tempo acelerado, desde que responda no instante adequado, é um sistema de tempo real e, neste sentido, jogos de computador, que operam com tempo ace-lerado, são sistemas de tempo real. Notemos que, para jo-gos de simulação (em tempo real), o que importa é a emo-ção que provoca no jogador e não a reprodução do tempo do fenômeno simulado. O tempo adequado para um jogo poder ser kairós em vez de chronos. Temos ainda que essa defini-ção requer que a reação seja oportuna, no sentido de que o sistema deve reagir atendendo às restrições temporais. As-sume-se, assim, a existência de uma escala de tempo glo-bal como referência para o sistema e o ambiente. Uma esca-la de tempo significa que o tempo pode ser medido, mas não necessariamente implica na existência de um relógio global no sistema. Os componentes do sistema de tempo real po-dem ter seus próprios relógios, que podem ser considerados como relógios locais, sendo a comunicação via canais entre os componentes. Na maioria das linguagens para tempo real, como Occam28 e Ada9, é considerada apenas a forma sim-ples de sincronização do controle de fluxo com confirmação (handshaking), que é implementada usualmente por um me-canismo simples de encontro (rendezvous10).

Retomando a questão do tempo, todo fenômeno da na-tureza possui o seu próprio ritmo de evolução, inerente à di-nâmica interna do processo (físico), que é possível associar a um tempo cronológico. Sendo o fenômeno a realidade com que se interage, a melhor definição de tempo real ainda se-ria a do tempo correspondente ao tempo cronológico do fe-nômeno. Nesta definição, o tempo real seria uma espécie de tempo, com todas as suas propriedades. Para que haja uma interação entre o sistema computadorizado e seu meio en-volvente é preciso que o sistema atue sobre o meio a tempo, isto é, de acordo com o respectivo tempo real. Dessa forma, o meio impõe ao sistema requisitos temporais, de acordo

com seu tempo real e sua dinâmica (Almeida, 2004). Nes-ta definição o tempo real é o do ambiente envolvente, não o do sistema computadorizado, sendo expresso por requisi-tos e iterações.

Almeida, (2004) resume a classificação dos sistemas computacionais em três classes, são elas:

• transformacional, onde os dados de entrada são trans-formados em resultados ou dados de saída;

• reativo, onde um programa pode executar indefinida-mente uma sequência de interações, como por exem-plo, operando sobre um fluxo de dados;

• de Tempo Real, onde o programa tem que se manter sincronizado com o fluxo de dados, o qual impõe restri-ções temporais à execução do programa.

Em decorrência desta forma de classificação, pelas me-tamorfoses da semântica, o termo “Tempo Real” passou a designar uma classe específica de sistemas computacionais (e não mais uma relação temporal com o fenômeno). O mes-mo Almeida (2004) conceitua também o termo tempo real como uma propriedade do sistema computacional que ca-racteriza a capacidade deste de estabelecer correspondên-cias entre diferentes sistemas de medição e/ou contagem de tempo. Sendo que esta dependência de um sistema compu-tacional face ao tempo pode ser do tipo:

• funcionalidade ou Serviço de Tempo Real: que tem de ser desempenhada ou prestada dentro de intervalos de tempo finitos, sendo estes impostos por um processo físico (externo);

• sistema de Tempo Real: aquele que desempenha pelo menos uma funcionalidade de tempo real ou que pres-ta pelo menos um serviço de tempo real.

A partir de agora, e enquanto a evolução da tecnologia não modifica a semântica, o termo tempo real passa a significar também uma classe de sistemas. A diferença de um Siste-ma em Tempo Real (STR) para os sistemas tradicionais de pro-cessamento de dados decorre dos STR possuírem restrições de requisitos não funcionais. Exemplo de requisitos não fun-


8. Occam 2: é uma linguagem de programação utilizada em computação paralela, desenvolvida por David May e outros na empresa inglesa INMOS Ltd.9. Ada: linguagem de programação encomendada pelo Ministério de Defesa dos Estados Unidos nos idos de 1974.10. No mecanismo de encontro os processos emissores e receptores permanecem bloqueados no ponto de sincronização, até que todos os envolvidos executem e alcancem este ponto em seus fluxos particulares.


cionais são requisitos de segurança e de temporização. Des-te modo, um sistema eficiente de simulação de tempo real deve requerer um modelo que satisfaça tanto os objetivos da simulação do fenômeno quanto às restrições de tempo (Lee e Fishwick, 2001). O desenvolvimento de sistemas de tempo real requer cuidados e ferramentas especiais, tanto na fase de projeto, quanto nas de programação ou de teste. Dada a diver-sidade e a complexidade crescente dos campos de aplicação, estas ferramentas muitas vezes não existem, não são adequa-das ou só têm emprego acadêmico. O autor salienta este fato ao afirmar que isto: “se deve à carência de suporte explícito (de linguagem) para expressar as restrições temporais das fer-ramentas CASE (Computer Aided Software Engeneering) usa-das na modelagem de sistemas em tempo real” (a despeito de toda a evolução desta área de conhecimento). Corroborando também com a experiência da comunidade técnica que aplica industrialmente estes dispositivos, o autor observa que alguns dos problemas temporais só são reconhecidos durante a fase de testes ou, pior ainda, após a liberação para uso.

A precedência do fenômeno sobre o tempo real pode ser entendida por meio do seguinte exemplo de projeto e de ope-ração de uma unidade piloto de destilação em batelada.

Nesta unidade, a queda da primeira gota separa a fase inicial de aquecimento da fase de destilação e dispara uma série de eventos e sequências. O feixe luminoso de um dis-positivo ótico é interceptado pela queda da gota, marcando o início da destilação. O feixe luminoso é calculado para ser posicionado secante ao local onde a gota passa em queda li-vre e em baixa velocidade. Na modelagem para o projeto do sistema, a gota foi assumida como um objeto em queda li-vre, numa trajetória retilínea entre o ponto inferior do bico do condensador e o recipiente de coleta. A simulação do siste-ma modelado mostrou que os requisitos de tempo real eram atendidos. Após alguns meses de operação normal consta-

tou-se que sob certas condições de vibração do equipamen-to, associada com aderências imperceptíveis de material dentro do bico, a corrente de líquido escoava em uma curva-tura e a gota se formava em outro ponto do bico, caindo sem interromper o feixe luminoso. Um conjunto de gotas subse-quentes cortava o feixe, introduzindo um erro de sequencia-mento. Este exemplo destaca o fato do fenômeno poder con-ter situações inimagináveis na fase de especificação e ilustra como um requisito temporal pode não ser atendido pelo sis-tema por uma variabilidade do processo físico que controla.

Segundo Guillies (apud Navarro, 2006), a execução cor-reta de um sistema em tempo real depende tanto da exati-dão de sua lógica quanto do tempo no qual os resultados fo-ram obtidos. Se as restrições de tempo não forem atingidas, diz-se que uma falha ocorreu.

Em Beaumont (2004) é possível encontrar novamente o mes-mo texto de Guillies, com o complemento de que os resultados das computações devem atender a dois critérios de correção:

• logicamente corretos: o sistema produz saídas adequa-das, como função das entradas, assegurando o com-portamento desejado do sistema;

• temporalmente correto: o sistema respeita restrições de tempo produzindo as saídas antes de limites (dead- lines) de tempo.

O autor ainda acrescenta que isto decorre da constante evolução do ambiente. Um sistema estático não é um siste-ma em tempo real, pois não existe diferença entre dois esta-dos, exceto se uma ação ocorrer no ambiente.

De forma semelhante Dellazari (2004) declara que os sis-temas de tempo real são aqueles que dependem, além da corretude algorítmica, do atendimento de requisitos tempo-rais. Esta expressão captura, em parte, a essência dos tra-balhos acadêmicos sobre tempo real na última década: o desenvolvimento de métodos matemáticos que buscam ga-rantir o atendimento dos requisitos temporais.

Os sistemas de tempo real, ou seus limites de tempo, podem ser classificados em quatro classes de aplicativos, segundo diversos autores (Farines, 2000; Beaumont, 2004; Dellazari, 2004; Almeida, 2004, ...):

Figura 2 – Imagem de alta velocidade da queda da gota usada na modelagem.

Figure 2 – High speed image of the fall of the drop used in modeling.

Figura 2 – Imagen de alta velocidad de la caída de la gota utilizadas en el modelaje.



• Tempo Real Crítico (Hard Real-Time): são sistemas que garantem o atendimento de todas as restrições tem-porais, ou seja, as respostas ocorrerão obrigatoriamen-te dentro de um intervalo de tempo bem definido. Caso contrário o sistema incorre numa falha crítica, com sé-rios prejuízos e até catástrofes com perda de vidas. Este é o caso dos sistemas de controle de voo, de con-trole em plantas nucleares, de telecirurgias e de co-mando de sondas espaciais.

• Tempo Real Firme (Firm Real-Time): são sistemas onde atrasos esporádicos são toleráveis, degradam a quali-dade do serviço, mas a perda de um resultado não in-corre em risco catastrófico. Nestes sistemas a perda do prazo incorre na inutilidade do resultado, havendo a possibilidade de mecanismos compensatórios, como interpolação ou filtros, manterem a qualidade do servi-ço. São exemplos os sistemas de vídeoconferência e sistemas de controle de tráfego de rede.

• Tempo Real Flexível ou Brando (Soft Real-Time): são sistemas em que atrasos esporádicos não compro-metem a qualidade final, ou seja, o tempo de res-posta é importante, mas se um prazo for perdido não provoca graves prejuízos e um resultado tardio ain-da pode ser útil. Este é o caso da aquisição de dados, onde filtros podem corrigir eventuais perdas de dado; sistemas de gestão de laboratórios (LIMS); sistemas de Informação de Processos (PIMS); caixas automáti-cas (onde demora na realização da operação apenas aborrecem o usuário) e aplicativos multimídia como videoconferência.

Farines (2000) ainda subdivide a classe de Tempo Real Crítico em outras duas:

• “Sistemas de Tempo Real Crítico Operacionais em Caso de Falha (fail operational) que, na presença de falhas parciais, podem se degradar fornecendo algu-ma forma de serviço mínimo (por exemplo, sistema de controle de voo com comportamento degradado, mas ainda seguro)”;

• “Sistemas de Tempo Real Crítico Seguros em Caso de Falha (fail safe) onde um ou vários estados seguros po-dem ser atingidos em caso de falha (por exemplo, pa-rada obrigatória de trens no caso de falha do sistema de sinalização ferroviário)”.

De forma a completar esta subclassificação, segue a se-guinte contribuição:

• Sistemas de Tempo Real Crítico Inseguro em Caso de Fa-lha onde mais nenhum estado seguro pode ser atingido; qualquer falha é falha crítica; alguns dispositivos explora-tórios espaciais e armas de cruzeiro são projetados den-tro deste critério, uma falha de requisito de tempo no sis-tema equivale à perda da missão ou do alvo.

Podemos exemplificar esta classificação considerando uma analogia com um voo comercial, onde a missão crítica é transportar a tempo os passageiros entre os aeroportos: “A” e “B”. Representam quatro subsistemas os quatro motores do avião e a condição segura “estar pousado”. Temos ain-da que o avião pode voar somente com um motor (condição operacional), porém, por contrato, não pode voar com ape-nas dois motores. Assim, o avião voando com quatro moto-res é um Sistema de Tempo Real Flexível ou Brando. Devido à pane em um motor, a condição de cumprir o contrato corres-ponde a de um Sistema Tempo Real Firme, pois permanece operacional, com condição de cumprir o contrato, com pos-sível atraso tolerável. Devido à pane em dois motores, o con-trato está quebrado e o avião tem que pousar. Havendo al-gum aeroporto próximo, esta situação corresponde a de um Sistema Tempo Real Crítico Operacional em Caso de Falha, pois permanece operacional e com a possibilidade de alcan-çar um estado seguro (aeroporto). A despeito da perda do prazo, o objetivo ainda pode ser alcançado, posteriormen-te, com a troca de aeronave e novo voo (serviço mínimo). Se neste ínterim, se ainda em voo para o aeroporto alternativo, o terceiro motor do avião para, a situação evolui para a de um Sistema de Tempo Real Crítico Seguro em Caso de Falha se houver uma pista de pouso próximo (sem infraestrutura aero-portuária). Neste caso, a situação segura implica na impossi-bilidade de alcançar o destino “B”. No entanto, se tal evento ocorre em região isolada, ou sobre o mar, a situação passa a corresponder a de um Sistema de Tempo Real Crítico Insegu-ro em Caso de Falha.

Pelas definições da literatura, um sistema de controle de processos químicos é classificável como:

• de Tempo Real Crítico, se a perda de algum prazo pro-vocar acidentes, danos aos equipamentos e operado-



res, perdas econômicas intoleráveis, ou causar danos ao meio ambiente;

• de Tempo Real Firme, se os processos internos do sis-tema conseguem sempre fazê-lo se recuperar apenas com custos operacionais e de controle; e

• de Tempo Real Flexível, se as consequências se refle-tirem na qualidade da produção ou do produto, dentro de margens aceitáveis.

As restrições de tempo normalmente advêm da dinâmi-ca do processo físico que impõem as restrições: aos prazos de observação do estado do sistema; aos prazos de compu-tação dos novos valores de controle; às variações dos prazos anteriores (jitter); tendo que ser cumpridas em todas as ins-tâncias (incluindo o pior caso) e não apenas em termos mé-dios (Almeida, 2004).

Uma das crenças mais comuns é a de que o problema de tempo real se resolve pelo aumento da velocidade com-putacional. A rapidez do processamento melhora o desem-penho de um sistema computacional como um todo, mi-nimizando o tempo médio de resposta de um conjunto de tarefas. O objetivo de um cálculo em tempo real é o aten-dimento dos requisitos temporais individuais de cada uma das tarefas no fluxo de processamento destes sistemas. Ter um tempo de resposta curto, não garante que os requi-sitos temporais de cada processamento serão atendidos! O desempenho médio não resolve os conflitos temporais por recursos durante o processamento das diversas ativi-dades. Para os sistemas de tempo real, é mais importan-te o conceito de previsibilidade do que a rapidez de cálculo (Stankovic, 1998 Farines, 2000). Conforme Almeida (2004): “tempo real não significa rapidez, mas apenas um ritmo de evolução próprio de certo processo físico”. Por analogia, é como na dança, tem que seguir o ritmo.

“Aplicações com requisitos de tempo real tornam-se cada vez mais comuns. Essas aplicações variam muito em relação à complexidade e às necessidades de garantia do atendimento de restrições temporais” (Farines, 2000). No le-vantamento de requisitos, as prioridades costumam ser de-terminadas a partir da importância das funcionalidades. No entanto, num sistema real, para o escalonamento dos ser-viços, o grau de importância do atendimento das restrições temporais nem sempre permanece constante ao longo da

execução. Além das ferramentas usuais de programação não tratarem intrinsecamente da corretude temporal, outro fator que influi é o entendimento superficial do que seria tempo real por parte dos programadores. Parte significativa dos sis-temas de tempo real vem sendo projetada e implementada até hoje a partir do entendimento equivocado de que tem-po real é uma simples questão de melhoria no desempenho. Exemplos de aula, situações simuladas ou algumas aplica-ções para fenômenos dinamicamente simples reforçam esta “lenda”. Continua o autor: “A concepção do sistema de tem-po real é diretamente relacionada com o ambiente no qual está interagindo e com o comportamento temporal do mes-mo. Nos sistemas de supervisão e controle, distinguem-se o Sistema a Controlar, o Sistema Computacional de Controle e o Operador. O Sistema a Controlar e o Operador são consi-derados como o Ambiente do Sistema Computacional”. (Fa-rines, 2000).

O termo tempo real evolui do significado de “tempo da dinâmica do fenômeno” (na computação analógica) para o de classe de sistema. Isto possibilita a conclusão de Farines (2000): “a maior parte das aplicações de tempo real se com-portam como sistemas reativos com restrições temporais. Existindo também situações nas quais as restrições temporais não são impostas pelo comportamento dinâmico de um even-tual Sistema a Controlar, mas pelas exigências dos serviços a serem oferecidos a um usuário humano ou computacional”.

O projeto de Sistemas de Tempo Real

A modelagem baseada em contratos para os requisi-tos de tempo real de sistemas foram discutidas pesso-almente com Cerqueira (2002), entre reuniões de proje-to do Robô Ambiental Híbrido, no Centro de Pesquisas da Petrobras.

Da literatura de mecatrônica foram resumidas a seguir al-gumas das considerações de Auslander (1997) sobre o pro-jeto de software de sistemas de tempo real:

• o software para tempo real se diferencia dos conven-cionais no sentido de que seus resultados precisam ser disponibilizados no tempo correto. O autor desta-



ca: “Um corolário de projeto que se segue desta defini-ção é que o software para tempo real precisa conter o conceito de duração11”;

• a complexidade do software tende a crescer exponen-cialmente com o tamanho do programa (número de li-nhas, tarefas, etc.);

• a simulação propicia um ambiente computacional extre-mamente valioso para testes e depuração inicial de um programa ou sistema. O aspecto mais importante quan-to ao uso da simulação é que: o software básico pode ser testado em um ambiente computacional que é con-veniente e eficiente para uso; e relativamente fácil para depuração. O ambiente de simulação convencional é ri-gorosamente um ambiente de computação síncrona12, o que permite que os erros possam ser repetidos por nova execução do programa. Este não é, geralmente, o caso, quando o controle é operado em seu ambiente alvo (real, fenomênico), pois o programa de controle e o sistema alvo operam de forma assíncrona!

Mesmo relacionando (de forma imprópria) tempo real com velocidade de processamento, merece destaque o co-mentário de Auslander a respeito do Matlab13 e de outros geradores de aplicativo. Embora o Matlab, “não seja uma linguagem para implementação de tempo real, com um pro-cessador rápido pode-se alcançar um desempenho de tem-po real para objetos lentos de controle, como processos tér-micos. O Matlab permite acesso ao relógio do computador pela chamada da função ‘tic’ e ‘toc’: ‘tic’ dispara um cronô-metro; ‘toc’ lê o tempo cronometrado. O tempo de execu-ção pode assim ser acompanhado”. “A granularidade14 (in-cremento mínimo de ‘tic’) do relógio pode ser demonstrado por um pequeno programa que permanece lendo o relógio até uma mudança do tempo cronométrico registrado”.

Traçar a interface entre o tempo fenomênico e o tempo real para os subsistemas, pode não ser óbvio, como exem-plificado na figura 3 Neste caso, um conjunto de atuação inteligente é formado por: eletrônica de controle micropro-cessada, motor de passo e elemento final de atuação (vál-vula). Usualmente, na modelagem para controle, a válvula faz parte do fenômeno, juntamente com a parte analógi-

ca do acionamento. A parte digital, como o motor de pas-sos, o controlador inteligente e a rede de comunicação fa-zem parte do substrato invisível do sistema em tempo real. Este substrato invisível deve ser modelado pelos recursos de tempo real das ferramentas (linguagens, emuladores, etc.) utilizadas para modelar o fenômeno. Num modelo de controle, as funções de transferência e atrasos modelados da válvula são descritos matematicamente como parte do fenômeno, e em decorrência integram a sua simulação. É possível construir-se um modelo do fenômeno da planta in-dustrial de forma a simulá-la em paralelo com a operação. No entanto, para este substrato “inteligente”, a metodolo-gia de modelagem matemática ainda é insipiente no que tange à expressão do comportamento dentro do contex-to de todo o sistema quando em operação, controlando a planta. Ou seja, a simulação da variação do tempo real (por exemplo, dos requisitos), ao longo do ciclo de vida da insta-lação, ainda é uma grande lacuna.

Sistema Computacional de Tempo Real

Dada a modularidade da programação e a possibilidade da distribuição dos módulos entre diversos processadores, temos que, além da categoria de sistema de tempo real, existe outra: a categoria de sistema computacional de tempo real. De modo geral, um sistema de tempo real pode conter um ou mais sis-temas computacionais de tempo real (figura 4). Sob a orga-nização lógica, um sistema de tempo real pode residir num mesmo equipamento (computador) ou estar distribuído num conjunto de equipamentos interconectados (em rede).

Figura 3 – Atuador inteligente.

Figure 3 – Intelligent Actuator.

Figura 3 – Actuador inteligente.


11. Duração, interpretada como a de uma tarefa (task) sob a percepção de um engenheiro de aplicação, que implica em previsibilidade.12. O “ambiente síncrono” referido pelo autor corresponde ao cadenciamento, não necessariamente temporal, de atividades, tarefas e geração de resultados.13. Ferramenta de programação para a construção de modelos e simulação matemática da MathWorks Inc.14. Granularidade: em informática, o nível de detalhamento dos dados ou do objeto descrito.


Quando, utilizando uma “estação de trabalho” (micro-computador), desenvolvemos e testamos um algoritmo (de controle) contra um alvo simulado (processo físico simulado) na mesma estação de trabalho, a categoria deste sistema também é computacional de tempo real. Neste ambiente, as restrições temporais terminam sendo iteração entre tarefas e mesmo eventos esporádicos podem ser sincronizados (ca-denciados). Neste contexto, basta a relação da duração en-tre um segundo da aplicação e um segundo cronológico para que o sistema dê conta dos requisitos temporais. Para um sistema de tempo real, as exigências de projeto e de teste são maiores, na medida em que ele deve atender à diversas demandas assíncronas (descorrelacionadas), pela execução de tarefas concorrentes que disputam recursos críticos ex-ternos à eletrônica do computador. Se o sistema possuir vá-rios processadores, então os requisitos se ampliam com o aumento da complexidade.

Sistemas computacionais aplicados a situações de tem-po real contêm, ou são construídos a partir de um Sistema Operacional de Tempo Real (SOTR). Os SOTR são uma clas-se de sistemas operacionais que oferecem serviços para a construção de sistemas computacionais de tempo real. Os SOTR oferecem mecanismos para que sistemas computa-cionais de tempo real se comportem corretamente, meca-nismos estes que sistemas operacionais convencionais não possuem. Duas características importantes são a previsibili-dade e a baixa latência, além de outros serviços comuns a qualquer sistema operacional. Ponto chave nos SOTR são os algoritmos de escalonamento de tempo, núcleo da garantia da previsibilidade nos sistemas de tempo real. “A previsibi-lidade está associada à capacidade de poder antecipar, em

tempo de projeto, se os processamentos de um sistema de tempo real serão executados dentro dos prazos determina-dos” (Delazarri, 2004). Os algoritmos de escalonamento são área ativa de pesquisa na Ciência da Computação.

De forma resumida, a previsibilidade pode ser:

• “determinista: que garante que todos os limites de tempo serão alcançados”;

• “probabilista: que é baseada em estimativas; probabili-dades são associadas a prazos definindo as possibilida-des dos mesmos serem alcançados”.

“A previsibilidade deve afetar todos os níveis de um sis-tema de tempo real: linguagens, sistema operacional, arqui-tetura do computador, comunicação, etc.” (Delazarri,2004).

A latência, como expressão de tempo, significa o tempo entre o estímulo e a resposta. Dependendo da organização in-terna do sistema ou dispositivo, a latência destes é compos-ta por retardos e outras latências. A latência corresponde ao tempo útil durante o qual o dispositivo, sem manifesta reação externa, processa a reação. O retardo em um sistema ou dis-positivo é um tempo durante o qual não existe uma ativida-de de processamento, correspondendo a uma temporização15, um transporte, uma propagação, etc. Como exemplos: numa fechadura eletrônica temporizada, a latência corresponde ao tempo do mecanismo atuar sobre o fecho e o retardo, o tem-po transcorrido temporizando; numa agência bancária, a latên-cia é o tempo de atendimento pelo caixa e o retardo, o tempo gasto na fila. Em sistemas de telecomunicação, a latência e o retardo são usualmente tratados como sinônimos. Em um STR (Sistema em Tempo Real), a latência é o tempo gasto proces-sando os códigos críticos internos do sistema operacional ou os críticos do programa aplicativo. Para os STR, o que importa é a latência máxima, ou seja, o tempo de processamento dos trechos críticos na pior condição de sobrecarga.

É possível encontrar um levantamento bibliográfico refe-rente aos Sistemas Operacionais de Tempo Real em Baskiyar (2005). Para esta classe de sistemas operacionais o padrão IEEE Posix 1003.1b, Portable Operating System Interface for Computer Environments (formalmente 1003.4), estipula os critérios de conformidade para os serviços dos SOTR, ten-

Figura 4 – Composição de Sistema Computacio-nal de Tempo Real.

Figure 4 – Composition of a Real Time Computer System.

Figura 4 – del Sistema de computadora en tiempo real.


15. Note que, sendo a temporização um artifício de programa, ela corresponde a uma espera.


do sido concebido de forma a permitir a portabilidade entre Sistemas Operacionais de programas escritos por diferen-tes programadores. O autor ainda salienta que a escolha do sistema operacional é importante no projeto de sistemas de tempo real para: o suporte de prioridades, interrupções, tem-porizações, comunicação entre tarefas, sincronização, ge-renciamento de memória e de multiprocessamento. Baskiyar considerou os seguintes sistemas operacionais:

• Windows CE, para dispositivos com pouca memória; • LynxOS para sistemas de tempo real de prazo rígido;• VxWorks16 para sistemas embarcados; • Jbed17 para a plataforma Java; • pSOS18 para sistemas operacionais orientados a objetos.

No entanto, tem sido prática comercial corrente a utiliza-ção de sistemas operacionais que não fazem parte da classe de SOTR (como o Windows NT) na construção de sistemas de tempo real. Isto é factível em situações de tempo real não crí-tico, conforme comenta Timmerman (1997) “o Window NT se tornou incrivelmente popular para ser aplicado em Sistemas de Tempo Real”. Algumas razões podem ser listadas, tais como:

• a API Win32 é considerada um padrão e existe um grande número de programas disponíveis para ela;

• a interface gráfica é tão popular que restaram poucos competidores;

• o NT tem uma grande quantidade de soluções comer-ciais prontas;

• todos os tipos de ferramentas de desenvolvimento es-tão disponíveis para o ambiente NT.

A avaliação a seguir se baseia nos produtos Windows face à sua popularidade e uso em aplicações de tempo real, a despeito de suas limitações, muitas vezes desconhecidas ou ignoradas. Ressalte-se que, sistemas baseados em Linux e suas versões para tempo real estão crescendo em popula-ridade e disponibilidade de aplicativos e ferramentas.

Para aplicação de tempo real crítico, Timmerman, no mes-mo artigo, comenta as impossibilidades do emprego do Win-

dows NT como um SOTR. Neste caso empregam-se exten-sões do núcleo do sistema operacional que propiciam os serviços de tempo real. Isto vem sendo feito desde o tempo do DOS (Disk Operating System). Usualmente estas extensões são camadas agregadas ao sistema operacional. O autor bus-ca discutir e comparar soluções que a indústria oferece atu-almente para temperar com Tempo Real o NT. Recorda que a política da Microsoft é a de não aceitar modificações no nú-cleo do NT. A única parte modificável do Núcleo é o objeto de código chamado de Controlador de Dispositivos (que é aberto para permitir a integração de periféricos dos fabricantes). Este é o único caminho possível para se comunicar com o Núcleo. O Controlador de Dispositivos situa-se no HAL (Hardware Abs-traction Layer) que é a camada subjacente de software que faz interface do NT com o hardware. O código fonte do HAL é dis-tribuído sob uma autorização especial. Alguns desenvolvedo-res, com este acesso, implementaram soluções especiais de tempo real pela modificação do HAL ou combinações.

Extensões do núcleo são válidos também para os outros sistemas operacionais da Microsoft. Um exemplo deste tipo de solução é o RTX, extensão de Tempo Real para Windows (XP, 2000, 2003 Server) da empresa Ardence (http://www.ar-dence.com/), figura 5. O catálogo do produto Ardence RTX destaca: “Manter esta separação entre o Núcleo e o subsis-tema de tempo real do RTX assegura que aplicações basea-das no RTX sobrevivem às falhas e ‘telas azuis’ do Windows”.

Linguagens para Tempo Real

Dado um SOTR ou um núcleo de extensão de tempo real, torna-se necessário dispor de uma linguagem de programa-ção que contenha primitivas19 que utilizem os serviços de tem-po real oferecidos ou disponha de uma biblioteca de funções que encapsule as chamadas para as funcionalidades do SOTR. Além destas primitivas, existem vários outros requisitos para a linguagem de programação para tempo real, como para a ar-quitetura desses programas. Algumas linguagens contêm um pequeno núcleo de tempo real em suas bibliotecas de execu-ção, adequadas para soluções mais simples quando o sistema operacional alvo não é um SOTR. Muitas linguagens foram de-


16. VxWorks: é um sistema operacional de tempo real similar ao Unix produzido e vendido pela Wind River Systems de Alameda, Califórnia, EUA.17. Jbed: uma rápida e pequena máquina virtual Java para sistemas embutidos de tempo real lançado pela empresa suíça Esmertec AG., em 1999.18. pSOS: sistema operacional em tempo real criado em 1980 por Alfred Chao e a empresa Software Components Group. Atualmente é propriedade da Wind River Systems, que o está substituindo pelo VxWorks.19. Chama-se de primitiva de uma linguagem de programação as funcionalidades básicas sobre as quais a linguagem é construída.


senvolvidas nos últimos 40 anos para uso em aplicações com-putacionais para tempo real, como: ADA, Pearl, Modula, Posix, Java RT. No entanto, segundo alguns autores, como Halang e Stoyenko (1990) e Cooling (1996) mesmo nestas linguagens ainda persistem recursos por implementar.

Das linguagens mais empregadas na programação de si-mulações matemática destaca-se o MatLab/Simulink. Este pacote de geração de aplicativos da MathWork, em decorrên-cia da facilidade de uso, da programação gráfica amigável, e da filosofia do projeto baseado em modelo, esconde do usu-ário os recursos internos sobre os quais constrói a simulação ou o aplicativo para tempo real, bem como as suas limitações! Destaque-se que o material publicitário da empresa, por obje-tivos comerciais, faz um uso abusivo do termo “tempo real”, tendo agregado o termo à marca de alguns de seus produtos.

As informações a seguir foram retiradas da página da Ma-thWork (http://www.mathworks.com/products), sobre cujo material focamos nossa atenção no pacote Matlab/Simulink de arquitetura, construção e teste de aplicativo computacio-nal para tempo real executável em PC com Windows. Pelos motivos anteriores, a escolha recaiu sobre produtos volta-dos para o sistema operacional Windows, sendo que o ma-terial informativo dos produtos equivalentes para Linux pode ser encontrado na página: (http://www.mathworks.com/pro-ducts/availability/Linux_x86_64.html).

O Simulink, isoladamente, é um gerador gráfico de apli-cativos para simulação do tipo ‘não tempo real’, ou tempo virtual. Com o Simulink pode-se simular conjuntamente o comportamento dinâmico da planta, dos controladores e do ambiente. Pode-se acelerar a execução do modelo e pelos perfis do modelo identificar gargalos de desempenho. Para a construção de um sistema de tempo real se faz necessá-rio uma extensão do núcleo do Windows. A família de produ-tos Simulink provê um ambiente de prototipação “Estação de Desenvolvimento – Dispositivo Alvo”, que reúne: um núcleo de tempo real, o Real-Time Windows Target®; o gerador de código em C, o Real-Time Workshop®; o módulo objeto do controlador de dispositivos de E/S; e ferramentas para cria-ção rápida do protótipo para eletrônica embarcada20, ou do sistema de simulação acoplado ao dispositivo (hardware-in--the-loop - HIL). Quando se cria uma aplicação de tempo real a partir do modelo, tanto o algoritmo de controle, quanto os controles de dispositivos, e o núcleo de tempo real são auto-maticamente gerados, ligados e transferidos para o sistema alvo de tempo real (Mathworks, 2008). Através do Simulink é possível o controle da execução do código executável para tempo real gerado (veja comentário de Auslander, citado an-teriormente, sobre ambiente síncrono de depuração).

O núcleo de tempo real proprietário para Windows (2000 e XP), o Real-Time Windows Target, permite a execução de um modelo Simulink e Stateflow® em tempo real na Esta-

Figura 5 – Arquitetura de Extensão do Núcleo do Windows pela empresa Ardense.

Figure 5 – Architectural Extension of Windows Nucleus by the Ardense Company.

Figura 5 – Arquitectura de Extensión del Núcleo de Windows de la empresa Ardense.


20. A expressão “eletrônica embarcada” é empregada para sistemas microcomputadorizados dedicados, como os circuitos de controle em automóveis, em eletrodomés-ticos, na aviônica, nos controladores de processo.


ção de Trabalho ou num PC portátil propiciando a prototipa-ção rápida, ou a simulação acoplada ao protótipo (HIL), de algoritmo de sistema de controle ou de processamento de sinais. O núcleo do Real-Time Windows Target executa na camada zero (ring zero, modo privilegiado ou do núcleo do Windows) e usa o relógio interno do PC como sua fonte pri-mária de tempo. Disponibiliza os seguintes serviços: interrup-ção por temporização; escalonamento; comunicação com a eletrônica de entrada e saída; e modo externo do Simulink. O núcleo intercepta a interrupção do relógio interno do PC, mantendo os sinais do relógio esperados pelo sistema ope-racional do Windows e garante a execução em tempo real do aplicativo. Como resultado, ambos, o núcleo e o aplicativo para tempo real, são executados na camada zero.

O Real-Time Workshop permite a geração de código C e C++ no padrão American National Standards Institute (ANSI), para todo o modelo Simulink ou para subsistemas, de forma otimizada, portável e personalizável, habilitando a execução do código gerado em qualquer microcomputador (embarcado) ou sistema operacional de tempo real (SOTR). Produtos acessórios, disponíveis separadamente, estendem o Real-Time Workshop quanto à capacidade e suporte de ge-ração de código. O código executável da aplicação deve ser carregado e executado diretamente pelo núcleo de tempo real. Ele não pode ser executado sem o núcleo.

Um exemplo de extensão das capacidades do Matlab/Simulink para tempo real é encontrado no Truetime, desen-volvido pela universidade de Lund (Dinamarca). Este conjun-to de blocos (toolbox) foi desenvolvido com a intenção de in-corporar o efeito das redes de comunicação sobre sistemas de controladores distribuídos. Na forma tradicional de proje-to de controle usando Matlab/Simulink, os efeitos temporais decorrentes da implementação final dos controladores são negligenciados. Controladores são implementados de forma frequente como tarefas sob um núcleo de tempo real, co-municando-se via rede com outros nós. Em consequência, as restrições do sistema alvo (por exemplo: limite da velo-cidade da Unidade Central de Processamento – UCP e a lar-gura de banda da rede), deveriam ser levados em considera-ção durante o projeto. Com este propósito foi desenvolvido o toolbox Truetime para simulação de sistema de controle dis-

tribuído em tempo real. Este toolbox tornou possível a simu-lação do comportamento temporal do núcleo de tempo real executando uma tarefa de controle e também a simulação de modelos simples de protocolos de rede e as influências dos “laços de controle sobre a rede”. Consiste de um conjun-to de blocos do Simulink, sendo: um bloco de núcleo de tem-po real, outro de rede, ambos escritos em C++ como varia-ble-step S-functions, além de outros blocos e recursos. Os blocos Truetime são conectados como qualquer bloco no Si-mulink para confeccionar um sistema de tempo real (Henri-ksson, et al., 2003).

A questão da integração de sistemas em tempo real é discutida num artigo muito interessante sobre a monitora-ção do estado (normal ou em falha) baseada em modelo do processo de um sistema de controle (Shi et al., 2007). O autor analisa algumas das questões levantadas ao lon-go deste texto, propondo como exemplo uma arquitetura composta por dois microcomputadores integrados por uma rede Fieldbus: um microcomputador dedicado ao contro-le e outro à execução do modelo e monitoração do estado. Analisa ainda algumas questões de sincronização entre as tarefas e os “pacotes” de dados, onde o tempo é um dado incorporado. A plataforma Matlab é usada para a constru-ção do modelo e do diagnóstico de falha. Além disto, a ar-quitetura do sistema contempla um programa supervisório (Labwindows) e um de aquisição de dados. Esta arquitetura exige, no entanto, o estudo das restrições temporais e de escalonamento das tarefas, com a construção de uma es-tratégia, que é apresentada no artigo, para o caso exemplo. O autor também comenta que o ActiveX foi a primeira ten-tativa, pois compunha o pacote do sistema supervisório. In-felizmente, o sistema travava de tempos em tempos quan-do usado para partilhar dados com o Matlab. Depois de desistir de resolver dúvidas sobre o suporte da MathWorks ao ActiveX optou-se pela utilização do suporte do Matlab ao DDE (Dynamic Data Exchange). Em suas considerações finais propõe a substituição da comunicação DDE pelo uso de canais nomeados21 ou OPC, de forma a permitir o em-prego de computação em grade (divisão das tarefas entre várias máquinas). O uso do OPC22 confirma nossa própria experiência na implementação da comunicação entre pro-gramas de simulação e controle em rede.


21. Canais nomeados ou named pipes, é um método de intercomunicação entre processos.22. OPC significa “OLE (Object linking and embebed) for Process Control” sendo um protocolo padrão de comunicação de dados processo entre dispositivos de diferentes fabricantes.


Limitações na simulação em tempo real

Em artigo sobre a grade curricular e a elaboração de cur-sos de engenharia de controle de processos Kheir (Kheir et al., 1995) comenta estas questões de forma bastante práti-ca: diz que um laboratório acadêmico de treinamento deve ilustrar diferentes tecnologias utilizadas nos sistemas de controle, ressaltando quais componentes e interfaces são importantes. Deve também indicar questões de tempo real concernentes aos circuitos supervisórios e aos problemas do homem no controle de sistemas, incluindo as questões de in-terface homem-máquina e as do ‘homem acoplado ao circui-to’ (humans in-the-loop). Deste modo, o autor cita o questio-namento que frequentemente é feito nestes ambientes: “se equipamentos de laboratórios são caros para comprar e cus-tosos de manter, porque não substituí-los simplesmente pela simulação?” Sua resposta é que “a simulação é muito útil, porém não pode substituir equipamentos reais. Em suas pa-lavras, “é importante para o aluno ser exposto aos caprichos e perversidades do mundo real”. Feita estas considerações, o autor ainda comenta que um simulador com facilidades de tempo real tem várias vantagens, dentre elas, a de permitir iniciar o curso apresentando em aula a simulação de um pro-cesso e do seu controle. Assim que uma simulação satisfa-tória é alcançada em sala de aula, o processo simulado pode ser substituído pelo processo real, simplesmente pela tro-ca de algumas conexões. Destaca que nem sempre o ‘sim-ples’ significa fácil. Um simulador que admite esta operação é o Simnon23. Ele tem uma característica adicional em ter-mos da geração de código, pois permite a geração de có-digo de tempo real em Módula 224, com chamadas para um ‘núcleo de tempo real’. Após este exemplo, o autor prosse-gue comentando sobre simulação e treinamento. No final do artigo destaca algumas insuficiências na adoção de progra-mas de Engenharia de Controle Assistidos por Computador (CACE), tais como:

• a potencial ignorância sobre a máquina de computação numérica subjacente que dá poder ao programa;

• a deficiência em perceber as limitações do sistema em relação ao processo físico sendo modelado e simulado;

• a carência de experiência prática, de ‘por as mãos’ no trato com a física dos sistemas de controle.

O autor comenta como, de forma sutil, a prática da si-mulação (sem a prática experimental) provoca estas insu-ficiências. Observa que a habilidade de simular um sistema de controle com sucesso propicia ao projetista confiança em seu projeto e baseia sua inspiração e discernimento sobre os meandros do problema. Esta confiança, inspiração e discer-nimento, no entanto, são limitadas pela fidelidade do modelo do sistema, comprometida talvez pela estimação paramétri-ca ou pela omissão de alguma não linearidade significativa. A principal razão desta insuficiência é que o currículo da enge-nharia de controle tende a simplificar as representações de sistemas usando tipos de comportamentos genéricos no lu-gar de tipos de componentes físicos. Um projetista de con-trole usualmente visualiza um motor de corrente contínua - DC como um dispositivo de terceira ordem com entrada de voltagem e saída de posição, ignorando vários detalhes do seu circuito interno e mecanismos. Curiosamente, em con-versa com um engenheiro projetista sobre este tema, ele cri-ticou esta aparente culpa atribuída à modelagem de siste-mas, afirmando que “o problema é do nível de detalhamento dos requisitos tanto do modelo quanto do subsistema hospe-deiro, de forma a garantir que este último seja tolerante a fa-lhas”. Efetivamente, a formação acadêmica calcada apenas em testes em ambientes simulados tem por efeito colateral uma prepotência decorrente da crença da superioridade da técnica sobre os fenômenos da natureza, como na argumen-tação deste engenheiro. No entanto, os acidentes com siste-mas de controle projetados por equipes dotadas de recursos e das últimas tecnologias de projeto e de teste pré-operacio-nal, são a prova mais cabal da limitação humana. Os exem-plos são abundantes nos noticiários e jornais, destacando- se, tristemente, os aeronáuticos.

Polissemia do tempo real

A comparação entre os autores citados, confirmando nossa própria experiência em automação, evidencia que o termo “tempo real” deve ser empregado com cautela. Con-trariando a expectativa de quem redige um artigo técnico, o termo não mais exprime um conceito bem estabelecido, face à rápida ampliação do significado com a evolução tec-nológica. Mesmo entre técnicos, dentro de uma restrita área tecnológica, existe o risco da interpretação ser contamina-


23. Simnon: simulador de processos, marca registrada do Inst. Tecnológico de Lund, Suécia.24. Módula 2: linguagem de programação desenvolvida por Niklaus Wirth (pai da linguagem Pascal) para atender os objetivos de modularidade.


da por outros significados. Acrescente-se a observação de que, cada vez mais, os jovens que ingressam nas áreas de simulação e controle de processo trazem um jargão bem se-dimentado de jogos de computadores, onde o termo “tempo real” sofreu sua maior ressignificação. Em áreas de conheci-mento mais abrangentes, como em engenharia de sistemas de controle, ou em situações multidisciplinares, a imprecisão pode tomar forma sutil, sendo causa de entendimentos equi-vocados. A popularização da informática no seio da socieda-de difundiu o termo tempo real ao mesmo tempo em que es-tabeleceu a polissemia. Alguns recortes tirados de páginas da internet e que exemplificam este fenômeno estão repro-duzidos abaixo.

Na Página da Microsoft Brasil sobre o WinCE encontra-mos o confuso texto abaixo, transcrito tal e qual, onde o ter-mo “tempo real” possui mais de um significado:

“Você já ouviu os termos ‘rápido’, ‘latência limitada’ e tempo real ‘rígido’ versus ‘flexível’. Quando você envia o seu dispositivo, o tempo real trata simplesmente de obter os re-sultados corretos dentro de uma faixa de tempo limitada, in-dependentemente do uso de CPU do seu projeto. Veja como o Windows CE, NET e o Windows XP Embedded usam as ca-racterísticas de interrupções, cronômetro, agentes e priori-dades de execução para oferecer soluções de alto desempe-nho, em tempo real”.

No Blog de Jim Laurent (2007) consultor da Sun Mi-crosystems, Inc, pode-se ler:

“a minha definição de computação em tempo real é: pe-gar a resposta certa e no prazo (get the right answer in the required time). Uma resposta certa fornecida depois que o prazo limite expirou é uma resposta incorreta. Aplicações de Computação em Tempo Real incluem, em ordem de comple-xidade, simuladores de voo, telemetria, armas guiadas, con-trole de naves espaciais, etc. Por exemplo, um simulador de voo típico roda com refresco de tela em 60Hz (60Hz frame). A coleção completa de dados (aerodinâmicos, estados dos motores, controles, visualizações, etc.) precisam ser recal-culados e apresentados de forma acurada para o piloto den-tro de cada tela. Uma falha em fazê-lo não apenas arruína

a simulação como pode facilmente deixar o piloto indispos-to, pois seus sentidos não recebem dados consistentes com sua ação”.

Inicialmente o texto se refere ao termo tempo real como sendo requisitos de tempo do fenômeno e, no entanto, exem-plifica uma condição de interface, de requisitos de iteração com o usuário. Por outro lado, o autor reconhece que existe um tempo fisiológico e psicológico na iteração. No exemplo, o usuário pode ficar indisposto, em outros sistemas o usuário pode ficar aborrecido com o retardo da resposta. Como clas-sificar um sistema dito de tempo real no qual as limitações de tempo são subjetivas e variam com a fisiologia, cultura ou a expectativa do usuário?

Sistemas de Gerenciamento de Banco de Dados (SGBD) e seus aplicativos se referem ao acesso as infor-mações em tempo real, com o significado de instantâneo, imediato, ou seja, o cliente da solicitação não deve ficar esperando por ela. O termo tempo real é utilizado também como expressão da capacidade do SGBD de reagir e pro-cessar eventos, com o significado de reativo e instantâ-neo. De modo equivalente à notação de jogos, o termo é empregado para descrever a interatividade com o usuário ou com outro sistema. No entanto, existe uma categoria específica dos bancos de dados para tempo real (SGBD--TR) cujas mais importantes características foram resumi-das de uma aula virtual (Universidade Católica de Pernam-buco - Unicap, 2008). Um SGBD-TR pode ser visto como a integração de um SGBD convencional com um STR. As-sim, um SGBD-TR além de processar transações e garantir a integridade dos dados, deve também operar em tempo real, para satisfazer as restrições temporais impostas aos dados e transações. Em algumas situações, estas restri-ções só podem ser satisfeitas se a consistência lógica dos dados for sacrificada. Em outras, para manter a consistên-cia lógica dos dados, a consistência temporal deve ser sa-crificada. Uma vez que estas situações são bastante fre-quentes em SGBD-TR, os resultados produzidos por uma transação não precisam ser totalmente corretos, ou seja, podem ser imprecisos. Portanto, as propriedades ACID25 (propriedade da transação em um banco de dados) não precisam ser cumpridas totalmente, e foram redefinidas


25. ACID: propriedade da transação em um banco de dados: atômica, consistente, isolada e durável;



nalistas, fotógrafos e cinegrafistas), e o material, que in-clui também resumos das palestras, pode ser conferido no endereço do fórum”. Em telecomunicações, inclusive em teleconferência, não é incomum o termo tempo real ser utilizado como sinônimo de “transmissão ao vivo”. No entanto, o exemplo de transmissão ao vivo e em tempo real é o de situação de telepresença.

O termo Tempo Real também invade o universo corpo-rativo, com o termo Empresa em Tempo Real (Real Time Enterprise), cunhado pelo Gartner Group. Significa a em-presa que reduz o tempo gasto com gerenciamento e execução dos processos de visualização de informações, não somente aprimorando ferramentas, mas distribuindo o acesso e oferecendo poder de decisão aos profissio-nais dos mais diferentes níveis hierárquicos da institui-ção. “Uma empresa em tempo real pode monitorar seus negócios a qualquer momento – e isso não significa ape-nas ter controle dentro de seus limites. Os processos a ser gerenciados extrapolam para dentro de parceiros e fornecedores” (Valim, 2008). Nesta categoria se inserem os sistemas ERP (Enterprise Resource Planning) ou SIGE (Sistemas Integrados de Gestão Empresarial), no Brasil.

Com beleza quase poética e de grande significado cognitivo temos o seguinte comentário provindo do uni-verso da música de laboratório (Vaz, 1999). “O surgimento do estranho termo tempo real ilustra a transformação da experiência promovida pelas novas tecnologias de comu-nicação. O desenvolvimento das técnicas de registro do som permitiu que as gravações da voz e dos instrumentos que compõem uma música pudessem ser feitas separa-damente, em diferentes momentos. Desde então, tornou--se necessário acrescentar o adjetivo ‘real’ ao conceito de ‘tempo’ para designar o tempo fenomenológico do aqui e agora - trata-se de uma gravação onde todos estão simul-taneamente reunidos. A marca do ‘ao mesmo tempo em que’ foi posteriormente trabalhada até passar a designar o tempo onde alguma ação é possível. O que nos interes-sa aqui é como a mediação tecnológica, concretamente, vai ‘acrescentando’ novos ritmos além do ‘imediato’ histo-ricamente anterior; na realidade, não se trata de uma adi-ção, mas do surgimento de um novo imediato. Nossa ex-periência de tempo foi sendo composta por outros ritmos e, neste sentido, modificada”.

para SGBD-TR. Por exemplo, em um sistema de contro-le de tráfego aéreo, a posição aproximada de um avião no tempo certo pode ser mais apropriada que o valor exa-to tarde demais. Geralmente a imprecisão permitida deve ser limitada. No exemplo anterior, a imprecisão na posi-ção do avião deve ser de apenas alguns metros, conside-rada a posição verdadeira. Idealmente, os dados grava-dos em um SGBD-TR devem ser idênticos em valor ao seu correspondente no ambiente. No entanto, geralmente há um atraso de atualização no SBD-TR, o que pode levar a inconsistências entre estes valores. Portanto, é necessá-rio um mecanismo para verificar a consistência tempo-ral do dado.

Com o sentido de informação disponível de forma imedia-ta e em linha o termo é intensamente empregado em pági-nas da internet como na figura 6, de onde é possível “moni-torar os ativos em tempo real”.

O termo Tempo Real nos meios de comunicação usu-almente significa transmissão simultânea ou concomitan-te dos fatos ou evento, conforme exemplifica o texto (III Fórum de Marketing, 2007). “Encerrou-se nesta quinta--feira, dia 16 de agosto, o III Fórum de Marketing de Curi-tiba, promovido pelo Grupo Positivo no UnicenP - Centro Universitário Positivo. A terceira edição do evento bateu o recorde, com 865 participantes. Neste ano, o Fórum con-tou com um blog, onde foi realizada a cobertura em tempo real dos dois dias de evento, com textos, fotos e vídeos de entrevistas exclusivas com os palestrantes. O traba-lho envolveu uma equipe de 15 profissionais (entre jor-

Figura 6 – Acesso a informação em “tempo real”.

Figure 6 – Information Access in “real time”.

Figura 6 – Acceso a la información en “tiempo real”.



Momento Histórico Significado de Tempo Real:

Ao longo de quase toda a história da humanidade:

A experiência do tempo cronológico tendo por alternativa o tempo irreal, imaginário ou transcendental;

Com o Advento da Computação Analógica:

Tipo de tempo numa simulação; corresponde ao tempo simulado quando este equaliza com o tempo do fenômeno.

Com o predomínio do computador digital:

Tempo discretizado, marcado por eventos, viabilizando sua manipulação como um objeto.Requisitos que o sistema tem que atender e recursos que tem que dispor, e não exatamente um tempo.Usado para definir um sistema de “resposta rápida”, em relação a dinâmica do fenômeno (con-fundido com velocidade do processador).Resposta no “instante adequado”. Considerando a iteração com o ser humano, cognitivo, emo-cional, o instante adequado pode não ser um tempo cronológico mas um tempo cairológico. Uma classe de sistema computacional (o STR) cuja corretude depende não apenas da saída, mas também do instante no qual esta saída é produzida.Recurso da parte básica do sistema computacional ou uma classe de sistema operacional (o SOTR).Uma linguagem de programação com primitivas que permitam descrever os requisitos de tem-po do sistema, é também o conjunto de ferramentas para a análise e projeto do sistema de tempo real.Ambientes, ferramentas de integração de sistemas e os sistemas produtos assim constituídos. Uma classe de Sistemas de Gerenciamento de Banco de Dados (o SGBD-TR), onde o resultado pode ser impreciso desde que atenda as restrições de tempo!

Com a popularização do uso da informática:

Sistemas e artefatos que respondem de forma imediata ou instantânea às solicitações;Sistemas e artefatos iterativos com o usuário ou com outros sistemas;Sistemas e artefatos com capacidade de reagir e processar eventos, com o significado de reativo;

Com a popularização dos jogos de computador, dos ambientes virtuais e da convergência telemática:

Um jogo de computador onde os contendores precisam estar presentes no mesmo instante in-teragindo com o sistema servidor do jogo.Transmissão simultânea ou concomitante de fatos ou eventos, é um significado que se genera-liza em telecomunicações.“Transmissão ao vivo”, também em telecomunicações e teleconferência.Telepresença, quando a transmissão ao vivo subsidia o comando ou operação de algum dispo-sitivo remoto.Uma classe de empresa ou de operações empresariais nas quais os funcionários envolvidos dispõem de acesso adequado e em tempo das informações que precisa para realizar suas ati-vidades.Um momento especial, o momento da convergência dos dados, dos recursos e das pessoas.

Tabela 1 – Resumo: A polissemia decorre do acúmulo de significâncias.

Table 1 – Summary: The polysemy arises from an accumulation of significances.

Tabla 1 – Resumen: La polisemia surge de una acumulación de significados.


Um Tempo não tão Real no Mundo Real

No mundo real, a polissemia aumenta a entropia. Conside-rando um possível ciclo de vida de um sistema de tempo real atuando no controle de um processo industrial, como concebi-do atualmente, temos que considerar desde a concepção dos subsistemas até a operação de toda a planta industrial, com suas atualizações, modificações e ampliações. Participam des-te ciclo diferentes atores, em diferentes momentos, como por exemplo: um jovem estagiário com a compreensão de tempo real oriunda dos jogos de estratégia; um engenheiro de teleco-municações com os conceitos de tempo real como contrato; um engenheiro químico especialista em cinética, com o enten-dimento de tempo real como o tempo simulado; o profissional de Recursos Humanos (RH) com conceito de tempo real ad-vindo da iteratividade em ensino a distância; um administrador com a visão de tempo real como sendo a da Gestão Integrada da Empresa (SIGE), etc. Esta polissemia representa um risco potencial para o tempo real dos sistemas.

Outra fonte de risco de tempo real decorre do esquecimen-to ou ignorância das limitações do projeto e dos testes em re-lação ao fenômeno. Na mentalidade de muitos engenheiros: “garantida as condições de projeto (contrato) o sistema ga-rante o funcionamento em tempo real”. Este tipo de afirmação significa que tudo que foi ignorado ou simplificado ao longo do projeto foi esquecido. Quando se trata de sistemas complexos, a tal “garantia das condições de projeto” não pode ser garan-tida ao longo da operação no mundo real. A natureza não se conforma às condições de projeto e, na “primeira oportunida-de” (que pode aguardar anos), violenta estas condições. Além disto, sistemas costumam ser construídos a partir da integra-ção de partes, onde “o resultado pode ser maior que a simples soma das partes” e onde nem todas novas propriedades são percebidas até que apareçam. Este sinergismo introduz novos riscos na medida em que a complexidade final do sistema de controle moderno pode vir a ser bem maior que a do fenômeno que busca controlar, sendo por si só um novo fenômeno. Um novo fenômeno subjacente ao modelo de controle.

Outra questão relevante é a de que, no mundo real: as in-tempéries, o envelhecimento, a evolução, as modificações, as atualizações (up-grade), as manutenções, etc., criam situa-

ções onde os requisitos de tempo real podem não ser aten-didos momentaneamente, criando situações onde falhas se-jam interpretadas como perda de desempenho e outras, onde perdas de desempenho sejam interpretadas como falha. Em relação às atualizações de equipamentos existe uma máxima na informática que diz que, não importa quão poderoso seja o computador, todos os seus recursos serão consumidos na pró-xima evolução do sistema.

Quando se observa o moderno sistema de controle inte-grado e as tendências da evolução da tecnologia, com uma vi-são sistêmica, temos que: todo novo produto de lógica embar-cada não permanecerá sozinho; de alguma forma será inserido numa rede fiada ou desfiada (sem fio)! Porém, na prática atu-al dos projetos de engenharia de controle de processos, os instrumentos e dispositivos que compõem os subsistemas, ainda são especificados como entidades temporalmente in-dependentes, como se a conexão por rede fosse apenas cir-cunstancial, ou seja, não originasse novos compromissos (decorrentes da complexidade crescente). Em processos in-dustriais, o uso de instrumentos e redes intrinsecamente se-guras esconde o fato de que falhas, degradação e acidentes podem provocar conflitos temporais inesperados. As arquite-turas em hierarquias computacionais (de sub-redes e de con-teúdo de informação) são planejadas como se fossem conti-das em seus níveis. Enquanto a falsa suposição de isolamento entre os componentes físicos pode interferir sobre o compor-tamento de tempo real do sistema, no lado humano é o iso-lamento das equipes que compromete o desempenho futuro. Dado o porte e sofisticação que os empreendimentos de au-tomação industrial estão alcançando, o projeto de um novo empreendimento ou o de atualização da instalação, é desen-volvido em fases, por equipes independentes, localizadas em diferentes empresas e países, dificultando a análise sistêmica da questão do tempo real. Essas equipes não se conhecem e partilham informações por meio de especificações, manuais e outros documentos. Em conseqüência, parte do conhecimen-to dos projetos de automação é adquirida residindo dentro de equipamentos, de programas, de subsistemas e de estruturas de comunicação, permanecendo um conhecimento tácito, si-giloso, oculto, com acesso restrito apenas ao que está publi-cado na documentação.

Uma vez comissionado o empreendimento, o tempo crono-lógico assenhoreia-se dos seus desdobramentos. Eventos tem-



porais assíncronos (esporádicos) se comportam como num jogo de azar, onde condições fortuitas podem ser impossíveis de repetir ou replicar. Considerando todos os eventos tempo-rais presentes em uma operação complexa e a impossibilidade de rastrear a todos com a granularidade temporal necessária, os comportamentos erráticos e os desvios inesperados terminam por ser imputados a outras causas. Por exemplo, como atribuir a falha do acionamento de uma válvula ao atraso no pacote de da-dos de controle transportado por um serviço de rede, que não foi devidamente contratado, e sofreu colisão com um pacote gera-do por uma mensagem de correio eletrônico, principalmente se esta falha não volta a se manifestar? Ou então, como atribuir o atraso na operação de uma válvula ao excesso de carga de co-municação numa rede cuja terminação apresenta mau conta-to em decorrência de um acidente durante uma soldagem e a vibração da partida de uma bomba, e cuja intermitência não é identificada pelo controlador da rede?

ConclusãoUsualmente, num projeto, a principal preocupação e cuidado

que existe com relação ao tempo é quanto ao tempo do crono-grama do empreendimento. A influência das questões de tem-po suscitados neste texto sobre um projeto e na operação de sistemas complexos, carece de ser reconsiderada e reavaliada.

Mesmo reconhecendo que o tempo cronológico ainda não poder ser manipulado nas aplicações de gestão e controle dos processos químicos, a modernidade vem redefinindo ou es-tabelecendo novos conceitos de tempo neste espaço-tempo da virtualidade construído eletronicamente. Como será definir tempo real dentro de uma caverna de realidade virtual? Será que é possível surgir o emprego do termo tempo real envelhe-cido ou desatualizado, numa instalação de processo industrial que integre diferentes versões e gerações de equipamentos e subsistemas? Novos significados ainda estão em porvir.

Com a disseminação dos recursos e dispositivos eletrôni-cos informatizados por todas as camadas sociais e ambien-tes da vida humana, o termo tempo real está sendo, de cer-ta forma, resignificado pela sociedade. A academia, como um todo, ainda não se deu conta desta mudança e os segmen-tos tecnológicos compartimentalizados permanecem presos ao passado, sendo prova disto o fato da literatura técnica pou-

co comentar esta transformação. Algumas personalidades ins-piradas, principalmente no campo da educação e da filosofia, têm manifestado esta percepção, que não se propaga, limita-da pela compartimentalização dos saberes. Pode-se argumen-tar que cada área de conhecimento deva ter sua terminologia, no entanto, em relação ao tempo real, a polissemia pode por em risco informações e processos industriais do mundo real.

Do reconhecimento destas transformações tecnológicas e dos seus impactos na cultura da sociedade atual, decorrem as seguintes propostas de uso do termo tempo real:

• o termo Tempo Real deve ser entendido como um con-ceito que expressa o comportamento temporal de um sistema (ou subsistema) ao atender aos seus requisi-tos temporais de especificação (contrato), sendo mais uma qualidade de um sistema do que propriamente um tempo, ou seja, não é uma propriedade mensurável;

• o termo Tempo Real deve ser sempre qualificado como crítico (seguro ou operacional), firme ou flexível;

• o termo Tempo Fenomênico deve passar a ser empre-gado para explicitar o comportamento temporal decor-rente da dinâmica do fenômeno com o qual o sistema interage. O tempo fenomênico é a fonte de todas as in-formações temporais conhecidas (requisitos capturados durante a fase conceitual) e ainda por conhecer (proble-mas e eventos identificados ao longo da operação), po-dendo ser expresso como uma propriedade mensurável;

• os requisitos temporais de todas as partes, dispositivos e subsistemas, de um sistema de tempo real, devem ser explicitados e conhecidos durante o projeto (por to-das as equipes) e principalmente disponibilizados du-rante a operação; sendo uma representação potencial a do “modelo orientado a contrato”;

• devem ser utilizados métodos e ferramentas para avaliar o desempenho de tempo real dos sistemas, tanto para o seu comissionamento como para avaliação durante a ope-ração (principalmente após modificações na arquitetura);

• os requisitos temporais devem ser avaliados levando em consideração a iteração humana, nos vários níveis da hierarquia do sistema e as modernas considerações de ergonomia cognitiva;

• os requisitos temporais devem descrever a percepção humana do tempo, na situação de operação, bem como os tempos de resposta humana envolvidos, de tal forma



n BACCARIN, F. Educação à Distância! Qual a Distância? In: CONGRES-SO INTERNACIONAL DE EDUCAÇÃO A DISTÂNCIA, 11., 2004, Salvador. Anais... Salvador: ABED, 2004.

n BASKIYAR, S.; MEGHANATHAN, N. A survey of contemporary real-time operating systems. Informatica, Slovenia, v. 29, n. 2, p. 233-240, 2005.

n BEAUMONT, P. Multi-platform coordination and resource manage-ment in command and control. 2004. 155 p. Dissertação (Mestrado) – Universidade de Laval, Québec, Canadá, 2004.

n CERQUEIRA, R. C. Uma proposta para descrição e implementação de contratos para serviços com qualidade diferenciada. 2002. 137 p. Disser-tação (Mestrado) – Universidade Federal Fluminense, Rio de Janeiro, 2002.

n COOLING, J. E. Languages for the programming of real-time embed-ded systems: a survey and comparison. Microprocessors and Microsys-tems: Embedded Hardware Design (MICPRO), Amsterdam, v. 20, n. 2, p. 67-77, Apr. 1996.

n DELLAZARI, M., A. Avaliando características de sistemas opera-cionais de tempo real. 2004. Graduação (Bacharel) – Curso de Ciên-cia da Computação, Universidade Estadual do Oeste do Paraná, Cas-cavel, PR, 2004.

n FARINES, J. M.; FRAGA, J. S.; OLIVEIRA, R. S. Sistemas de tempo real. São Paulo: Editora Escola de Computação, 2000.

n HALANG, W., A.; STOYENKO, A. D. Comparative evaluation of high-level real-time programming languages. Journal Real-Time Systems, Nether-lands, v. 2, n. 4, p. 365-382, Nov. 1990.

n HAWKING, S. W. Uma breve história do tempo: do big bang aos bura-cos negros. 30. ed., Rio de Janeiro: Rocco, 2000. Tradução do original de Maria Helena Torres, publicado em 1988.

Referências Bibliográficas

n HAWKING, S. W.; MLONDINOW, L. Uma nova história do tempo. Rio de Janeiro: Ediouro, 2005. 174 p.

n KHEIR, N. A.; ASTROM, K. J.; AUSLANDER, D.; CHECK, K. C.; FRANKLIN, G. F.; MASTEN, M.; RABINS, M. Control systems engineering education. Automatica, Amsterdam, v. 32, n. 2, p. 147-166, Feb. 1996.

n LEE, K.; FISHWICK, P. A. Building a model for real-time simulation. Future Generation Computer Systems, Amsterdam, v. 17, n. 5, p. 585-600, Mar. 2001.

n NAVARRO, C. PET-IV: ambiente didático interativo de visualização de sistemas concorrentes operando em tempo real. 2006. 115 f. Dissertação (Mestrado) – Universidade Tecnologica Federal do Paraná, Curitiba, 2006.

n PETTERSSON, P. Modelling and verification of real-time systems using timed automata: theory and practice. 1999. 206 p. Tese (Doutorado) – Department of Computer Systems, Uppsala University, Uppsala,1999.

n STANKOVIC, J. A. Misconceptions about real-time computing: a serious problem for next-generation systems. Computer, Washington, v. 21, n. 10, p. 10-19, Oct. 1988.

n TIMMERMAN, M.; MONFRET, J. C. Windows NT as Real-Time OS? Re-al-Time Magazine, Belgium, v. 97, n. 2, p. 6-13, 1997.

n TIMMERMAN, M.; MONFRET, J. C. Windows NT Real-Time Extensions: an over view. Real-Time Magazine, Belgium, v. 97-2, p. 14-24, 1997.

n SHI, J. Z.; GU, F.; GOULDING, P.; BALL, A. Integration of multiple platfor-ms for real-time remote model-based condition monitoring. Computers in Industry, Amsterdam, v. 58, n. 6, p. 531-538, Aug. 2007.

n WHITROW, G. J. O que é tempo?: uma visão clássica sobre a natureza do tempo. Rio de Janeiro: Jorge Zahar, 2005. 208 p. Publicação original em inglês, em 1972. Tradução da edição publicada em 2003.


que seja conceituado um super-sistema que incorpore o elemento humano. Ou, de outra forma, que todo sistema incorpore um subsistema “homo-sapiens”.

O conceito de tempo real é usualmente bem tratado nos artigos, na fase de projeto, nas simulações e nos estudos la-boratoriais. No entanto, ao longo da operação e uso tende a se tornar um ilustre desconhecido. Existe uma brincadeira de crianças, onde elas se deslocam sob a orientação de uma lí-

der, perguntando: “mamãe posso ir, quantos passos?”. Nes-ta brincadeira as crianças tendem a trapacear o tamanho dos passos, em relação ao acordado (contrato), intuitivamente. Na convergência entre o comportamento de sistemas complexos e o comportamento humano, a parte de tempo real correspon-de àquela que pode nos surpreender com um comportamen-to assemelhado ao do trapacear com as regras do sistema!

n n n




Webgrafia

n ALMEIDA, L. Notas de aula. Portugal: DETUA, 2004. Disponível em: < http://sweet.ua.pt/~lda/str/slides-aula1.pdf>. Acesso em: dez. 2007.

n AUSLANDER, D. M. Mechatronics: a design and implementation methodology for Real Time Control software. University of Califor-nia at Berkeley (CA): 1997. Disponível em: <http://www.me.berkeley.edu/~dma/controls/mechsoft.pdf>.

n FÓRUM DE MARKETING DE CURITIBA, 3., 2007, Curitiba. Anais... Curitiba: UnicenP, 2007. Disponível em: <http://clickmarket.com.br/ portal/index.php?cat=1&pchave=4074&contchave=4074>. Acesso em: 12 dez. 2008.

n HENRIKSSON D.; CERVIN, A.; OHLIN, M.; ÅRZÉN, K., E. TrueTime: Real-time Control System Simulation with MATLAB and Simulink. In: NORDIC MATLAB CONFERENCE, Copenhagen, 2003. Proceedings… Copenhagen: Lund University, Department Automatic Control - Denmark, 2003. Disponível em: <http://www.control.lth.se/database/publications/article.pike?artkey=hen%2b03>.

n LAURENT, J. Jim Laurent’s weblog: what is real-time computing and how do Solaris and Java support it? Washington D.C., 2007. Disponível em: <http://blogs.sun.com/jimlaurent/entry/what_is_real_time_compu-ting>. Acesso em: 13 dez. 2007.

Bibliografia

n FOLLY, R., O., M.; SANTOS, M., C. Monitoração e controle de unidades de destilação em batelada: relatório final do projeto CTPETRO nº 600928. Rio de Janeiro: UFRJ/EQ, 2006.

n GUIMARÃES, L. B. M. Ergonomia cognitiva. 3. ed. Porto Alegre: FEENG, 2006.

n MATHWORKS. Control design application brochure: technical lite-rature. U.S.: MATLAB/Simulink, 2008. Disponível em:<http://www.ma-thworks.com/applications/controldesign/technicalliterature.html>. Aces-so em: jan. 2008.

n UNIVERSIDADE CATÓLICA DE PERNAMBUCO. Notas de aula. UNI-CAP, 2008. Disponível em: <http://www.dei.unicap.br/~almir/semina-rios/2005.2/ns06/bdtr/BDTR_arquivos/page0005.htm>. Acesso em: 05 mar. 2008.

n VALIM, C. E. O mundo em tempo real. Curitiba: Intecma, 2008. Dis-ponível em: <http://www.intecma.com.br/portal/news/ReadNews.aspx?w010_id=703>. Acesso em: 16 jun. 2008.

n VAZ, P. R. G. Corpo e Risco. Forum Media, Viseu, v.1, n.1, p.101-111, Rio de Janeiro: ECO/UFRJ, 1999. Disponível em: <http://www.angelfire.com/mb/oencantador/paulovaz/P2A.html>. Acesso em: dez. 2007.

n MICROSOFT CORPORATION. Tempo real com Windows Embedded. Disponível em: < http://www.microsoft.com/brasil/embedded/techinsi-ghts/realtime.mspx.>. Acesso em:12 mar. 2008.

Autor

Mauricio Carvalho dos Santos ingressou na Petrobras, em 1977, como Químico de Petróleo, para trabalhar na implanta-ção do primeiro minicomputador de aquisição de dados das Plantas Piloto. É formado em Engenharia Química pela Uni-versidade Federal do Rio de Janeiro (UFRJ) e Mestre pelo Instituto Alberto Luiz Coimbra de Pós-graduação e Pesqui-sa de Engenharia (COPPE/UFRJ), com o Tema “Síntese Heu-rística de Sistemas de Reatores”. Ao longo da década de 1980 foi assessor da Secretaria Especial de Informática para a nacionalização de instrumentos de análise química, den-tro de acordo de contribuição da Petrobras àquela política. Trabalhou com automação de laboratórios e simulação até o fim da era da reserva de mercado. Desenvolveu trabalhos de


Centro de Pesquisas da Petrobras (Cenpes).Gerência de Tecnologia de Processa-mento Primário e Avaliação de Petróleo.e-mail: [email protected]

modelagem em biofenômenos e conduziu o projeto de atu-alização e ampliação do Sistema de Controle de Amostras - SCAD (gestão de laboratório). Conduziu projeto de naciona-lização de unidade laboratorial de destilação de petróleo em batelada, depositando três patentes. Conduziu o primeiro Fó-rum Transverso da Petrobras, como exercício de inovação in-terdisciplinar, tendo para isto iniciado estudos em cognição, que tem aplicado na pesquisa e na operação de unidades pi-loto. Atualmente trabalha em projeto de produção submarina descontínua, tendo depositado duas patentes e conduz pro-jeto CTPetro com O IQ/UFRJ e o IM/UFRJ projeto Quamostra cujo tema é o controle da qualidade na cadeia amostragem- ensaio de petróleos nacionais.



Um tempo não tão real: um ensaio sobre a evolução do ... · Un tiempo no tan real: un ensayo...

Documents

Transcript of Um tempo não tão real: um ensaio sobre a evolução do ... · Un tiempo no tan real: un ensayo...