Você está na página 1de 29

Automação II Relton Alves da Silva

NOVAS FRONTEIRAS DA AUTOMAÇÃO

RESUMO

O sentido da palavra automação passa por uma revolução. A primeira causa é uma
especialização causada pela melhor compreensão dos diversos tipos de processo. Automação de
processos contínuos, em batelada e de manufatura requerem normas e produtos diferentes, que
melhor atendam a identidade de cada setor. A segunda causa se deu quanto ao escopo. A
automação rompeu os grilhões do chão de fábrica e buscou fronteiras mais amplas, se
preocupando com a automação do negócio ao invés da simples automação dos processos e
equipamentos. Nascem aí os sistemas de gerenciamento da produção ou EPS- Enterprise
Production Systems, termo mais amplo que o conceito original de MES. E da produção passamos
a gerenciar os materiais através de Warehouse Management Systems, as vendas através dos
sistemas de automação de força de vendas e a inter-relação entre as diversas etapas da nossa
cadeia de suprimentos através dos sistemas de supply chain. Isto abre novas perspectivas para os
provedores de engenharia e produtos, desmentindo o conceito de que automação virou
commodity.

1. UM POUCO DE HISTÓRIA:

A automação industrial se caracterizava, há alguns anos atrás por um terrível imobilismo.


Os sistemas abertos eram o inalcançável Santo Gral. Era a época do culto ao fornecedor. Neste
regime feudal, ninguém queria abrir seu território e permitir o acesso dos demais fornecedores aos
seus clientes sagrados e encurralados. O mote do período seria: “Faça a sua escolha por uma
seita, digo marca, e devote fidelidade eterna à sua tecnologia…”.
Quem conseguiu subverter este ambiente de radicalismo tecnológico foi, na minha opinião,
o aparecimento simples e despretensioso do PC. Caíram os painéis sinópticos, sumiram as mesas
de controle e o PC passou a reinar como a plataforma preferida de supervisão e operação de
processos. Os softwares SCADA apareceram em diversos tamanhos, em diversos sistemas
operacionais, com diversos repertórios de funcionalidades. O mercado se depurou com o tempo.
As empresas que produziam estes produtos se fundiram, se consolidaram, ficaram no final
reduzidas a uma dezena.
Os Sistemas operacionais de tempo real (RTOS) deram lugar ao Windows NT de uso
genérico e de performance questionável em aplicações críticas. Mas nesta época, já estava claro
que supervisório era uma aplicação soft real time. Por outro lado o Windows NT apresenta grandes
vantagens em relação ao custo total de propriedade, à beleza e popularidade da sua interface
gráfica e à abundância de drives de comunicação com todos os dispositivos de mercado.
O paradigma do uso de uma rede determinística, interligando estações de controle foi
vencido, mais uma vez por uma tecnologia alienígena ao ambiente de automação. Uma rede de
propósitos gerais, não concebida para uso em ambiente industrial, torna-se a vencedora. A
Ethernet 10-Base-T, justamente o padrão que usa par trançado como meio de comunicação, a
princípio preterido em favor do cabo coaxial,vence esmagadoramente a disputa. Hoje a switched
Ethernet 100-Base-T se torna o padrão. Se observarmos a evolução da história, vemos que o mais
geral substitui o especialista, o mais barato, o mais comum, o que é padrão de fato, vence.
Os CLPs também tiveram que mudar. Tinham que operar em rede como qualquer
computador normal.
Buscaram CPUs mais genéricas, maiores capacidades de memória, redes de campo que
propiciassem alta descentralização e finalmente linguagens padrões. A linguagem ladder surgiu
antes da criação dos CLPs.Servia para documentar gabinetes de relés. Os relés se foram, o CLP
conquistou espaço também no tratamento de variáveis analógicas e malhas de controle, mas o
ladder continuou. Continuou porque facilitava a manutenção, porque era a linguagem natural dos
eletricistas, porque era mais fácil de entender, porque gerava menos código e cabia na exígua
memória dos CLPs, porque… Na verdade ninguém acreditava mais nestas justificativas. Os relés
não são estudados em cursos técnicos, ou de engenharia, há décadas e não há algo mais
Automação II Relton Alves da Silva

indefensável, que projetar um diagrama lógico e depois traduzi-lo em linguagem ladder. Finalmente
surge o padrão IEC 61131-3, definindo cinco linguagens padrões para programação para CLPs ou
remotas industriais. E o CLP começa a mudar de verdade.

Talvez não devamos blasfemar tanto contra o conservadorismo dos CLPs. Talvez sua
sobrevivência até os dias de hoje deva-se exatamente a isto. Dick Morley, o inventor dos CLPs
conta que no início era normal que os usuários quisessem confrontar a robustez do novo
equipamento comparando-o com a solução convencional. Era comum que os clientes quisessem
comprovar se ocorria algum dano depois de provocar uma queda de dois metros do equipamento.
Ou testar seu funcionamento quando próximo a um arco voltaico produzido por uma máquina de
solda industrial. No início, o CLP teve que provar que era um bugre,apto para as tarefas mais
árduas. Por isso custou a suavizar sua aparência e comportamento, a se socializar e a falar língua
de gente.
Os fabricantes de CLPs também compreenderam a inequação básica: software > hardware
e passaram a produzir sistemas SCADA, sistemas BATCH e outros pacotes mais especializados.
Passaram a concorrer para a solução completa: SCADA + CLP .
Já recentemente surgiram os sistemas híbridos, uma versão light dos SDCDs dedicado às
aplicações com mais de 1000 analógicas, limite aceito para a aplicação SCADA + CLP. Os
sistemas híbridos trouxeram alguma novidades interessantes. Arquitetura cliente-servidor, troca a
quente de cartões de entrada e saída,dicionário de dados único. É possível definir o nome lógico
de um ponto na remota de aquisição de dados e controle e este nome será enxergado e
reconhecido por todos os módulos de software do sistema, independente de seu nível hierárquico.
Neste sistema também é possível programar os algoritmos de controle, usando as linguagens IEC
61131-3 diretamente das estações de supervisão, características que só os SDCDs apresentavam.
E os SDCDs ? Também desceram do pedestal. Bastou alguém atirar a primeira pedra e os
dinossauros acordaram. Buscaram obedecer a padrões de interligação de mercado. Procuraram
parecer mais esbeltos, abertos e flexíveis. Adotaram redes de instrumentos inteligentes e
“intercambiáveis”. Na área de instrumentação a revolução se deu mais dolorosamente. Era
necessário dotar os instrumentos de mais inteligência e de fazê-los comunicar em rede. O velho
padrão 4-20 mA para a transmissão de sinais analógicos tinha que ceder lugar à transmissão
digital. A principio foi desenvolvido um protocolo que aproveitava a própria cablagem já existente,
fazendo transitar sinais digitais sobre sinais analógicos 4-20 mA. Este protocolo (HART) não foi
mais que um paliativo, embora permaneça até hoje em sua interinidade.
De certa forma, representa também uma reação ao avanço das novas tecnologias. Depois
surgiram uma
profusão de padrões e protocolos que pretendiam ser o único e melhor barramento de campo. O
tempo e o
mercado acabaram por depurar o conceito e a selecionar os mais aptos.
Alguns barramentos servem apenas para interligar sensores e atuadores discretos,
basicamente
transmitindo estados e bits de comando. Foram denominados de Sensorbus. Entre eles temos a
rede ASI liderada pela Siemens e o Interbus-S. Um segundo nível era representado pelas redes
capazes de interligar dispositivos inteligentes mais complexos, enquadrados na denominação
genérica de Devicebus. As mensagens aqui já são orientadas a byte. Nesta categoria se
enquadram as redes DeviceNet e ControlNet, capitaneadas pela Rockwell, Ethernet 100Base-T e
LonWorks da Echelon. Finalmente restam as redes de instrumentos de campo ou Fieldbus
especializadas em variáveis analógicas e controle. Além do padrão Fieldbus Foundation (IEC/SP50
H1) temos o Profibus PA e o WorldFIP, os dois últimos padrão de fato na Europa.
A Ethernet está invadindo também os instrumentos de campo. A Fieldbus Foundation
decidiu implementar a rede High Speed Fieldbus utilizando a rede High Speed Ethernet (HSE)
100Mbps com TCP/IP e toda suite de protocolos Internet, mas conservando a DLL Data link layer
utilizada no padrão Fieldbus H1. Esta rede irá promover a interligação de um segmento H1 à sala
de controle. Por outro lado, o padrão IEEE1451 determina como sensores e atuadores podem ser
ligados diretamente a uma rede de controle, incluindo a Ethernet. Este padrão abre uma alternativa
para a Ethernet como em aplicações que não requerem segurança intrínseca ou alimentação
através do cabo de rede.
Automação II Relton Alves da Silva

bi t level )
DEVICEBUS(by t e level )
O Windows NT e a Ethernet talvez sejam os grandes vencedores do que costumamos
denominar de níveis I e II da pirâmide da automação. Estas considerações fecham o painel das
principais mudanças no cenário do chão de fábrica que estamos mais acostumados a associar com
o conceito de automação.

Figura 2 - A pirâmide da automação antes e depois

2. A ESPECIALIZAÇÃO:
Uma outra revolução iria acontecer na maneira de se definir uma fábrica, seus
equipamentos de controle e a maneira de programar aplicações de processos em batelada. O
padrão ISA S88.01 começa por definir o nome das coisas. Primeiro define um modelo físico (célula
de processo, unidade, módulo de equipamento,módulo de controle), depois um modelo procedural
que estrutura as ações hierarquicamente em procedimentos, procedimentos de unidade,
operações e fases. O modelo de controle de atividades define uma hierarquia de receitas e o
modelo de processo os resultado da aplicação da estratégia de controle em um processo
(destilação, filtração, polimerização, hidrogenação). O importante disto tudo é que é uma aplicação
de batelada deve ser programada de uma forma diferente. A receita não pode mais ser
programada no CLP, pois engessa o projeto. As fases devem ser programadas no CLP como
blocos de um quebra cabeças. Como o quebra cabeças será montado, dependerá de uma receita
que começa a ser definida no ERP e virá sendo refinada e personalizada para os equipamentos de
um determinada linha.
Automação II Relton Alves da Silva

A linguagem de programação ideal para este tipo de aplicação é a Sequential Function


Charts. O sistema deve acompanhar em que fase o processo está, quais os valores das variáveis
naquela fase, qual a duração da fase, etc. Resumindo, ao trocar uma receita, as fases serão
chamadas em uma ordem diferente e com diferentes parâmetros. Os principais sistemas SCADAS
incorporaram módulos especiais de gerenciamento de bateladas, se especializando e procurando
atender as necessidades dos clientes deste setor.
Outras especializações poderiam ser examinadas, mas vamos apenas listá-las. Para cada
um destes nichos surgiram produtos extremamente dedicados, que com o tempo também passam
a adotar hardware e software mais padronizados, mas que constituem uma área de atuação
caracterizada por poucos players em todo o mundo. Nesta categoria estão o controle de vibração
de máquinas rotativas, a sincronização de eventos em usinas de energia elétrica, o controle e
supervisão de subestações, o controle de processo eletrolítico de alumínio, o controle de fornos a
arco em indústrias de ferro ligas, o controle de semáforos urbanos, o controle ferroviário, o controle
de elevadores, etc.

3. GERENCIANDO E OTIMIZANDO O PROCESSO


Até o início dos anos 90, os sistemas de controle constituíam ilhas de automação. Um
sistema controlava o pátio de matérias primas, outro o alto forno, outro a aciaria. Um forte desejo
de todos os usuários era poder unificar os dados de todas as áreas em um banco de dados único.
O primeiro objetivo era propiciar uma massa de dados para análise dos engenheiros de processo.
Estes queriam ser independentes do pessoal da automação, que lhes negavam os dados e
que forneciam relatórios pobres e pouco flexíveis e também do pessoal da informática, que não
tinham tempo para atendê-los.

Neste cenário, surgiram os historiadores de processo ou PIMS (Plant Information


Management Systems).Estes softwares são capazes de buscar os dados onde estiverem e inseri-
los num banco de dados temporal com capacidade para meses ou anos. Devido a um eficiente
algoritmo de compressão de dados, é possível buscar num piscar de olhos um gráfico da
temperatura de um forno no dia 28 de fevereiro de 1998 e compará-lo com o comportamento do
mesmo forno um ano e cinco meses mais tarde. É tudo que o engenheiro de processo
precisava.Este software representa também a redenção do engenheiro de automação que agora
não precisa mais fazer malabarismos com os geradores de relatórios dos sistemas SCADA para
fazer aquilo que o sistema SCADA não sabe fazer. E colocar um banco de dados relacional no
SCADA só piorava as coisas. O PIMS, nascido para atender o processo químico e petroquímico,
irradiou-se para todo o universo dos processos contínuos. E a engenharia de automação migrou
um nível para cima.
A área de modelagem e otimização de processos industriais também cresceu e ramificou-
se, mas com menor ímpeto, entre nós do hemisfério sul. A indústria do cimento adotou os sistemas
especialistas para a condução de seus fornos, moagens e resfriadores. A mineração também
começou a adotar estas soluções,mas de forma mais cautelosa. A indústria petroquímica focou
principalmente na adoção de modelos e técnicas de controle avançadas, abundantes para controle
de processos neste setor.
As ferramentas de desenvolvimento evoluíram muito e tornaram-se mais amigáveis.
Passaram a reunir os vários tipos de tecnologias: sistemas especialistas, lógica nebulosa e redes
neurais, essa última usada para modelar processos, onde a modelagem fenomenológica se mostra
muito difícil.
Automação II Relton Alves da Silva

4. OS SISTEMAS DE PRODUÇÃO
Uma vez tendo o processo e os dados que descrevam o seu comportamento sob controle,
a automação subiu um nível na pirâmide. Era preciso transformar dados em informação de
negócio. Todos os sistemas construídos em volta do processo de manufatura passaram a ser alvos
de uma racionalização e de automatização. Estes sistemas são englobados no termo geral de
EPS: Enterprise Production Sytems, os sistemas de produção. Aí estão incluídos o MES –
Manufacturing Execution System responsável por todo o acompanhamento da produção, da ordem
de produção ao produto final, os sistemas de manutenção, os sistemas de gerenciamento de
laboratórios (LIMS – Lab Information Management Systems), os sistemas de gerenciamento de
ativos e outros.
Hoje o MES é visto como uma das etapas de um modelo maior que representa a cadeia de
suprimentos (Supply Chain). Embora as empresas de automação mais tradicionais do mercado
não tenham percebido esta migração de foco, tornou-se claro para os atores do universo da
automação de todo o mundo, que a visão da automação deveria ser mais holística. A onda de
fusões e aquisições do último ano comprovam esta constatação. As empresas de integração de
soluções de negócio passam a adquirir avidamente as empresas que entendem do processo de
produção preparando-se para a terceira onda. E as grandes empresas de automação buscaram se
qualificar para atuar em outro nicho, mais próximo dos centros de decisão das corporações. O
mercado de supply chain passa a ser preenchido por empresas vindas da experiência de
integração de ERPs e por empresas de automação que ganharam oportunidades dentro do
próprio universo de seus clientes. Após conhecerem os processos produtivos elas buscam
conhecer o negócio como um todo.

Figura 3: As três ondas da racionalização do negócio

O MES tem passado por diversas crises e ainda não alcançou a sua verdadeira identidade.
Primeiro serviu de ponte para ligar o chão de fábrica aos ERPs, como se fosse este o seu papel.
Numa segunda fase passou a ser implementado, geralmente nos processos de manufatura, para
atender às exigências do mercado, principalmente a necessidade de se ter rastreabilidade de tudo
que é produzido. Os clientes querem saber o histórico de cada constituinte de um produto, a que
horas foi produzido, por quem e com que qualidade. O outro objetivo é realmente controlar as
variáveis de negócio. Métricas de processo devem ser definidas para tudo que influa no custo e na
qualidade. O gerente muda de papel e fica inserido na malha de realimentação do negócio. Ele
deixa de ser o analista do erro passado e passa a ser responsável pelo que acontece em tempo
real.
A automação continua após o produto acabado. Agora é preciso armazená-lo, inventariá-lo
e recuperá-lo automaticamente. As tecnologias de captura automática de dados (CAD) se
sofisticaram. A identificação do produto antes feita apenas pelo código de barras passa a ser feita
preferencialmente pelos RFids (Radio Frequency Identifiers). Os produtos podem ser identificados
automaticamente enquanto se deslocam pela fábrica. As panelas de gusa, os carros torpedo, os
vagões ferroviários, tudo deve ser identificado e rastreado em tempo real e mostrar o se conteúdo
a qualquer instante. Os sistemas de WMS (Warehouse Management Systems) possibilitam o
Automação II Relton Alves da Silva

comprometimento de vendas livre de erros. O sistema de controle e planejamento de produção,


ciente do disponível em estoque e das capacidades reais do processo, pode atingir um maior nível
de acerto. Em muitos ambientes, uma rede de coletores de dados se comunicando por rádio
freqüência se incumbirá do Work in process, medindo eventos antes impossíveis de serem
percebidos por um PLC convencional. Ë melhor declarar um evento manualmente do que não
informá-lo ao sistema. Se um sensor é demasiado caro para capturar um dado automaticamente,
um terminal de entrada manual será introduzido. Pecado é não informar, é ter um evento fora de
controle. A automação chega a sua maturidade ao perceber que sua finalidade é compor uma
solução de negócio.

5. NOVAS FRONTEIRAS – NOVAS OPORTUNIDADES

A implantação dos ERPs trouxe novas oportunidades. Um sistema de gestão integrada


precisa ser alimentado com dados reais dos diversos processos. O módulo de gerenciamento de
materiais precisa conhecer todo o movimento internos de matérias primas e produtos acabados, o
sistema de recursos humanos tem que realizar o controle de acesso às áreas da empresa e
apontar a presença dos funcionários, a utilização do restaurante e o acesso a estacionamentos e
áreas reservadas. Tudo isto requer equipamentos especializados e automação.

Figura 4: Interligando o ERP aos diversos processos de uma fábrica

6. A AUTOMAÇÃO DA FORÇA DE VENDAS


A outra grande vertente mostrou ser a automação da força de vendas. Os vendedores
recebem do ERP,pela manhã, o planejamento das rotas de vendas, contendo todos os clientes a
serem visitados. Estes dados são transmitidos via rede telefônica e recebidos por um computador
hand held especializado, que substitui os palm tops de propósitos gerais, usados na primeira
geração de produtos. Estes computadores constituem sistemas completos: micro 486, sistema
operacional Windows CE, banco de dados relacional, scanner, modem, interface InfraRed ou RF.
Os vendedores possuem informações completas sobre o histórico de vendas daquele cliente,
políticas de descontos ou promoções on line, calcula preços emite nota fiscal e pode efetuar
recebimentos e dar quitações. O software de retaguarda analisa as vendas de todos os endedores,
consolida o movimento diário, emite relatórios, analisa históricos e estatísticas de vendas por
região, por produto, por segmento e detecta tendências e padrões, passando a ser uma ferramenta
Automação II Relton Alves da Silva

imprescindível para controlar o processo de vendas. Note o grifo na palavra controlar. Não se trata
apenas de supervisionar, mas de influir no processo. É o velho princípio da realimentação sendo
utilizado para controlar as variáveis do processo, o gerenciamento das variáveis de negócio, e as
variáveis do processo de vendas. Fechar o loop é preciso… Medir, analisar e coordenar como
preconiza o modelo Repac da AMR concebido para modelar os sistemas de produção.

Figura 5: O modelo REPAC da AMR: o MES como etapa da cadeia de suprimentos

7. E-AUTOMATION, E-COMPANY, E-PROCESS, E-BUSINESS: O PAPEL DA


INTERNET
A explosão do uso da Internet nas indústrias de processo será avassalador. É esperado um
período de grande crescimento para as indústrias de processo nos próximos dois anos com mais
do que 10% do comércio industrial sendo colocado on-line até 2003 (Forrester Research). O
impacto da ferramenta Internet se dará em todas as etapas do processo:

7.1 Compra de insumos e matérias primas (procurement)


A maior parte dos fornecedores cadastrados estarão on-line colocando suas ofertas. Com uma
maior visibilidade das disponibilidades de estoques, preços e condições de pagamento, o
comprador terá a oportunidade de fechar melhores negócios. Os softwares B2B permitem segurar
uma posição de compra por um tempo determinado, fazer contra ofertas, enfim entabular todos os
passos de uma negociação normal. Fretes e armazenamento também são negociados de forma
integrada. Os operadores logísticos passam a oferecer uma cadeia completa de serviços incluindo
transporte, armazenamento,recondicionamento de produtos, simplificando a operação da cadeia
de suprimentos.
7.2 Venda e distribuição de produtos.
Grande parte dos clientes estarão on-line. Parte do esforço hoje realizado pela força de
vendas, mesmo que informatizada, será realizado diretamente pela Internet. A iniciativa de compra
e venda será bilateral. O fornecedor coloca de manhã a oferta para seus clientes. Pode oferecer
maiores vantagens num determinado produto, para um determinado perfil de cliente. O cliente por
sua vez pode colocar um pedido de forma assíncrona e no caso de uma rede de varejo, ser
atendido pelo primeiro caminhão de entregas servindo sua região.
7.3 Integração da cadeia de suprimentos.
Os clientes poderão consultar a qualquer instante o status de sua ordem de compra numa
linha de
produção, ter o prazo consolidado de entrega visível em tempo real. O mesmo ocorrerá com a área
de serviços. O cronograma do projeto, o status do desenvolvimento de cada etapa, o cronograma
de desembolso, enfim todas as informações, estarão disponíveis on-line.

7.4 Integração dos processos internos: Intranet.


Todos os processos internos de manufatura serão acompanhados internamente pela
Intranet. Ao invés de relatórios extensos em papel, temos informações on-line. Apenas a
Automação II Relton Alves da Silva

informação necessária, personalizada para cada nível, para cada responsável por tomadas de
decisão. Esta função já está sendo propiciada pelos sistemas MES atualmente em implantação.
Tudo isto irá requerer um trabalho imenso das empresas de engenharia para alinhar os processos
de seus clientes e torná-los Internet-Ready. Ao colocar uma empresa não preparada na Internet,
estaremos apenas expondo suas fragilidades. A empresa deverá ser preparada para isto. Não se
pode acompanhar on line, a qualidade de um processo sem qualidade e nem acompanhar a cadeia
de custos de um produto em um processo, onde não existem métricas estabelecidas. A torta da
empresa integrada possui diversas camadas. A internet é o glacê e a vela do bolo de noiva. O bolo
só será palatável se todas as camadas tiverem sido construídas com esmero. E se a base não for
consistente toda a torta irá desmoronar.
Automação II Relton Alves da Silva

LISTA 1

1. Porque, segundo o autor, o sentido da palavra automação passa por


uma revolução? Comente com suas palavras.
2. O que caracteriza a era do “culto ao fornecedor”e como foi o
processo de mudança e depuração?
3. Quais as relações existentes entre o Windows NT e Ethernet na
padronização dos sistemas de automação?
4. Na evolução dos CLP’s porque a linguagem ladder se perpetuou até
os dias atuais? Justifique.
5. Quais as razões que justificam a sobrevivência dos CLP’s até os dias
atuais?
6. Quais as características dos sistemas híbridos e o que aconteceu
com os SDCD’s?
7. Estabeleça a relação entre as redes de controle e instrumentação:
4~20 mA, Hart, Fieldbus e Ethernet.
8. Descreva a pirâmide de automação antes e depois.
9. O que são PIMS e MES?
10. Quais as novas fronteiras e oportunidades nos negócios das
empresas e como se situa a automação?
Automação II Relton Alves da Silva

Marque Verdadeiro ou falso:

( ) O WNT é um RTOS sistema operacional de tempo real de grande


utilização em
automação industrial.
( ) O WNT é recomendado para aplicações críticas no tempo, por
exemplo para
controlar a trajetória de um míssil balístico intercontinental.
( ) A linguagem ladder surgiu com a criação dos CLPs.
( ) Sistemas híbridos foram criados para atender aos mercados onde
havia um grande número de variáveis analógicas e digitais. Por
exemplo o processo de produção de açúcar e álcool.
( ) Os sistemas híbridos abraçaram o padrão IEC61131-3.
( ) Após o advento da rede Fieldbus, apenas um padrão passou a ser
utilizado por todas as empresas.
( ) O padrão IEEE1451 mostra como sensores e atuadores podem ser
ligados
diretamente à rede de controle.
( ) Existe possibilidade de se associar cabos de alimentação
diretamente a um cabo Ethernet.
( ) A rede ASI é ideal para interligação de instrumentos no chão de
fábrica tais como transmissores de pressão diferencial, temperatura,
fluxo e nível.
( ) Sistemas de batelada são programados utilizando exatamente as
mesmas ferramentas e metodologias de sistemas de processos
contínuos.
( ) A linguagem mais adequada para programação de aplicações em
batelada é a de blocos lógicos.
( ) O rastreamento da produção é uma das funções do sistema ERP.
Automação II Relton Alves da Silva

1. PIMS - PLANT INFORMATION MANAGEMENT SYSTEM


O termo PIMS (Plant Information Management System) começa a ecoar nos meios de TI
(Tecnologia da Informação) e também onde é feita a sua aplicação, nos meios industriais. Trata-se
de uma tecnologia emergente que aos poucos começa a ser difundida entre os vários tipos de
indústrias. Esta tecnologia não é nova para alguns segmentos industriais, tal como o segmento
petroquímico, onde sua utilização traz ganhos na ordem de milhões de dólares por ano. Devido
aos seus benefícios, esta nova forma de controlar as informações provenientes do processo será
cada vez mais utilizada nos novos projetos que envolvam sistemas de supervisão e controle,
sendo uma complementação para ambos.

A MESA (Manufacturing Execution System Association), instituição criada para


regulamentar as definições das novas tecnologias de middleware (principalmente de MES),
tenta sintetizar as diversas funções dos futuros sistemas industriais. Como exemplo temos hoje
definidos muitos conceitos, dentre os quais os mais conhecidos são os de MES, EPS e PIMS. Aqui
vamos nos concentrar no conceito de PIMS, mas é recomendado o estudo dos outros dois termos
que de certa forma complementam ou estendem o conceito de PIMS.
Basicamente PIMS é um software contendo um repositório que concentra toda a informação
relevante das células de processo. As informações de processo estão diretamente ligadas a
sistemas de supervisão e controle. O PIMS coleta informações dos sistemas de Supervisão, CLPs,
SDCDs e sistemas legados e os armazena em uma base de dados real - time. Tal base de dados
tem características que não são encontradas nos bancos de dados convencionais. Suas
características são de grande capacidade de compactação (tipicamente de 10:1) e da alta
velocidade de resposta a consulta em sua base histórica. Devido a isto é possível armazenar um
grande volume de dados com recursos mínimos se comparado às soluções convencionais.

Figura 1 - Figura de arquitetura de sistemas utilizando PIMS


O PIMS é uma solução pronta para quem quer implementar rapidamente um
middleware. É fácil encontrar um produto PIMS que satisfaça 90% das necessidades
de uma indústria. Quando aparece uma nova necessidade não contemplada nos
pacotes tradicionais, o PIMS deixa aberta a porta para qualquer desenvolvimento de
funções específicas, podendo-se implementar funções que utilizem, por exemplo, os
tradicionais bancos de dados relacionais.
Automação II Relton Alves da Silva

2. COMUNICAÇÃO COM SISTEMAS EXTERNOS

Uma das tarefas mais difíceis na implementação de sistemas de middleware é a conexão com
os sistemas que compõem as células de produção. Estes sistemas,mesmo dentro de uma fábrica
bem planejada e moderna, são extremamente heterogêneos. Os sistemas PIMS dispõem de
ferramentas especialmente desenvolvidas com a finalidade de conexão com os sistemas industriais
(supervisão,CLPs, SDCDs, sistemas legados, etc) tornando a tarefa mais fácil. Estas ferramentas
já dispõem de uma variedade imensa de drivers de comunicação (tipicamente 150),cobrindo a
maioria dos sistemas existentes. Estes drivers de comunicação englobam as mais novas
tecnologias de troca de informação, tais com o OPC. Caso não se tenha o driver específico para a
conexão entre o software de PIMS e o sistema industrial em questão, existem ferramentas
disponibilizadas pelos fabricantes que facilitam a confecção de um novo driver.

3. COMPACTAÇÃO DE DADOS

Os softwares de PIMS dispõem de algoritmos de compactação que permitem armazenar


informações ocupando um mínimo espaço em disco. Para ilustrar tal compactação imaginemos o
comportamento de uma variável qualquer de processo,representada no gráfico da Figura 2:

Figura 2 – Sem compactação

Podemos representar o gráfico da Figura 2 pela ocupação dos 25 pontos que são mostrados
periodicamente no tempo. Os algoritmos de compactação basicamente excluem os pontos que não
são necessários para a composição do gráfico e não os considera, faz isso através da
configuração de uma banda morta.

Figura 3 – Com compactação


Automação II Relton Alves da Silva

Após a aplicação do algoritmo de compactação, dizemos que são necessários um número


muito menor de pontos para representar a mesma informação.

4. DISTRIBUIÇÃO DEMOCRÁTICA DA INFORMAÇÃO

A função de distribuição de dados para outros níveis organizacionais é uma das metas do
PIMS. Através de uma série de mecanismos e aplicativos, o PIMS democratiza a informação
dentro da organização. Informações que antes só eram acessadas no local onde eram geradas,
agora são disponíveis para qualquer parte da organização que tenha interesse na mesma. Além da
informação romper a barreira dos departamentos/divisões e níveis hierárquicos, esta ainda quebra
barreiras de distância física, podendo ser acessada de sites remotos ou pela Internet. Vários
softwares de PIMS possibilitam a visualização da informação a grandes distâncias, entre plantas
que estão em lados opostos do globo terrestre. O grau de sofisticação de tais sistemas é tão
elevado que informações são disponibilizadas utilizando o formato de tempo GMT que considera a
posição terrestre.
A informação armazenada na base de dados do PIMS pode ser consultada de várias formas.
Geralmente os fabricantes de PIMS disponibilizam uma ferramenta gráfica,bem simples de ser
usada, para que os usuários possam efetuar a pesquisa on-line para saber o que ocorre no
processo. Além disto, informações de momentos diferentes nos tempos podem ser cruzadas.
Pode-se também consultar as variáveis on-line ou históricas.

Figura 4 - Figura de variáveis de processo de uma fábrica de cimento visualizadas através


de uma ferramenta gráfica de PIMS

As informações contidas dentro da base de dados do PIMS também podem ser acessadas
com as ferramentas mais comuns do mercado, tais como Excel e Access. Isto é possível devido a
disponibilização das informações através de Add-Ins (Excel) ou através do mecanismo ODBC, que
permite que sejam retornados dados da base real - time através de comandos SQL.
Automação II Relton Alves da Silva

Figura 2 - Figura do software Excel recebendo informações da base de dados do PIMS

As facilidades descritas acima possibilitam que o usuário do PIMS gere por si só os relatórios
que desejar, sem a necessidade de contratar uma software house para desenvolve-los. Isto
representa uma grande economia em relação a custos de implementação de software.
Além das formas de visualização através de ferramentas que disponibilizam gráficos e textos,
as informações ainda podem ser acessadas através de sinóticos resumido e através da internet.

Figura 3 - Figura de tela sinótica de um processo químico, as informações provêem do


PIMS
Automação II Relton Alves da Silva

5. VANTAGENS DE SE USAR O PIMS

Os softwares de PIMS incorporam outras funções que antes só existiam nos níveis de
supervisão e controle ou no nível corporativo. É possível associar um alarme para quaisquer
variável. Também pode-se acompanhar as variáveis com contexto financeiro. Tabelas contendo os
preços associados aos diversos insumos podem ser obtidas dos sistemas corporativos e novas
variáveis no processo podem ser criadas através de cálculos. Feito isto, o usuário passa a ter além
da tradicional visão de processo, uma visão financeira do seu negócio.
Acima são listados apenas algumas das aplicações que podem ser extraídas de um sistema
PIMS. Deixo para o leitor a tarefa de imaginar a gama de aplicações que podem fazer uso das
informações contidas no PIMS visto que o mesmo reflete em sua base real time todos os dados de
processo.

5.1 Porque usar o PIMS se todos os meus dados estão nas células de
processo?

Tipicamente os sistemas DCS e PLCs tem um conceito operacional e uma visão de


acompanhamento e troubleshoot voltados para o tempo real e solução de problemas relacionados
ao chão de fábrica. Os sistemas supervisórios dispõem de um histórico que normalmente não
ultrapassam um ou dois meses, tornando-se assim impossível uma análise comparativa do
comportamento do processo hoje, no mesmo período do ano passado, ou nos últimos 5 anos.

Figura 4 – Transformação da Informação dentro

Os sistema PIMS é capaz de armazenar informações de processo com históricos que variam
de 1 a 15 anos. Feito isto, é possível comparar informações entre vários períodos para a mesma
variável, cruzar informações provenientes de células de processo distintas e basicamente efetuar
qualquer análise nos dados históricos Além disto, existem ferramentas prontas que são utilizadas
pelos usuários para análises avançadas de processo.
Automação II Relton Alves da Silva

6. EXEMPLOS
6.1 Comparação de variáveis em períodos diferentes.
Pode-se fazer consultas a quaisquer variáveis (tags) armazenadas na base histórica PIMS.
Estas consultas se tornam especialmente interessantes quando comparamos uma, ou
várias variáveis em momentos distintos no tempo, como visto no gráfico da Figura 4 no
qual temos uma mesma variável em momentos diferentes.

Figura 4 – Visão de uma mesma variável em momentos diferentes

6.2 Contexto Financeiro


É possível dar um contexto financeiro aos processos através de um mecanismo de
Donwload das tabelas de preços de insumos e custos de energia, mão-de-obra, etc; dos
sistemas corporativos.

Figura 6 – Contexto financeiro das variáveis de processo


O PIMS é capaz de calcular dinamicamente índices de custo, rendimento e desempenho
financeiros fornecendo uma nova visão da operação do negócio.
Pode-se atribuir alarmes com limites mínimos e máximos para as novas variáveis.
Sendo assim pode ser implementando o conceito de Dynamic-Value Chain, ou o
acompanhamento on-line da cadeia de valores. Assim, não é necessário o fechamento do mês
para que se apure perdas financeiras.
Automação II Relton Alves da Silva

6.3 Investigação de problemas

Pode-se comparar uma situação de uma produção normal com uma situação problemática.
Tal comparação ressalta quais variáveis não estavam em seu valor normal ou típico. As
variáveis podem corresponder à mesma célula de produção ou a células de produção
diferentes. Veja os gráficos abaixo ( Figura 5)

Figura 5 – Investigação de Problemas

6.4 Cruzamento de informações (variáveis) de célula de produção


Distintas

Uma excelente forma de avaliar a real capacidade produtiva de uma célula (on-ine) é
através da criação de um indicador de performance advindo do cruzamento deinformações
entre células de processo constituindo um benchmark.
Podemos por exemplo correlacionar as variáveis de consumo de energia elétrica com a
produção. Através desta medida podemos obter um consumo específico (CE) de
0,8Kwr/unidade de produção (Prod. Final). Desta forma, se a produção aumentar, o consumo
de energia aumenta também e o CE fica próximo ao 0,8Kwr / unidade.
Caso ocorra um problema e o consumo de energia aumente e a produção não, o CE pode
passar, por exemplo para 5,0Kwr / unidade. Pode-se ver a mudança graficamente e até
associar um alarme a mesma.
Automação II Relton Alves da Silva

Figura 6 –Benchmark de consumo de energia elétrica / produção


6.5 Estudo de variáveis diversas que podem influenciar o processo
É possível verificar como variáveis externas ao processo podem influenciar o mesmo, tais
como temperatura externa a fábrica, umidade do ar, etc. Desta forma o processo produtivo não
se restringe mais as células de produção possibilitando uma visão mais holística.

6.6 Processo de batelada (Gold Batch)


Tipicamente e historicamente os produtos de PIMS são mais aplicados em processos de
contínuos, mas existem ferramentas mais recentes que tornam estes produtos aplicáveis em
processo por batelada ou processos contínuos com contexto de batelada.
Um lote ou batch pode ter seus eventos de início e final gravados em uma base de dados
relacional. As datas de início e fim servem para associar à batelada as variáveis contínuas da
base de dados temporal de um PIMS. Além disto pode-se salvar informações adicionais em um
banco de dados relacional.

Figura 7 – Informações de processo e batch em um mesmo contexto


Automação II Relton Alves da Silva

Enterprise resource planning software


Planejamento de recursos empresariais

Para começarmos a entender o ERP, é importante sabermos que ele não possui nenhuma
ligação direta com a sua sigla. Esqueça a palavra planejamento, ele não faz isso, e esqueça a
palavra recurso, um termo descartável. Mas lembre-se da parte empresarial. Ele serve para
integrar todos os departamentos e funções de uma companhia em um simples sistema de
computador que pode servir a todas necessidades particulares de cada uma das diferentes
seções.
É um grande desafio construir um único programa de software que supra as necessidades
do departamento financeiro, assim como dos trabalhadores de recursos humanos e também do
depósito e é isso que o ERP faz. Cada um desses departamentos, tipicamente, possuem seu
próprio sistema de computador, cada um aperfeiçoado para cada necessidade, para a forma
de trabalho de cada departamento. O ERP combina todos eles juntos em um só programa de
software integrado que trabalha com um banco de dados comum. Dessa forma, os vários
departamentos podem mais facilmente dividir informações e se comunicar entre si.
Essa abordagem integradora pode dar um grande retorno financeiro se as companhias
instalarem o software adequadamente. Pegue o pedido de um cliente como exemplo:
tipicamente, quando um cliente faz um pedido, aquele pedido começa uma jornada em papel,
de um lugar para outro na empresa, sendo digitado e redigitado em vários computadores ao
longo do caminho. Toda essa jornada causa atrasos e perdas de pedidos, e cada digitação, em
um diferente sistema, é convidativo a erros. Ao mesmo tempo, nenhuma companhia sabe
realmente em que estágio um pedido se encontra em um determinado momento porque não há
como o departamento financeiro, por exemplo, entrar no computador do depósito para ver se o
item foi embarcado. "Você terá que ligar para o depósito", é a resposta familiar dada aos
frustrados consumidores.

Como o ERP pode melhorar a performance de uma empresa?


Automação II Relton Alves da Silva

ERP automatiza as tarefas envolvendo a performance de um processo, tal qual a


finalização de um pedido, o qual envolve pegar o pedido de um cliente, enviá-lo e cobrá-lo.
Com o ERP, quando um representante recebe o pedido de um cliente, ele ou ela, tem todas as
informações necessárias para completá-lo. Todas as pessoas na empresa vêm o mesmo visor
e têm acesso a um único banco de dados que guarda o novo pedido do cliente. Quando um
departamento termina a sua parte em um pedido, este é enviado automaticamente para o
próximo departamento via ERP. Para saber em que ponto está um pedido, em um determinado
momento, é só checar no ERP. Com sorte, o processo se move como um raio dentro da
organização, e os clientes recebem seus pedidos mais rapidamente que antes. O ERP
consegue aplicar essa mesma mágica à maioria dos processos empresariais, tal qual manter
os funcionários informados sobre seus benefícios ou sobre decisões financeiras em geral.
Esse, pelo menos, é o sonho do ERP. A realidade é bem mais dura.
Vamos retornar aos pontos tratados anteriormente. Aquele processo talvez não tenha sido
eficiente, mas ele foi simples. O departamento financeiro fez o seu trabalho, o depósito fez o
seu trabalho e se algo deu errado fora das paredes do departamento, esse problema é sempre
de outra pessoa. Com o ERP essa história muda sensivelmente: os representante que
recebem os pedido dos clientes, não são mais mero digitadores colocando o nome de alguém
em um computador e batendo na tecla retornar. O monitor do ERP faz deles pessoas de
negócio. Ele vai desde o crédito do cliente, passa pelo departamento financeiro e vai até o
fluxo de trabalho do depósito.
O cliente pagará em dia? Nós seremos capazes de embarcar o produto em tempo? Essas
são perguntas que os representantes de vendas nunca tiveram que fazer antes e que afeta o
cliente e todos os outros departamentos da empresa. Mas não são apenas os representantes
que terão que acordar. As pessoas no depósito, que estavam acostumadas a manter as datas
na cabeça ou em pedaços de papel, precisam colocar toda informação on-line agora. Se eles
não fizerem isso, os representantes de venda verão baixos níveis de produtos no monitor e
falarão aos clientes que seus pedidos não estão disponíveis no estoque. Comprometimento,
responsabilidade e comunicação nunca foram tão testados antes.
Quanto tempo leva um projeto de ERP?
Instalar o ERP não foi um processo fácil para as companhias que o fizeram. Não se
engane quando vendedores de ERP dizem que o tempo de implantação, em média, é de três
ou seis meses. As implementações que foram feitas em um curto tempo (porque seis meses é
um curto tempo), todas foram realizadas em pequenas empresas, ou foram limitadas a
pequenas áreas da empresa, ou apenas usaram as partes financeiras do programa ( no qual o
ERP é apenas um caro sistema de contabilidade). Para fazer o ERP certo, a forma como você
faz negócio terá que mudar, bem como a forma como as pessoas trabalham. E esse tipo de
mudança não acontece sem dor. A não ser que a maneira como você negocia esteja indo
extremamente bem, pedidos são embarcados no período certo, a sua produtividade é maior do
que a dos seus concorrentes, seus clientes estão completamente satisfeitos, sendo que,
nesses casos, não há nenhuma razão para pensar em instalar o ERP.
O importante é não focar-se no tempo que levará a sua implantação, já que
transformações reais com o ERP normalmente levam entre um e três anos em média, mas sim
entender porque você precisa dele e como você pode utilizá-lo para aumentar seus negócios.
Como o ERP melhorará os meus negócios?
Há três razões principais pelas quais firmas adotam o ERP:
- Para integrar dados financeiros: Como o CEO tenta entender a performance geral da
companhia, ele ou ela podem encontrar diferentes versões da verdade. O financeiro tem os seus
números, vendas tem outra versão, e as diferentes unidades podem, cada uma, ter a sua própria
versão do quanto eles podem contribuir para a receita. O ERP cria uma única versão da verdade
que não pode ser questionada porque todos estão usando o mesmo sistema.
Automação II Relton Alves da Silva

- Para uniformizar o processo de manufatura: Empresas de manufatura, especialmente aquelas


com um grande apetite por fusões e aquisições, geralmente descobrem que diferentes unidades da
empresa usam diferentes métodos e sistemas de computador. Uniformizar esses processos,
usando um único e integrado sistema de computador, pode economizar tempo, aumentar a
produtividade e reduzir gastos.

- Para uniformizar as informações de RH: Principalmente em firmas com múltiplas unidades de


negócio, o departamento de Recursos Humanos talvez não tenha um único e simples método para
acompanhar o tempo dos empregados e comunicá-los sobre seus benefícios e serviços. O ERP
pode fazer isso.

O ERP irá se adequar ao meu jeito de negociar?


É difícil para as empresas entenderem se a forma delas negociarem se adapta ao padrão
ERP antes de todos os cheques de pagamento terem sido assinados e a implementação ter
começado. A razão mais comum pela qual as empresas fogem dos projetos multimilionários do
ERP é porque elas descobrem que o software não suporta algum dos importantes processos
dos seus negócios. Nesse momento, só há duas coisas a serem feitas: mudar o processo para
se adaptar ao software, o qual significará mudanças profundas nas formas de se fazer negócio,
o que apesar de ser positivo para a produtividade da empresa, mexe em papéis de pessoas
importantes e com responsabilidades e que apenas poucas empresas têm coragem para fazer.
Ou, mudar o software para que este se adapte ao processo, o que diminuirá a velocidade do
projeto e provavelmente deturpará o sistema.
Não é necessário dizer que a mudança para o ERP é um projeto que necessita fôlego.
Além de orçar pelo custo do software, executivos financeiros devem planejar o preço da
consultoria, as adaptações, testes de integração e uma longa lista de outros gastos antes que
os benefícios do ERP comecem aparecer.
Quando receberei o retorno do ERP - e de quanto será este retorno?
Não espere revolucionar seus negócios com o ERP. A implantação dele requer uma
reorganização na forma como as coisas funcionam mais internamente na sua empresa do que
externamente com clientes, fornecedores ou parceiros. Mas, para quem tem paciência, esse é
um projeto com retorno garantido. Um estudo feito em 63 empresas que adotaram o sistema
descobriu que os benefícios costumam aparecer em média oito meses depois da instalação do
novo sistema, ou seja, em 31 meses. Após esse período, a média de economia anual com o
sistema ERP é em torno de U$1.6 milhões.

O custo escondido do ERP


Embora diferentes empresas encontrem diferentes problemas durante o orçamento,
aqueles que implantaram o ERP concordam que certos custos são normalmente maiores que
outros. A partir das experiências estudadas, pode-se dizer que os gastos mais significativos
ocorrem nas áreas: de treinamento, integração e teste; de conversão e análise de dados;
consultorias, na substituição de pessoal - com a constante implementação; e, também, com a
depressão "pós-ERP".
De qualquer forma, os benefícios que podem ser obtidos se a empresa tiver maturidade
para aceitar as mudanças e se adequar a elas, são bem maiores que as desvantagens. O ERP
é um avanço que com certeza agrega valor a uma empresa.
Automação II Relton Alves da Silva

Sistemas de Tempo Real


Introdução
O avanço tecnológico das últimas décadas colocou de forma definitiva os
computadores no cotidiano da vida moderna, seja num sistema bancário, de transporte, de
saúde, de comunicação, de manufatura, entre tantos outros. Se de um lado tal inserção
traz inúmeros benefícios às nossas vidas, de outro coloca novos desafios tecnológicos
para a construção de sistemas computacionais cada vez mais confiáveis e seguros, sem
os quais prejuízos e desastres tornar-se-ão inevitáveis.
Os sistemas de tempo-real são um caso especial de sistemas computacionais em
que o computador interage diretamente com o ambiente, não somente por meio de uma
interface homem-máquina (e.g., vídeo e teclado), mas sobretudo através de dispositivos
Automação II Relton Alves da Silva

que captam informações e que interferem no ambiente, chamados de sensores e


atuadores,respectivamente. Exemplos desses sistemas vão desde simples fornos de
microondas até sistemas de controle automático de vôo. Nesse sentido, o termo
previsibilidade que acompanha o título deste curso refere-se à capacidade do sistema em
executar ações desejadas (usualmente, através dos atuadores) dentro de intervalos de
tempos determinados a priori e, via de regra, ditados pelo próprio ambiente no qual o
sistema computacional está imerso. Por exemplo, o controle de pouso de um avião tem
que acionar o trem de pouso tão logo seja detectada a proximidade do solo através de um
sensor de altitude.A possibilidade dos vários componentes de um sistema de tempo-real
estarem distribuídos em diferentes computadores e se comunicarem para a realização de
tarefas,coloca dificuldade adicional na garantia da previsibilidade, uma vez que o mau
funcionamento de um simples componente ou do meio de comunicação pode causar
violação de prazos ou mesmo a interrupção total do serviço.
Dentro desse contexto, pode-se definir um sistema como previsível se o seu
comportamento (funcional e temporal) pode ser de algum modo antecipado ou previsto. O
comportamento funcional refere-se ao resultado de uma computação, como o acionamento
o trem de pouso do exemplo citado. Já o comportamento temporal refere-se ao instante em
que determinada ação é produzida (observe que o trem de pouso tem que ser acionado
antes da aterrissagem). Para que o sistema funcione de forma previsível é necessário, em
primeiro lugar, que haja um gerenciamento adequado dos recursos disponíveis a fim de
que ações de tempo-real não sofram atrasos imprevistos, por exemplo, devido à
indisponibilidade de memória, CPU, banda passante na rede de comunicação ou mesmo a
execução simultânea de diferentes tarefas (acionadas a partir de estímulos diversos do
ambiente).
Havendo a garantia de que os recursos necessários para a execução do sistema
estão disponíveis, o único impedimento que pode suceder é a ocorrência de defeitos nos
componentes, sejam eles no software ou no hardware. De fato, uma das poucas certezas
que existe na área de computação é sobre a impossibilidade de se construir sistemas
totalmente imunes à defeitos, ou seja, totalmente previsíveis. O que pode ser feito,
entretanto,é minimizar a ocorrência desses defeitos através de mecanismos e técnicas
diversas. Por exemplo, existem técnicas que diminuem a possibilidade de se introduzir
falhas já na etapa de especificação do sistema (e.g., especificação e verificação formal do
software e hardware dos componentes). Outras técnicas introduzem robustez no sistema
de tal forma que falhas, mesmo que ocorram em tempo de execução, podem ser toleradas
sem comprometer a previsibilidade (e.g., replicação de componentes do sistema). Vale
ressaltar que o esforço e recursos depreendidos para se verificar e colocar redundância no
sistema deve estar diretamente relacionado ao custo advindo da violação de sua
previsibilidade. Os sistemas de segurança críticos, como controle de plantas nucleares e
de vôo de aeronaves tripuladas, requerem uma previsibilidade próxima de 100 por cento.
Por outro lado, ações de sistemas convencionais (fora do escopo de tempo-real), como,
por exemplo, consultas num cadastro de uma empresa, podem ser realizadas num
intervalo de tempo muito menos rígido. Sendo assim, não há a necessidade de se garantir
a previsibilidade em tais sistemas, apesar de ser imprescindível que sua correção (e.g., o
cadastro deve sempre estar consistente) seja assegurada.

Conceitos Básicos de Sistemas de Tempo-Real

Alguns conceitos básicos sobre o tema abordado nesse curso serão aqui
apresentados. Isto inlcui uma discussão informal sobre tempo e previsibilidade,
caracterização de sistemas de tempo-real e considerações sobre a ocorrência de falhas
em tais sistemas. Os conceitos apresentados ao longo do capítulo serão ilustrados através
de uma aplicação-exemplo,que será descrita ao final desta seção. Obviamente, não é a
intenção aqui detalhar um sistema real e sim apresentar, de forma simplificada, um sistema
que seja suficientemente representativo aos propósitos do curso. A finalidade é usar um
Automação II Relton Alves da Silva

exemplo único ao longo do curso, de tal forma que os diferentes conceitos apresentados
possam ser integrados,facilitando assim a assimilação dos mesmos por parte do leitor.

Tempo e Previsibilidade

Aplicações de tempo-real precisam expressar seus requisitos em função do tempo,


o que inclui momentos para disparar determinados eventos, determinação dos momentos
em que eventos ocorreram, medir a duração de operações, ordenar temporalmente
mensagens recebidas etc. Portanto, é imprescindível a existência de uma referência de
tempo comum para todos os elementos envolvidos na consecução das tarefas e isso exige
a implementação de um sistema de relógios sincronizados entre si (sincronização interna)
e em relação a uma referência externa (sincronização externa). A sincronização interna é
sufi-ciente se os requisitos das aplicações envolvem apenas medidas de duração de
operações.Contudo, se as medidas precisam ser relacionadas às horas do dia, então a
sincronização externa precisa ser realizada.
Para se realizar a sincronização dos relógios existem algumas dificuldades
inerentes aos sistemas físicos. Isoladamente, em cada computador, um relógio é
implementado a partir de um contador que recebe estímulos periódicos de um oscilador
(e.g., quartzo).
Uma dificuldade inicial é que tais osciladores não são perfeitos, gerando um desvio
durante determinados períodos que exigem calibrações periódicas dos relógios. Num
sistema de tempo-real distribuído, que envolve vários relógios de vários computadores, difi-
culdades adicionais surgem devido aos tempos de propagação das mensagens, sendo que
todos os relógios distribuídos precisam ser re-sincronizados periodicamente. Além dessas
dificuldades, os relógios ou processos (tarefas) que os controlam podem falhar, gerando
incertezas. Todas essas limitações implicam em relógios onde se pode atingir, dependendo
das características físicas dos osciladores, computadores e redes de comunicação, uma
dada precisão (precision), que define a diferença máxima entre medidas de relógios
distintos, exatidão (accuracy) que define a diferença máxima entre um relógio e uma
referência externa, e, finalmente, granularidade, que define a duração de uma batida do
relógio (que, por sua vez, representa um número múltiplo de batidas no relógio individual).
O problema de sincronização de relógio foi bastante estudado, havendo vários
algoritmos que atendem aos variados requisitos das aplicações de tempo-real [53, 67, 66,
82].
Neste curso, quando nos referirmos ao tempo, assumiremos a existência de um
sistema de relógios devidamente sincronizados com a precisão, exatidão e granularidade
requeridas pelas aplicações em discussão, e por questões didáticas, omitiremos os
detalhes de granularidade na referência aos momentos de tempo expressos.
Como a especificação de sistemas de tempo-real envolve aspectos temporais,
resultados corretos em tais sistemas significam valores corretos produzidos nos momentos
corretos. Obviamente, o momento correto depende da aplicação e/ou do contexto que ela
está inserida. Por exemplo, suponha que o tempo de transmissão de um sinal de rádio da
Terra para Júpiter é de uma hora. Então, qualquer comando enviado para uma nave
orbitando Júpiter não pode levar menos do que uma hora para ser executado. Esse tempo
de espera, contudo, é inaceitável para um usuário de uma empresa de telefonia. Portanto,
uma aplicação que precise de uma hora para realizar conexões telefonicas será facilmente
considerada incorreta, mesmo se, ao final, as conexões sejam feitas com sucesso. A
seguir introduziremos outros aspectos de projetos relacionados à garantia de
previsibilidade de sistemas de tempo-real. Esses conceitos serão aprofundados nas
seções que seguirão.

Tarefas de Tempo-real e seus Atributos

Um sistema computacional de tempo-real típico controla ou monitora elementos do


mundo real (também denominado de ambiente), representados pelos sensores, atuadores
Automação II Relton Alves da Silva

e operadores do sistema. O sistema computacional de tempo-real deve reagir a eventos


oriundos das entidades que pertencem ao ambiente, como mudança na temperatura de um
forno, comandos do operador (através da interface homem-máquina) ou, até mesmo, a
própria passagem do tempo [50]. Eventos que são relevantes ao sistema são mapeados de
forma que eles gerem estímulos (e.g., sinais eletrônicos) para processamento pelo sistema
computacional. Por exemplo, a temperatura atmosférica pode ser irrelevante para
determinado sistema, mas a temperatura de um forno que está sendo controlado deve ser
considerada relevante, e, portanto, percebida pelo sistema computacional. Para
tanto,existem interfaces (e.g., sensores, conversores de sinal) entre o sistema
computacional e o ambiente, responsáveis por mapear os eventos relevantes ao sistema
em estímulos que ativam sua computação - geralmente estruturada em um conjunto de
tarefas. Portanto, uma tarefa pode ser informalmente definida como uma seqüência de
ações executadas pelo sistema, e acionada pela ocorrência de eventos do ambiente.
Como outro exemplo, considere a temperatura de uma caldeira que passou de seu limite
operacional. A interface da caldeira, representada por um sensor de temperatura, faz
chegar ao sistema computacional essa informação (evento) e, a partir daí, uma ou mais
tarefas corretivas são ativadas. Cada uma dessas tarefas, por sua vez, ativa outras tarefas
ou responde ao ambiente através da interface (e.g., atuadores, válvulas) para que haja a
devida resposta ao aumento de temperatura.
Neste capítulo, um determinado sistema ou aplicação será representado por um
conjunto de n tarefas _ = f_1; _2; :::_ng. Cada uma dessas tarefas é descrita em termos de
atributos. Alguns dos atributos mais comumente usados são [22, 23, 50, 34]:_ Deadline. As
especificações temporais de um sistema de tempo-real são, na maioria das vezes,
expressas em função do intervalo máximo de tempo que cada uma das suas tarefas deve
executar. Esse intervalo de tempo é relativo ao início da execução da tarefa e é conhecido
como deadline. Para cada tarefa _i, seu deadline relativo será representado por Di.
Existem algumas tarefas que não podem violar seus deadlines, pois gerariam
resultados incorretos. Essas tarefas são consideradas de tempo-real rígido (hard real-time).
Se essas tarefas de deadline rígido estão associadas a serviços críticos, que envolvem
vidas humanas ou grandes quantidades de recursos financeiros, então são chamadas de
tarefas críticas. Sistemas que possuem algum serviço composto de uma ou mais tarefas
críticas são chamados de sistemas de tempo-real críticos (safety-critical systems).
Sistemas críticos, como controle de vôo, controle ambiental etc., devem possuir alto nível
de previsibilidade. Quando não há tarefas com deadline rígido no sistema, ele é conhecido
como sistema de tempo-real brando (soft real-time systems). Descumprir deadlines nesse
caso é aceitável em termos de custos para a aplicação ou para o usuário, embora não seja
desejável. Sistemas multimídia são exemplos de tais sistemas._ Período. Este atributo,
representado aqui por Ti para cada tarefa _i, diz respeito às ativações das tarefas no
sistema. Se há um período de ativação da tarefa conhecido,a tarefa é dita periódica.
Algumas tarefas são ditas esporádicas. Para essas, geralmente, o período significa o
mínimo tempo entre duas ativações consecutivas
Quando nada se sabe sobre as ativações de uma tarefa, diz-se que ela é
aperiódica. _ Jitter. Esse atributo representa a variação máxima de duas ativações
consecutivas que uma tarefa periódica ou esporádica pode apresentar. Por exemplo, se
uma tarefa periódica _i possui jitter Ji = 0, então ela é ativada no sistema a cada Ti
unidades de tempo. Considerar esse atributo é importante, dado que variações no intervalo
entre ativações de uma tarefa pode afetar o comportamento temporal do sistema.
_ Tempo máximo de execução. Esse atributo representa o tempo de execução da
tarefa no pior caso, considerando uma dada arquitetura. Essa informação é
fundamental para prever o comportamento temporal do sistema (e.g., todas as tarefas
terminam antes de seus deadlines?). Esse tempo é derivado por técnicas especiais [76]
que levam em consideração detalhes do sistema computacional (hardware e software)
onde as tarefas serão executadas. Representa-se por Ci o tempo máximo de execução da
tarefa _i. Dado que os atributos acima são conhecidos, os desenvolvedores do sistema
devem decidir como as tarefas serão ativadas no sistema. Há duas abordagens
conhecidas. A primeira consiste em ativar as tarefas tão logo os eventos a elas associados
Automação II Relton Alves da Silva

sejam percebidos pelo sistema [19]. Nesse caso, diz-se que a ativação das tarefas é
baseada em ou orientada à eventos (event-triggered). A segunda alternativa é fazer com
que as tarefas sejam ativadas em instantes pré-determinados (time-triggered), ou seja,
suas ativações ocorrerão em momentos específicos no tempo. Para comparar ambas as
abordagens, suponha que uma tarefa está associada ao evento "temperatura da fornalha
maior que 1.000 graus".
Na primeira abordagem, tal tarefa será ativada tão logo o sistema computacional
perceba o evento através da sua interface. Na segunda, contudo, o sistema somente
acionará a tarefa em um momento pré-definido, independente da ocorrência do evento. Há
uma discussão na comunidade científica a respeito de qual abordagem é a mais
apropriada.
Argüi-se que a primeira é mais flexível enquanto que a segunda favorece à
previsibilidade em detrimento da flexibilidade. Como será visto ao longo do texto, essa
argumentação não deveria focalizar somente esses extremos. De fato, há várias situações
onde é possível garantir previsibilidade com um grau de flexibilidade razoável.
Como visto, um sistema de tempo-real é constituído por um conjunto de
tarefas,que possuem requisitos temporais próprios. Suponha, por exemplo, que devido ao
aumento repentino da temperatura de uma fornalha, uma determinada tarefa seja ativada.
Essa tarefa pode, em princípio, usar recursos computacionais necessários para a
execução de outras tarefas, podendo assim causar a violação de algum deadline. Tal
cenário deve ser evitado através de técnicas e mecanismos que forneçam o gerenciamento
adequado dos recursos do sistema. Um dos problemas principais que surge nesse
gerenciamento é o escalonamento de tarefas, o qual sofre influência de vários fatores, tais
como relações de precedência entre as tarefas, suas interações etc. A Seção 3.6 tratará
desse problema.

Obstáculos à Previsibilidade
Quando uma ação computacional se desvia do que foi especificado ou esperado, o
sistema se mostra defeituoso. Um defeito é assim a externalização de um erro. Erros,
definidos como estados incorretos do sistema, por sua vez, são causados por falhas [57].1
Um defeito ocorre na dimensão funcional se o sistema produz resultados (valores)
fora de sua especificação. Na dimensão temporal um sistema pode produzir resultados
antecipadamente ou em atraso. Se algum resultado nunca é produzido, diz-se que o
sistema apresenta defeitos por omissão. Esse tipo de defeito pode ser considerado
pertencente tanto à dimensão funcional (resultados nulos são produzidos) quanto à
temporal (o sistema está infinitamente atrasado). Omissões persistentes são chamadas de
defeitos tipo crash. O tipo mais genérico de defeito que um sistema pode apresentar é
chamado de bizantino ou arbitrário. Nesse caso, o sistema pode apresentar
comportamento completamente imprevisível em ambas as dimensões.
Construir um sistema de tempo-real 100% previsível é, portanto, evitar seus
possíveis defeitos. Como é impossível construir-se tal sistema perfeito, na prática, busca-
se minimizar a probabilidade da ocorrência de defeitos, tanto funcionais quanto temporais.
Isso pode ser feito através de diversas técnicas complementares, seja durante a
especifi-cação do sistema, da sua programação ou através da implementação de
mecanismos que,em tempo de execução, aumentam a confiança no funcionamento do
sistema.
Erros durante a fase de concepção do sistema tendem a se propagar durante sua
construção ou implementação e execução. Deseja-se, portanto, detectar tais erros antes
mesmo do sistema ser construído. Algumas técnicas, tais como prototipação e
testes,auxiliam nessa tarefa. No caso de sistemas de tempo-real críticos, contudo, apenas
essa abordagem não é o bastante. Outra alternativa é o uso de ferramentas baseadas em
formalismos através das quais os comportamentos funcional e temporal do sistema
possam ser provados. Só então é possível certificar-se de que a especificação do sistema
está correta de acordo com critérios de correção identificados. Na seção 3.3, uma das
ferramentas usadas para esse fim será brevemente descrita.
Automação II Relton Alves da Silva

Mesmo que a especificação, programação, implementação e o gerenciamento dos


recursos estejam corretos, o sistema pode ainda apresentar comportamento
imprevisível.Por exemplo, se uma tarefa no sistema apresenta algum defeito na sua
execução devido ao mau funcionamento do hardware causado, por exemplo, por
interferência eletromagnética , nem seu comportamento temporal nem o funcional podem
ser mais assegurados.Existem várias técnicas que lidam com esse tipo de possibilidade
[57], visando assegurar a confiança no funcionamento do sistema (dependability), mesmo
na ocorrência de defeitos. Como será visto, elas estão baseadas em prover um nível
adequado de redundância no sistema de tal forma que a falha seja mascarada (e.g.,
através de uma réplica da tarefa) ou o sistema seja recuperado (e.g., outra tarefa é ativada
com tal objetivo). Nesse sentido, sistemas distribuídos são uma maneira natural de
conceber redundância na computação do sistema.

Suporte ao Desenvolvimento

Dado que a especificação do sistema esteja correta e todos os mecanismos não


funcionais (e.g., confiabilidade) devidamente planejados, o próximo passo é a utilização de
ferramentas de desenvolvimento que forneçam abstrações adequadas aos
desenvolvedores do 1Essa nomenclatura, apresentada por Laprie [57], é a mais
comunmente aceita pela comunidade cientí-fica. Neste texto, os termos defeitos e falhas
foram traduzidos do inglês failure e faults, respectivamente.sistema. Em particular, tais
ferramentas devem ser capazes de expressar os requisitos temporais, além dos funcionais
presentes em aplicações convencionais.Encaixa-se nessa categoria de ferramenta, as
linguagens de programação e as arquiteturas de middleware. As linguagens são
responsáveis por fornecer a devida interface para o desenvolvedor de sistemas, mapeando
os seus requisitos para os ambientes de execução (por exemplo, máquina virtual,
middleware e sistema operacional). Há diversas linguagens destinadas à construção de
sistemas de tempo-real, a exemplo de Pearl e Esterel.
Já o middleware fornece um nível de abstração intermediário entre o ambiente de
execução e a aplicação, “escondendo” do desenvolvedor da aplicação detalhes do
ambiente,como de localização de serviços, heterogeneidade de plataformas usadas etc. As
seções 3.4 e 3.5 abordam, respectivamente, linguagens de programação e
middleware,enfatizando aspectos relacionados com previsibilidade.

Exemplo Ilustrativo
Essa seção apresenta uma aplicação ilustrativa, que representa um UAV
(Unmanned Air Vehicle), o qual será utilizado durante o decorrer do texto. Os dados e a
modelagem usados são fictícios e têm o propósito didático.
Um UAV é um veículo aéreo não tripulado que realiza atividades através de
controle autônomo ou remoto. Esta categoria de aeronave vem sendo cada vez mais
utilizada,tanto em aplicações civis (mapeamento de regiões, estudos climáticos etc.)
quanto em aplicações militares (coleta de informações sobre forças inimigas e suas
instalações, reconhecimento de armas químicas e biológicas, lançamento de mísseis etc.)
[14, 41]. A figura 3.1 fornece uma ilustração de um UAV típico [93].
Figura 3.1: Ilustração de um UAV.
O tipo de UAV modelado no exemplo aqui descrito é conhecido como
préprogramado [14], pois é completamente autônomo, capaz de realizar vôos completos
entre dois pontos previamente conhecidos e reagir adequadamente em situações não
previstas sem necessidade de intervenção humana. De forma simplificada, dois sistemas
computacionais básicos fazem parte do exemplo: o Sistema de Controle de Navegação
(SCN) e o Sistema de Controle de Atitude (SCA). O primeiro é responsável por
criar/gerenciar um conjunto de metas que viabilizem a partida e a chegada ao destino. Um
exemplo de meta pode ser sobrevoar uma certa área, a certa altura, seguindo uma
determinada rota de vôo.
Automação II Relton Alves da Silva

O SCN, portanto, necessita de informações sobre a posição relativa da aeronave a


cada instante. Já o SCA interage com sensores e/ou atuadores para cumprir a meta
independentemente das perturbações externas (e.g., mudança de velocidade do vento)
que possamocorrer.
Para efeito de ilustração, o sistema SCN é composto de três tarefas (_gps, _vrf e
_ctl) enquanto que o SCA contém apenas uma tarefa (_atd). Os atributos dessas tarefas
estão descritos na tabela 3.1. A tarefa _gps é periódica e responsável pela leitura por GPS
dos dados de localização. A tarefa _vrf, também periódica, se encarraga de verificar se a
rota que está sendo feita corresponde à rota estabelecida. O procedimento de verificação
pode assim requisitar a ativação da tarefa de controle (_ctl) caso seja necessário. Quando
acionada,_ctl tem por finalidade estabelecer nova meta que deverá ser obedecida pelo
SCA. Por xemplo, _ctl pode alterar ou ajustar alguns parâmetros de definição de rota de
vôo como,por exemplo, direção e altura. Note que _ctl é esporádica e o tempo mínimo
entre duas ativações consecutivas é igual ao período de _vrf. Em outras palavras Tctl =
Tvrf, pois pode haver a necessidade de ativar _ctl a cada instância de _vrf. Os parâmetros
de definição de rota de vôo são lidos pelo sistema SCA, através da tarefa _atd. Isso
significa que a comunicação entre _ctl e _atd é aqui modelada por compartilhamento de
recursos. Com base nestes parâmetros e nas informações dos sensores do UAV, o SCA
deve ser capaz de determinar os posicionamentos adequados dos atuadores para que a
meta determinade elo SCN seja cumprida. É importante observar que, mesmo que não
haja alteração dos parâmetros de rota de vôo, pode haver a necessidade de se executar
_atd (outros eventos,tais como mudança na velocidade ou direção do vento, por exemplo,
podem requerer seu processamento). Por esse motivo, modelamos _atd como uma tarefa
periódica.

Especificação Formal

Na seção anterior, a previsibilidade foi apresentada como um conceito essencial no


projeto de sistemas de tempo-real. Uma alternativa para a garantia de previsibilidade do
comportamento dos sistemas é o uso de métodos formais. Métodos formais compõem o
conjunto de linguagens, técnicas e ferramentas baseadas em modelos matemáticos e
destinadas a fornecer um padrão rigoroso de modelagem e análise de sistemas
computacionais [25, 29]. Estes métodos podem ser utilizados na descrição do sistema e na
especificação e verificação de propriedades, ainda durante a fase de projeto, possibilitando
eventuais correções e a certificação do seu comportamento.
A verificação de modelos (model checking) é uma técnica que permite a verifi-
cação de propriedades de sistemas de modo automático [26]. Esta é uma técnica aplicável
aos sistemas computacionais que podem ser modelados por autômatos finitos ou
variações deste estilo de representação, e consiste em três passos: a representação de
uma aplicação através de um modelo A representado como um sistema de transição de
estados finitos (autômatos); a representação de uma propriedade _ em uma linguagem
lógica de especi -decação de propriedades e, finalmente, a execução de um algoritmo de
verificação que esponda a questão: “o modelo A satisfaz a propriedade _, ou seja, A j= _?”
[8]. Diversas são as variações de algoritmos de verificação implementadas nas muitas
ferramentas de verificação de modelos para sistemas de tempo-real disponíveis [39, 42,
73, 86, 96]. Esta seção apresenta uma ferramenta de verificação de modelos largamente
utilizada,chamada UPPAAL [7]. O UPPAAL é uma ferramenta para modelagem, simulação
e verificação de sistemas de tempo-real. Esta ferramenta está disponível gratuitamente
para fins não comerciais. Para a apresentação do UPPAAL, serão modeladas algumas
tarefas do exemplo do UAV definido na seção anterior.
Automação II Relton Alves da Silva

REFERÊNCIAS BIBLIOGRÁFICAS
1 - PENA, R. T., CARVALHO, N.L.; TORRES, B.S., ASSIS, R.S., CALDEIRA, F.R.,
PENNA, C.C., "Development of a Tank System for Control Studies", Preprints of the
6th IFAC Symposium on Advances in Control Education, ACE 2003, pp 241-246,
Oulu, Finland;
2 - CARVALHO, N. L. "Implementação de Sistemas de Tanques para Controle de Nível,
Vazão e Temperatura usando a Tecnologia Fieldbus". Tese de Mestrado Engenharia
Elétrica. UFMG, dezembro 1998;
3 - FUNCTION BLOCK APPLICATION PROCESS - Fieldbus Specification - Part 1-
Fieldbus Foundation - FF-94-890 Internal Review Draft 1.0, dezembro/94.
4 - FRANCO, LUCIA R.H.R. - O Modelo de Referência OSI e as Redes de Barramento de
Campo, Revista INSTEC, N.82, outubro 1994, p. 18-23.
5 - FRANCO, LUCIA R.H.R. - Escalonamento da Comunicação no Fieldbus: Garantia do
Atendimento às Exigências Temporais em Sistemas “Hard Real Time”, Anais do 30
COBISA.
6 - FRANCO, LUCIA R.H.R., et al. - Comunicação em Chão de fábrica - Solução
Fieldbus, Anais do 30 COBISA - Congresso Brasileiro da ISA/ 10 CINISA - Congresso
Internacional da ISA - ISA Show Brasil 95.
7 - FRANCO, LUCIA R.H.R. - Configurador e Escalonador da Comunicação de Dados e
Mensagens no Fieldbus, 6 pág., submetido ao XI Congresso Brasileiro de Automática a ser
realizado em setembro de 1996.
8 - LAINE, T - Modelisation D’applications Reparties pour la Configuration Automatique
d’un Bus de Terrain - 29/maio/91 - tese de doutorado da École Nationale Superieure
d’Electricité et de Mécanique de Nancy - Institut National Polytechnique de Lorraine -
França, 146 páginas.
9 - RAJA, P; NOUBIR, G - Static and Dynamic Polling Mechanisms for Fieldbus
Networks. Operating Systems Review - p. 34-45, julho/93 - Volume 27, N.3 - ACM
Press.
10 - RAJA, P.; RUIZ, L.; HERNANDEZ, J.; NOUBIR, G.; RIESE; M. - Scheduling for
Absolute Temporal Consistency, Proceedings IFIP-TC5/WG5.7 International Wokshop on
Knowledge-Based Reactive Scheduling, Athens, Greece, outubro/93.
11 - SANTORI, M. Device Descriptions: The Key to Fieldbus Interoperability, Revista
INTECH, março 1995, p. 40-3.
12 - www.fieldbus.org
13 – www.profibus.com

Você também pode gostar