sistema integrado de controlo da qualidade apoio à gestão da ...

twiki.fe.up.pt

sistema integrado de controlo da qualidade apoio à gestão da ...

SISTEMA INTEGRADO DE CONTROLO DA QUALIDADE

E

APOIO Ë GESTÌO DA PRODU‚ÌO

Alexandre Diogo*, Beatriz Pereira*, Jo‹o Cardoso**, JosŽ Mendon a**

* INESC-Porto Rua JosŽ Falc‹o, 110 4000 Porto Telef: 2008553 Fax: 2008487

**INESC-Porto/FEUP-DEEC

Sum‡rio

A presente comunica ‹o descreve um sistema de

controlo de qualidade e apoio ˆ produ ‹o desenvolvido

para o sector de fundi ‹o injectada de uma empresa

fornecedora da indœstria autom—vel. O sistema disp›e

de ferramentas para a classifica ‹o on-line da qualidade

das pe as produzidas em cada m‡quina de injec ‹o,

utilizando tŽcnicas supervisionadas de reconhecimento

de padr›es. O sistema disp›e ainda de ferramentas para

o controlo estat’stico de qualidade, monitoriza ‹o e

supervis‹o do processo e apoio ˆ gest‹o da produ ‹o.

Descreve-se a arquitectura do sistema, as suas

funcionalidades e as solu ›es adoptadas.

1. INTRODU‚ÌO

Para manter a competitividade dentro da comunidade

europeia, onde a livre circula ‹o de bens e servi os Ž j‡

um facto, Ž vital que as empresas portuguesas

disponham de um Sistema de Qualidade envolvendo

pessoal qualificado e mŽtodos e equipamentos

adequados.

A detec ‹o de defeitos apenas no fim do processo de

fabrico, ou atŽ mesmo no cliente, Ž um processo

dispendioso e incompat’vel com as exig ncias do

mercado. O controlo da qualidade tem de deixar de ser

feito no fim do processo, tal como era feito

tradicionalmente, para passar a fazer parte do pr—prio

processo produtivo. Ensaios e testes ao longo do

processo de fabrico permitem detectar falhas e efectuar

as necess‡rias correc ›es em antecipa ‹o, evitando-se a

produ ‹o de sucata e diminuindo-se os custos da n‹oqualidade.

ƒ pois imperativo o uso de ferramentas de qualidade

que permitam detectar atempadamente a produ ‹o de

defeitos e corrigir em tempo œtil as causas dessas falhas.

Este trabalho apresenta um sistema de Controlo de

Qualidade e Apoio ˆ Produ ‹o para uma indœstria

fornecedora de componentes para a indœstria autom—vel,

que foi desenvolvido no ‰mbito de um projecto

financiado pelo programa PEDIP. A sec ‹o da f‡brica

onde o sistema vai trabalhar Ž a da fundi ‹o injectada,

onde existem cerca de 20 m‡quinas de injec ‹o

instaladas.

Pretende-se monitorar o funcionamento de cada uma

destas m‡quinas e determinar on-line, i.e., em produ ‹o,

a qualidade das pe as produzidas, uma a uma, antes de

serem retiradas do molde.

Em paralelo faz-se a recolha de informa ‹o para o

controlo estat’stico de qualidade do processo e para o

apoio ˆ gest‹o da produ ‹o.

O sector industrial referido tem a particularidade de ser

alvo de exigentes inspec ›es e auditorias realizadas

pelas indœstrias clientes, nomeadamente a indœstria

autom—vel, resultando em avalia ›es peri—dicas do seu

n’vel de qualidade e numa constante compara ‹o com a

concorr ncia.

Estas exig ncias obrigam as empresas fornecedoras a

dotarem-se de sistemas sofisticados de Gest‹o da

Qualidade com capacidade de se reajustarem e

evoluirem no sentido de atingir o objectivo œltimo de

um programa de qualidade: a produ ‹o de zero defeitos.

2. ARQUITECTURA DO SISTEMA

O objectivo principal no desenvolvimento de um

sistema deste tipo Ž que a sua arquitectura permita um

crescimento modular.

Para se atingir este objectivo Ž necess‡rio definir uma

arquitectura hier‡rquica e modular de modo a permitir

desenvolvimentos independentes das v‡rias partes do

sistema, facilitando o desenvolvimento gradual da

aplica ‹o final e permitindo fazer mais facilmente

upgrades em funcionamento, de cada uma das suas

partes.

Outra caracter’stica importante da arquitectura Ž que

seja flex’vel, isto Ž, permita facilmente adaptar-se ˆ

reconfigura ‹o da planta fabril.

Finalmente, mas n‹o menos importante, deve permitir

que o sistema seja genuinamente aberto, isto Ž, que

possa ser facilmente integrado e acedido por outros

sistemas j‡ existentes ou a instalar.

A considera ‹o destes factores foram determinantes

para a defini ‹o da arquitectura do sistema.

O sistema proposto baseia-se pois numa arquitectura


hier‡rquica descentralizada e com processamento

distribu’do.

Em cada m‡quina de injec ‹o uma unidade remota com

elevada capacidade de processamento e autonomia Ž

respons‡vel pela aquisi ‹o de dados e processamento

local. Estas unidades efectuam o controlo da qualidade

on-line na linha de produ ‹o, determinando em cada

injec ‹o a conformidade da pe a/pe as produzidas. Este

controlo vai evitar que pe as n‹o conformes sigam para

fases posteriores da produ ‹o.

Estas unidades remotas, distribu’das pela planta fabril,

est‹o ligadas por uma rede industrial a uma unidade

central, constitu’da por um computador pessoal com

ambiente multitarefa. AtravŽs da rede, enviam para a

unidade central informa ‹o previamente tratada, que Ž

armazenada numa base de dados relacional. Na unidade

central correm v‡rias aplica ›es (controlo da qualidade,

produ ‹o, etc.), que v‹o aceder a esta informa ‹o a

partir da base de dados. Contudo, quando a situa ‹o o

justificar, poder‹o tambŽm aceder directamente ˆ

informa ‹o das unidades remotas atravŽs da rede.

A unidade central ou as unidades remotas podem ainda

ser acedidas por sistemas noutras sec ›es da f‡brica

atravŽs de uma liga ‹o Ethernet, podendo estes sistemas

usufruir de informa ‹o importante relativa ˆs ordens de

fabrico, n‹o conformidades, capacidade das m‡quinas,

etc.

Rede Local Ethernet

Rede Industrial Bitbus

...

Fig. 1 - Arquitectura do sistema.

Neste contexto est‡ a ser estudada a liga ‹o deste

sistema a um hierarquicamente superior, desenvolvido

no ‰mbito de um projecto europeu ESPRIT.

3. SOLU‚ÍES ADOPTADAS

A escolha cuidada do ambiente de desenvolvimento e

das ferramentas de suporte Ž vital para se atingirem as

caracter’sticas propostas aquando da defini ‹o da

arquitectura.

O uso de solu ›es standard (quer sejam standards de

facto quer sejam standards actuais ou emergentes) Ž

imperativo para se conseguir obter um sistema aberto.

Para alŽm destas preocupa ›es, outro aspecto

importante para a determina ‹o das ferramentas a

utilizar Ž a interface com o utilizador. S‹o necess‡rias

ferramentas que permitam criar uma interface com o

utilizador simples, amig‡vel e de f‡cil utiliza ‹o.

Unidades remotas

A necessidade de efectuar um controlo da qualidade on

line, pe a a pe a, sem diminuir a taxa de produ ‹o,

aliada ao facto de o algoritmo de classifica ‹o (i.e.

determina ‹o da conformidade) exigir uma grande

quantidade de informa ‹o, adquirida a uma taxa

elevada, implica a exist ncia de unidades remotas de

elevada capacidade de processamento.

Cada unidade remota est‡ associada a um n— da rede

industrial de comunica ‹o de dados e exerce as

seguintes fun ›es:

-aquisi ‹o e processamento de sinais anal—gicos

provenientes da m‡quina de injec ‹o;

-aquisi ‹o de sinais digitais inerentes ao processo de

injec ‹o;

-interface com o equipamento de produ ‹o a ela ligado;

-classifica ‹o em tempo real das pe as fabricadas em

fun ‹o da sua qualidade;

-interface homem-m‡quina para a entrada de dados

referentes ˆ produ ‹o e ˆ monitoriza ‹o local do

processo de fabrico;

-interface homem-m‡quina para a entrada de dados

referentes ˆ configura ‹o, teste e manuten ‹o da

unidade remota;

-recolha dos dados necess‡rios ˆs aplica ›es de

controlo de qualidade, produ ‹o, monitoriza ‹o, etc.,

que correm na unidade central.

Atendendo ˆ aplica ‹o em causa s‹o de real ar os

seguintes requisitos da unidade remota:

-funcionamento em condi ›es ambientais severas;

-robustez e modularidade do hardware e do software ;

-frequ ncia de amostragem dos sinais anal—gicos na

ordem da dezena de KHz;

-di‡logo "amig‡vel" com o operador;

-execu ‹o em tempo real;

-facilidade de customiza ‹o e de expans‹o;

-autonomia e possibilidade de funcionamento

independente da unidade central;

-custo reduzido.

Rede Industrial

Os par‰metros que ditaram a escolha da rede industrial

foram a possibilidade de processamento

descentralizado, a fiabilidade em ambientes industriais,

as satisfat—rias taxas de transfer ncia, o baixo custo e o

conhecimento dos seus detalhes de implementa ‹o, de

modo a permitir um desenvolvimento espec’fico; n‹o

menos importante, a rede deveria ser um standard de

facto. A escolha recaiu sobre a rede BitBus,

principalmente pelo facto de a sua especifica ‹o ser do

conhecimento pœblico e pelo seu baixo custo.

O software de comunica ›es entre a unidade central e as

unidades remotas, estando embebido no nœcleo do

sistema operativo da unidade central, permite a qualquer

aplica ‹o da unidade central aceder concorrentemente a

uma ou mais unidade remota, ou ainda a qualquer outro

dispositivo que se encontre na rede.

Unidade central

A defini ‹o da arquitectura obrigava, para a unidade

central, a um sistema operativo multitarefa, aberto,

suportado por v‡rios fabricantes de software e

hardware. A escolha recaiu sobre UNIX, em particular

sobre a sua variante XENIX pelo seu menor custo,

menor exig ncia de capacidade de CPU, e garantias de


compatibilidade com UNIX.

Para a base de dados foi escolhido o Sistema de Gest‹o

de Base de Dados Informix dado ser um SGBD de

baixo custo, ser f‡cil de administrar, n‹o necessitar de

grandes recursos de hardware e apresentar um

desempenho razo‡vel em sistemas com pequenos

requisitos de transac ‹o[4].

A interface com o utilizador, quer na unidade central

quer nas unidades remotas, mereceu especial aten ‹o,

dado que Ž respons‡vel pela comunica ‹o entre o

utilizador e a aplica ‹o, dependendo em grande parte o

sucesso de uma aplica ‹o da forma como esta interface

Ž concebida. Deve ser simples, amig‡vel e projectada de

forma a minimizar o esfor o de aprendizagem por parte

do utilizador, dando-lhe sempre que poss’vel toda a

informa ‹o de que necessita para executar uma

opera ‹o, de modo a tornar a sua utiliza ‹o intuitiva.

Tendo em considera ‹o estes aspectos, a interface com

o utilizador na unidade central foi desenvolvida em

ambiente X Windows / OSF Motif por ser o que melhor

preenchia os requisitos colocados, devido ˆs suas bem

conhecidas potencialidades: permitir criar uma interface

amig‡vel com o utilizador, com janelas, menus pulldown

’cones, etc. Finalmente, deve real ar-se que o X

Windows est‡ a tornar-se um standard apoiado por

v‡rias organiza ›es internacionais e suportado por

v‡rios fabricantes.

REDE

aplic

aplic

BD

aplic

X

aplic

UNIX

Fig. 2.- Arquitectura do software da unidade central.

A necessidade de ter um sistema altamente modular

determinou a filosofia adoptada para o software da

unidade central. Deste modo, em vez de se ter

desenvolvido um pacote de software com um conjunto

de fun ›es bem definidas e dificilmente alter‡veis, foi

desenvolvida uma aplica ‹o que vai permitir todas as

funcionalidades necess‡rias, e outras que no futuro se

poder‹o a vir integrar, como processos UNIX

independentes. Esta aplica ‹o tem como fun ‹o

principal e œnica gerir as v‡rias aplica ›es que correm

na unidade e passar-lhes os argumentos necess‡rios. O

modo como foi elaborada esta aplica ‹o integradora

permite acrescentar funcionalidades (aplica ›es) ao

sistema de um modo muito simples. Basta desenvolver a

aplica ‹o e adicion‡-la a um ficheiro de configura ‹o,

configurando o modo como se pretende que seja

evocado. Esta filosofia vai permitir o desenvolvimento

posterior de m—dulos distintos de software e a f‡cil

altera ‹o dos processos existentes.

De notar que apesar de serem independentes, garantiuse

a integra ‹o das v‡rias aplica ›es, quer atravŽs da

base de dados, quer atravŽs de um processo simples e

eficiente de comunica ‹o directa entre as aplica ›es,

utilizando-se as facilidades do X Windows.

4. UNIDADES REMOTAS

A utiliza ‹o de uma carta de CPU baseada no

microprocessador 68000 e contendo circuitos

perifŽricos capazes de gerar interrup ›es ao

processador, permitiu criar nas unidades remotas uma

estrutura baseada em tarefas concorrentes e

hierarquizada. Confere-se assim ˆ unidade remota

elevada efici ncia no desempenho das tarefas e na

utiliza ‹o do tempo de CPU, caracter’sticas essenciais ˆ

execu ‹o de tarefas onde se colocam exig ncias de

tempo real.

Infraestrutura de Hardware

A infraestrutura de hardware das unidades remotas Ž

um sistema O.E.M. que, para alŽm de apresentar uma

—ptima rela ‹o custo/desempenho, constitui ainda uma

solu ‹o com garantias de estabilidade tecnol—gica,

facilidade de customiza ‹o e de expans‹o e obedece ao

conceito de sistemas abertos. Cada unidade remota Ž

constitu’da por um rack industrial que aloja um

conjunto de cartas electr—nicas de elevado desempenho

e fiabilidade: carta de CPU de 16/32 bits a 16 MHz,

carta de entradas anal—gicas de 12 bits com uma taxa de

aquisi ‹o de 30000 amostras/s, carta de entradas/sa’das

digitais com isolamento galv‰nico e carta de interface ˆ

rede industrial com o mesmo tipo de isolamento. Estas

cartas est‹o interligadas por um barramento G-64, um

standard de facto para aplica ›es em ambientes

industriais.

Fun ›es de apoio ˆs aplica ›es

Das fun ›es de apoio existentes podemos destacar:

-inicializa ‹o, configura ‹o e teste de funcionalidade do

hardware;

-detec ‹o e recupera ‹o de erros;

-configura ‹o din‰mica dos par‰metros dos portos de

comunica ‹o sŽrie;

-leitura e escrita formatada de informa ‹o;

-configura ‹o din‰mica dos par‰metros de aquisi ‹o

relativos ˆ carta de entradas anal—gicas, e apoio ˆ sua

calibra ‹o.

-acerto do rel—gio de tempo real, remota e localmente;

-comunica ‹o da unidade remota com a unidade central

da rede de comunica ›es;

-recupera ‹o dos dados existentes na unidade remota

em caso de falhas intempestivas na alimenta ‹o do

sistema;

-calibra ‹o de transdutores;

-parametriza ‹o do classificador.

Interface com o operador

Um dos requisitos a que obedece a unidade remota


consiste no estabelecimento de uma interface homemm‡quina,

por forma a ser utilizada por um operador sem

experi ncia no dom’nio da inform‡tica. Assim optou-se

por desenvolver uma interface utilizando um teclado

matricial e um terminal de computador, no qual s‹o

apresentados Žcrans orientados por menus. Estes cont m

listas de comandos e de informa ›es relativas aos

diferentes estados de funcionamento da m‡quina e

alarmes, assim como par‰metros de configura ‹o

relacionados com os processos de controlo da

qualidade, controlo da produ ‹o e monitoriza ‹o do

processo produtivo. Foi ainda desenvolvido uma

interface gr‡fica que possibilita a observa ‹o das curvas

que traduzem a evolu ‹o das grandezas adquiridas. ƒ

tambŽm disponibilizada informa ‹o quantitativa sobre a

qualidade da pe a produzida e sobre os pontos cr’ticos

relativos ao ciclo de injec ‹o. Esta informa ‹o Ž œtil na

afina ‹o da m‡quina de injec ‹o.

Monitoriza ‹o e Controlo da Produ ‹o

As fun ›es de apoio ˆ monitoriza ‹o e ao controlo da

produ ‹o registam e enviam para a unidade central o

estado do posto de trabalho, o c—digo do operador, as

opera ›es por ele efectuadas, a hora, data e dura ‹o de

execu ‹o dessas opera ›es, bem como o conteœdo de

diversos contadores que permitem o c‡lculo instant‰neo

da sua actividade hor‡ria. Registam-se tambŽm alarmes

sempre que estes ocorram, assim como as ac ›es

consequentes.

Fig.3. DFD da unidade remota.

5. CLASSIFICA‚ÌO EM TEMPO REAL

O objectivo principal deste projecto Ž o de procurar

classificar cada pe a produzida na m‡quina de injec ‹o

imediatamente ap—s o seu fabrico, mas antes de ser

colocada ˆ disposi ‹o do operador ou robot

manipulador que a extraem do interior do molde. A

pe a dever‡ ser dada como conforme ou n‹o conforme,

segundo critŽrios definidos pelo Departamento de

Qualidade da f‡brica.

Este objectivo, bastante ambicioso, foi j‡ objecto de

estudo, tendo os resultados sido encorajadores, apesar

de n‹o definitivos[8]. Segundo a opini‹o dos peritos das

tŽcnicas de injec ‹o de alta press‹o, assim como a dos

fabricantes das m‡quinas de injec ‹o, os par‰metros

relevantes para uma boa qualidade da pe a, alŽm da

qualidade da liga, s‹o a evolu ‹o da press‹o a que ela

est‡ sujeita durante a injec ‹o, manifestada atravŽs da

press‹o hidr‡ulica do pist‹o de injec ‹o, e pela evolu ‹o

da velocidade e do deslocamento do mesmo pist‹o.

Estes par‰metros variam rapidamente durante a

injec ‹o, particularmente durante um per’odo cr’tico

denominado de fase de enchimento do molde. A um

determinado molde correspondem condi ›es de

injec ‹o bastante precisas, geralmente determinadas

pelo Departamento de Constru ‹o de Moldes,

recorrendo quer a tŽcnicas emp’ricas quer a programas

de simula ‹o e/ou de CAD/CAM. H‡ por isso toda o

interesse em controlar n‹o s— a evolu ‹o da press‹o,

deslocamento e velocidade do pist‹o de injec ‹o, mas

tambŽm obter a partir deles os dados da injec ‹o que o

Departamento de Constru ‹o de Moldes considera

importantes. Outros par‰metros de funcionamento, tais

como a temperatura da liga e do molde, s‹o tambŽm

importantes, apesar de variarem mais lentamente.

TŽcnicas de reconhecimento de padr›es

Sendo o algoritmo de classifica ‹o baseado em tŽcnicas

supervisionadas de reconhecimento de padr›es, Ž

necess‡ria uma fase de aprendizagem efectuada sobre

um grande nœmero de injec ›es. Nesta fase s‹o

adquiridos pela unidade remota e enviadas para a

unidade central um conjunto de 128 vari‡veis de treino,

constitu’das pela evolu ‹o da press‹o, deslocamento e

velocidade do pist‹o de injec ‹o, condensados sob a

forma de uma Transformada R‡pida de Fourier, os

par‰metros de funcionamento, e os par‰metros de

injec ‹o. A cada pe a produzida nesta fase Ž atribu’do

um nœmero, sendo as pe as posteriormente classificadas

no Laborat—rio do Departamento de Qualidade, que

produz um relat—rio.

Correlacionam-se depois as vari‡veis de treino com o

relat—rio do Laborat—rio, procurando-se determinar um

subconjunto de vari‡veis que permita obter os mesmos

resultados a que chegou o Laborat—rio. Esse

subconjunto de vari‡veis, denominado vari‡veis

caracter’sticas, Ž enviado para a unidade remota sempre

que o molde que lhe est‡ associado a’ for instalado.

Atendendo a que o processo de selec ‹o de vari‡veis

caracter’sticas se caracteriza por um elevado peso

computacional no que respeita ao tempo de

processamento e volume de informa ‹o a manipular,

optou-se por atribuir ˆ unidade central essa fun ‹o.

Durante o funcionamento normal da m‡quina de

injectar, a unidade remota determina as vari‡veis de

treino do mesmo modo que na fase de aprendizagem e

compara-as com as vari‡veis caracter’sticas,

classificando a pe a recŽm fabricada como conforme ou

n‹o conforme, segundo as suas vari‡veis estejam

pr—ximas ou afastadas das vari‡veis caracter’sticas. O

algoritmo utilizado Ž o do tipo prot—tipo mais


pr—ximo[8].

6. REDE INDUSTRIAL

Fig. 4 - Resultados obtidos pelo classificador para duas

vari‡veis.

An‡lise de pontos cr’ticos da injec ‹o

A classifica ‹o baseada na an‡lise de pontos cr’ticos

relativos ao ciclo de injec ‹o poder‡ ser aplicada quer

isoladamente quer como complemento ˆ tŽcnica

anterior. De notar que a aplica ‹o daquela tŽcnica n‹o

permite identificar causas atribu’veis ˆ n‹o

conformidade de uma pe a, a n‹o ser que as vari‡veis

caracter’sticas seleccionadas correspondam a alguns dos

pontos cr’ticos.

Como complemento ˆ primeira tŽcnica, a an‡lise de

pontos cr’ticos mostra-se œtil quer na atribui ‹o das

causas de n‹o conformidade, quer como elemento de

decis‹o final, sempre que o resultado da classifica ‹o

n‹o seja conclusivo.

Fig. 5 - Curvas t’picas de injec ‹o com visualiza ‹o dos

pontos cr’ticos e resultado do classificador.

Como processo isolado de classifica ‹o, esta tŽcnica ,

embora ainda n‹o totalmente testada, apresenta-se com

francas possibilidades de sucesso, face aos resultados

encorajadores obtidos por simula ‹o laboratorial. AlŽm

de identificar as causas de n‹o conformidade, esta

tŽcnica caracteriza-se por um tempo de processamento

bastante inferior ˆ tŽcnica anterior.

A rede industrial Ž orientada para a troca de mensagens

curtas entre o n— mestre da rede e os n—s escravos.

Na implementa ‹o deste tipo de redes de dados, e por o

seu dom’nio de aplica ‹o ser geralmente de ‰mbito

dedicado, corre-se o risco de a tornar pouco geral,

comprometendo assim desenvolvimentos futuros; por

outro lado, n‹o Ž desej‡vel por raz›es de efic‡cia

efectuar a implementa ‹o seguindo o modelo completo

de camadas OSI.

De entre as v‡rias possibilidades[6], optou-se por

embeber o nœcleo de comunica ›es no kernel do

sistema operativo, criando um device driver genŽrico, e

permitindo assim que outros desenvolvimentos, noutros

ambientes fabris, pudessem customizar alguns dos

aspectos da rede. Este device driver, juntamente com o

firmware do microcontrolador que gere a rede,

implementa atŽ ao equivalente do "n’vel de rede" do

modelo OSI. Foi tambŽm desenvolvida especificamente

para a aplica ‹o em causa uma biblioteca de fun ›es de

acesso ˆ rede, que implementa atŽ ao equivalente do

"n’vel de sess‹o" do modelo OSI. As aplica ›es que

lidam com a rede (quer do lado da unidade central quer

do lado das unidades remotas) conhecem apenas quatro

fun ›es: abre(canal), envia(mensagem),

recebe(mensagem) e fecha(canal).

Um canal especifica uma liga ‹o virtual com os n—s da

rede, funcionando como o equivalente do portmap do

TCP/IP. Um canal constitui um ponto de encontro, um

rendez-vous, entre aplica ›es espec’ficas que desejam

comunicar estre si de uma forma predeterminada.

Aplica ›es genŽricas, que n‹o forne am servi os

especiais, n‹o necessitam de especificar um canal.

Executando abre(QUALQUER) o primeiro canal

dispon’vel Ž-lhes atribu’do. Cada aplica ‹o pode abrir

apenas um canal de cada vez, sendo o envio e recep ‹o

de mensagens ass’ncrono.

Quando a unidade remota toma a iniciativa de enviar

certo tipo de dados para a unidade central, f‡-lo num

determinado canal. A aplica ‹o da unidade central que

os trata, para os receber, deve utilizar o mesmo canal no

qual eles foram enviados, sendo o nœmero do canal do

conhecimento prŽvio de ambas as aplica ›es. A unidade

remota responde a uma mensagem sempre no mesmo

canal em que a recebeu. Garante-se assim a entrega

correcta de mensagens aos seus destinat‡rios, o que Ž

particularmente importante em situa ›es de falha na

rede, em que as mensagens ficam retidas na unidade

remota atŽ que as aplica ›es da unidade central as

recebam.

A fun ‹o das aplica ›es de interface com a rede Ž a de

manter a Base de Dados da unidade central e as

unidades remotas em sincronismo. Tendo-se

identificado quatro grandes ‡reas afins, optou-se por

criar v‡rias aplica ›es, cada uma com a sua fun ‹o

espec’fica, evitando-se deste modo um grande e pesado

processo servidor, de dif’cil manuten ‹o e adapta ‹o.

Uma das aplica ›es Ž respons‡vel por enviar a cada

unidade remota os dados de que esta necessita para

funcionar, de acordo com uma Ordem de Produ ‹o

definida e escalonada pelo Departamento de Produ ‹o.

A aplica ‹o regista, por outro lado, na Base de Dados


todas as mudan as de estado, ocorr ncias e alarmes que

se verifiquem na unidade remota. Se houver perda de

comunica ›es entre a unidade central e uma unidade

remota, esta n‹o pode iniciar nova Ordem de Produ ‹o.

Nesta situa ‹o n‹o h‡ perda da informa ‹o que

entretanto tenha sido gerada na unidade remota, pois o

software de rede guarda internamente essa informa ‹o.

Esta Ž a caracter’stica dominante das mensagens

enviadas pela unidade remota neste canal de

comunica ›es: a informa ‹o que por ele Ž enviada n‹o

deve ser perdida. O per’odo de autonomia Ž de v‡rias

horas, dependendo da quantidade de ocorr ncias

geradas, podendo chegar a um dia. As mensagens que

transitam neste canal s‹o tipicamente curtas, apesar de

frequentes.

Outra aplica ‹o Ž respons‡vel por registar na Base de

Dados todos os dados recolhidos pelas unidades remotas

durante o processo de aprendizagem. ƒ admiss’vel a

perda de comunica ›es durante um certo per’odo de

tempo, tipicamente uma hora. As mensagens que

circulam neste canal de comunica ›es s‹o de

comprimento mŽdio, e pouco frequentes.

Outra aplica ‹o Ž respons‡vel por registar na Base de

Dados os par‰metros de funcionamento da m‡quina de

injec ‹o, assim como os par‰metros da injec ‹o

propriamente dita, de acordo com uma taxa

configur‡vel na unidade central. As mensagens que

circulam neste canal s‹o tipicamente curtas mas muito

frequentes, n‹o sendo indispens‡veis.

Finalmente, outra aplica ‹o Ž respons‡vel pela recolha e

envio de curvas reais de injec ‹o de, e para as unidades

remotas. Esta aplica ‹o Ž indispens‡vel para simular no

Laborat—rio uma m‡quina de injectar e para visualizar e

registar na unidade central as curvas reais de injec ‹o de

uma determinada unidade remota O volume de

informa ‹o que transita neste canal Ž bastante grande,

mas muito pouco frequente.

7. UNIDADE CENTRAL

Na unidade central s‹o suportadas fun ›es para a

configura ‹o do funcionamento, monitoriza ‹o do

processo, controlo estat’stico do processo (SPC), apoio

ˆ produ ‹o e elabora ‹o de relat—rios de hist—ricos de

estados e de alarmes.

Configura ‹o do Funcionamento

Este m—dulo permite a configura ‹o da rede (atribui ‹o

de endere os ˆs unidades remotas, configura ‹o dos

seus transdutores, configura ‹o da planta fabril, etc.),

configura ‹o do funcionamento da unidade central (taxa

de monitoriza ‹o dos par‰metros, defini ‹o das cartas

de controlo a construir, etc.) e ainda configura ‹o de

alarmes e das acc›es a tomar em cada situa ‹o de

alarme definida.

Monitoriza ‹o

Permite a monitoriza ‹o dos par‰metros que est‹o a ser

recolhidos em cada m‡quina pelas unidades remotas, a

uma taxa definida pelo utilizador. Permite tambŽm a

visualiza ‹o da evolu ‹o dos par‰metros durante um

per’odo de tempo predeterminado. Para alŽm da

monitoriza ‹o destes par‰metros, a aplica ‹o mantŽm

sempre actualizada a informa ‹o sobre o estado actual

de funcionamento de cada uma das m‡quinas.

Controlo Estat’stico do Processo

Nesta aplica ‹o s‹o implementadas algumas das

ferramentas cl‡ssicas para o controlo estat’stico do

processo: cartas de controlo (XR, p, np, c e u), an‡lise

de histogramas e estudos de capabilidade do processo.

Objectivos

O objectivo principal da an‡lise SPC[5] Ž a

identifica ‹o atempada de problemas na produ ‹o que

poder‹o vir a resultar no fabrico de produtos

defeituosos. As ferramentas cl‡ssicas de SPC t m um

contributo importante na realiza ‹o desta tarefa.

Nas cartas de controlo os limites de ac ‹o s‹o

calculados de modo que exista apenas uma

probabilidade muito pequena de serem excedidos

estando o processo sob controlo. Deste modo se estes

limites forem excedidos, Ž necess‡rio detectar a causa e

actuar sobre o processo para o colocar novamente sob

controlo.

O objectivo deste procedimento n‹o Ž apenas fornecer

um mecanismo de decis‹o que indique quando Ž que se

deve tomar uma ac ‹o de controlo, mas sim, ao indicar

que o processo saiu de controlo, sugerir que toda a

informa ‹o ˆ volta desse per’odo seja examinada de

forma a encontrar uma causa atribu’vel, isto Ž um

evento ou ocorr ncia directamente relacionada com o

problema de qualidade detectado. S— este procedimento

permite melhorar continuamente o processo.

Este procedimento de detec ‹o de pontos fora dos

limites de controlo Ž complementado com a aplica ‹o

da Teoria dos Runs, que nos permite analisar tend ncias

e desvios no processo, mesmo que n‹o se cheguem a

verificar pontos fora dos limites de controlo.

Dado que muitas das caracter’sticas de qualidade s—

podem ser observadas como atributos, isto Ž, pela

classifica ‹o dos items em conformes ou n‹o conformes

em rela ‹o ˆs especifica ›es, para alŽm das cartas XR,

que usam informa ‹o sobre o valor mŽdio e gama do

par‰metro de qualidade escolhido, foram

implementadas tambŽm cartas p, cartas np, cartas c e

cartas u. Estas cartas, para alŽm do que j‡ se apontou,

providenciam ˆ gest‹o uma colec ‹o de informa ‹o da

hist—ria da qualidade, cujo conhecimento pode ajudar na

tomada de decis›es.

As cartas de controlo de defeitos, cartas p, usam

informa ‹o sobre a percentagem de items rejeitados de

um dado lote, por exemplo, devido a apresentarem-se

n‹o conformes em rela ‹o ˆ especifica ‹o.

As cartas de controlo de n‹o conformidades por unidade

ou item produzido, usualmente designadas por cartas c,

s‹o utilizadas apenas em situa ›es particulares, em que

se pode distinguir v‡rios tipos de n‹o conformidades

num mesmo produto, e em que o nœmero total de n‹o

conformidades por unidade Ž registado pela inspec ‹o.

Aplica ‹o

A informa ‹o recolhida nas unidades remotas, quer dos

par‰metros da m‡quina, quer da quantidade de pe as

n‹o conformes produzidas, permite a constru ‹o on-line

de cartas XR e cartas p. A frequ ncia entre amostras e o

tamanho das amostras s‹o configuradas pelo utilizador.

Quando se inicia a constru ‹o de uma carta os limites

de controlo podem ser definidos pelo utilizador, ou se j‡


tiver sido constru’da uma carta para este par‰metro

podem ser utilizados os limites calculados pela

aplica ‹o, com os valores da carta anterior. Sempre que

Ž verificada qualquer uma das situa ›es descritas

anteriormente, indicativas que o processo est‡ fora de

controlo, Ž gerado um alarme, cujo n’vel de gravidade Ž

configur‡vel.

Nesta situa ‹o a aplica ‹o sugere um conjunto de

ac ›es a serem tomadas, por ordem de prioridade.

Tal como os alarmes, estas ac ›es s‹o configuradas pelo

utilizador, e podem ser alteradas ˆ medida que o

conhecimento sobre o processo aumente.

Associado a uma carta de controlo, constroi-se um

jornal de ocorr ncias. ƒ solicitado ao operador que

registe todas as ocorr ncias que surjam durante a

recolha de uma amostra e que possam influenciar o

comportamento do processo.

Para alŽm dos registos do operador, situa ›es detectadas

pelo sistema, como por exemplo a mudan a do

operador, a avaria de um transdutor, etc. s‹o tambŽm

registadas neste jornal.

Isto permite ao utilizador ter associado a cada carta de

controlo informa ‹o importante sobre acontecimentos

na planta fabril e a forma como estes influenciam o

processo, o que pode fornecer um conhecimento

acrescido sobre o processo.

Para alŽm das cartas de controlo cl‡ssicas ser‹o ainda

implementadas cartas de valores individuais e cartas de

CuSum. Estas œltimas podem trazer alguns benef’cios

pois tem maior sensibilidade que as cartas XR,

permitindo detectar altera ›es mais pequenas.

A aplica ‹o permite ainda a constru ‹o e an‡lise de

histogramas e estudos de capabilidade do processo. Para

alŽm do c‡lculo dos ’ndices Cp e Cpk, a aplica ‹o

permite a constru ‹o de gr‡ficos da varia ‹o dos Cpk ao

longo do tempo, sendo assim poss’vel avaliar a

evolu ‹o do desempenho do processo.

Produ ‹o

Nesta aplica ‹o permite-se o lan amento de ordens de

produ ‹o e respectivo escalonamento, a defini ‹o dos

par‰metros de afina ‹o das m‡quinas, o c‡lculo da

actividade actual ou durante um determinado per’odo de

um operador ou m‡quina e obter informa ‹o actualizada

sobre o equipamento de produ ‹o (m‡quinas e moldes).

Hist—ricos

Foram definidos v‡rios estados de funcionamento e

ocorr ncias que podem surgir durante a labora ‹o.

Sempre que uma m‡quina entra em determinado estado

(funcionamento, aprendizagem, mudan a de molde,

etc.), ou se detecta determinada ocorr ncia (falta de

matŽria prima, avarias v‡rias, etc.), tal facto Ž registado

na unidade remota pelo operador e de seguida enviado

para a unidade central. Esta informa ‹o Ž guardada

durante um per’odo de tempo prŽ-estabelecido,

permitindo elaborar relat—rios de hist—ricos de estados

ou alarmes por ordem de produ ‹o ou per’odo de

produ ‹o, por operador e/ou m‡quina e/ou molde.

Acesso

De modo a impedir a m‡ utiliza ‹o da aplica ‹o por

utilizadores menos experimentados foi criado um

sistema de seguran a que permite atribuir um n’vel de

acesso para cada utilizador.

Definiram-se tr s n’veis de acesso. No primeiro n’vel o

utilizador tem apenas acesso ˆs ac ›es de

monitoriza ‹o. No segundo, o utilizador tem acesso ˆs

diferentes tarefas de entrada de dados (lan amento de

ordens de produ ‹o, etc.). No terceiro, o utilizador tem

permiss‹o m‡xima, tendo acesso a todas as fun ›es de

configura ‹o do funcionamento do sistema.

Alarmes

Os alarmes foram categorizados em tr s n’veis de

prioridade:

Cr’ticos - s‹o os alarmes de prioridade mais elevada.

S‹o apresentados usando cr vermelha e exigem a

confirma ‹o do utilizador, ficando registado o seu

nome.

N‹o-cr’ticos - s‹o monitorizados usando cr amarela,

n‹o ficando registado o nome do utilizador que fez a

confirma ‹o.

Informativos - s‹o apresentados usando cr verde ou

azul, n‹o necessitando da confirma ‹o pelo utilizador.

As condi ›es de alarme e as ac ›es a tomar s‹o

configuradas pelo utilizador.

Do mesmo modo que para os hist—ricos de estados, a

aplica ‹o de hist—ricos tambŽm elabora relat—rios dos

hist—ricos de alarmes.

Interface com o Utilizador

A interface com o utilizador, tal como j‡ foi

mencionado, foi projectada tendo em considera ‹o a

facilidade e efici ncia da sua utiliza ‹o.

Tendo em vista alcan ar os objectivos propostos na

sec ‹o 3, foram extensamente utilizadas as facilidades

gr‡ficas do OSF/Motif seguindo-se as suas linhas

directrizes.

A interac ‹o com o utilizador baseia-se na execu ‹o de

ac ›es sobre objectos. Entende-se por objectos todos os

elementos que fazem parte da planta fabril: m‡quinas,

moldes, operadores, ordens de produ ‹o, etc. Estes

objectos s‹o representados por ’cones numa janela

constru’da para o efeito, em que se pretende representar

a planta fabril com todos os elementos que a

constituem.

Quando se quer efectuar qualquer opera ‹o, que ser‡

necessariamente sobre um objecto, primeiro seleccionase

o objecto e a seguir a ac ‹o a efectuar. Por exemplo,

para monitorar os par‰metros de funcionamento da

m‡quina 206, selecciona-se na janela dos objectos o

’cone que representa a m‡quina 206, a seguir na

aplica ‹o "Monitoriza ‹o" selecciona-se a ac ‹o

"monitorar par‰metros".

Este mecanismo mantŽm-se consistente em todas as

aplica ›es.

Comunica ‹o entre processos

Com o tipo de arquitectura descrito, em que a Base de

Dados funciona como reposit—rio central da informa ‹o

dispon’vel ˆs v‡rias aplica ›es, sincronizando-as entre

si, Ž necess‡rio que estas tenham conhecimento de

altera ›es efectuadas na Base da Dados. Estas

altera ›es podem ser efectuadas assincronamente por

qualquer aplica ‹o, quer devido ˆ ac ‹o volunt‡ria do

utilizador, quer devido a altera ›es do ambiente sob

controlo ou monitoriza ‹o.

N‹o Ž eficaz que cada aplica ‹o esteja continuamente a

consultar a Base da Dados, sendo prefer’vel cada uma


manter uma imagem privada dos aspectos relevantes

para o seu funcionamento, sendo necess‡rio apenas

actualizar esta imagem ocasionalmente. Poder-se-ia

actualizar a imagem a intervalos regulares apropriados a

cada aplica ‹o, mas num ambiente ass’ncrono Ž dif’cil

faz -lo; mesmo fazendo-o, a maioria das consultas ˆ

Base de Dados seria desnecess‡ria, por n‹o terem nela

ocorrido modifica ›es.

A œnica aplica ‹o que sabe qual a altera ‹o efectuada

na Base de Dados Ž aquela que a efectuou, e deve ser

ela a informar do facto as aplica ›es interessadas.

Assim, cada aplica ‹o deve registar-se, perante uma

entidade, como interessada em classes ou subclasses de

ocorr ncias; a aplica ‹o que regista a ocorr ncia

sinaliza ent‹o as aplica ›es interessadas no facto, e

estas actualizam a sua imagem privada.

Suponhamos que o utilizador decide monitorar, em

tempo real, a press‹o de —leo de uma determinada

m‡quina; desconhece-se, ˆ partida, qual o ritmo de

varia ‹o desse par‰metro, sobretudo se ocorrerem

varia ›es sœbitas. Claro que a unidade remota associada

a essa m‡quina particular conhece o ritmo de

amostragem correcto dessa grandeza, enviando para a

unidade central apenas as altera ›es. Na unidade

central, uma aplica ‹o especial, daemon, est‡

encarregada de registar na Base de Dados os par‰metros

lidos nas diferentes unidades remotas, e quando efectua

um registo, verifica se h‡ alguma aplica ‹o interessada,

sinalizando-a se houver. No exemplo acima, a aplica ‹o

que deseja monitorar a press‹o de —leo regista-se como

interessada nesse par‰metro de uma dada m‡quina,

sendo sinalizada pelo daemon apenas quando este

variar. Claro que o daemon tambŽm est‡ interessado em

altera ›es na Base de Dados, por exemplo o adicionar

ou retirar de uma m‡quina, registando-se como

interessado na configura ‹o da planta fabril.

Fig. 6 - DFD das comunica ›es da unidade central.

No modelo descrito, cada aplica ‹o desconhece o

ambiente em que est‡ integrada: podem ser adicionadas

aplica ›es ou ser alterada a funcionalidade de

aplica ›es existentes ou da pr—pria Base de Dados.

Na implementa ‹o actual do modelo descrito, uma

aplica ‹o pode registar-se como interessada na altera ‹o

de uma determinada tabela da Base de Dados, e em

particular numa determinada m‡quina da planta fabril.

O processo de registo Ž efectuado numa tabela da Base

de Dados, existindo para o efeito uma pequena

biblioteca de quatro fun ›es: regista, sinaliza, consulta

e de-regista. A fun ‹o sinaliza Ž utilizada pelo processo

que efectuou altera ›es na Base de Dados, sendo o

processo de sinaliza ‹o implementado atravŽs de sinais,

um mecanismo bem conhecido de UNIX. A fun ‹o

consulta Ž utilizado pela fun ‹o que Ž sinalizada, de

modo a poder obter mais detalhes sobre qual a altera ‹o

efectuada.

A implementa ‹o n‹o Ž muito eficaz, por se basear

numa tabela da Base de Dados, estrutura que se

pretendia precisamente aliviar de acessos

desnecess‡rios; verificado contudo o sucesso do

modelo, ser‡ agora simples implementar o mecanismo

atravŽs de, por exemplo, mem—ria partilhada.

8. CONCLUSÍES

Pretendeu-se com o sistema descrito dotar uma empresa

de fundi ‹o injectada com um sistema de controlo de

qualidade e apoio ˆ gest‹o da produ ‹o.

Apesar de ser uma solu ‹o customizada, este sistema

devia ser capaz de se adaptar facilmente a outras

indœstrias similares, e permitir a integra ‹o em sistemas

inform‡ticos existentes.

Estes dois objectivos tantas vezes incompat’veis, foram

plenamente atingidos com a adop ‹o de uma estrutura

modular, flexivel, e aberta, permitindo a f‡cil

redefini ‹o de funcionalidades existentes e a inclus‹o de

novas funcionalidades.

Refer ncias

[1] Allchin, Thomas. Quality Assurance with Modern

CNC Die Casting Systems. Die Casting Engineer,

pp 34-38.

[2] Allsop, D. F.; Kennedy, D. 1983. Pressure

Diecasting. The Technology of the Casting and the

Die. Vol. 1 e 2. Pergamon Press.

[3] Carneiro, L. M.; Gouveia, J. B.; Mendon a, J. M.

1990. The Use of Data Bases in SMEÕs Systems

Integration. 6th Esprit CIM-Europe Conference,

Lisboa.

[4] Carneiro, L. M.; Magalh‹es, P.C.; Rom‹o, N.;

Mendon a, J.M. 1991. Data Base Management

System Evaluation Report. Esprit Project 5478.

[5] Grant, E. L.; Leavenworth, R. S., 1988. Statistical

Quality Control. McGraw Hill.

[6] Cardoso, J. A Rede Industrial de Comunica ›es de

Dados em ambiente XENIX, trabalho de s’ntese

inserido nas provas de capacidade cient’fica, DEEC,

FEUP, 1991.

[7] Juran, J. M.; Gryna, F. M. Quality Planning and

Analisys. McGraw-Hill.

[8] NazarŽ, L. Controlo de Qualidade em Tempo Real

na linha de Produ ‹o, trabalho de s’ntese inserido


nas provas de capacidade cient’fica, DEEC, FEUP.

More magazines by this user
Similar magazines