automac¸ao de um˜fetter/cba2008_41754.pdf · ufrgs. originalmente, o sputtering do instituto de...
TRANSCRIPT
AUTOMACAO DE UM SPUTTERING
Diego Caberlon Santini∗, Luiz C. C. M. Nagamine†, Walter Fetter Lages∗
∗Universidade Federal do Rio Grande do SulDepartamento de Engenharia Eletrica
Av. Osvaldo Aranha, 10390035-190 Porto Alegre, RS, Brasil
†Universidade Federal do Rio Grande do SulInstituto de Fısica
Av. Bento Goncalves, 9500Porto Alegre, RS, Brasil
Emails: [email protected], [email protected], [email protected]
Abstract— A sputtering is a machine used to deposit thin films onto a surface. This paper presents a system
developed to automate a sputtering. A distributed system, including two microprocessor based controllers and
a personal computer is proposed. The hardware and software developed for the system and the communication
protocol are described. Two different interfaces are available to the end-user, the first one by using a web browser
and the other by programming in the C++ language. The class hierarchy developed to encapsulate all details of
the system and give the end-user a view very close to his problem is described in details.
Keywords— Sputtering, Real-time Control, Web interface, Java, Control via UDP, Distributed Control.
Resumo— Um sputtering e uma maquina utilizada para depositar filmes finos sobre uma superfıcie. Este
artigo apresenta o sistema desenvolvido para automacao de um sputtering. E proposto um sistema de controle
distribuıdo composto por dois controladores baseados em microcontroladores e um computador PC. Sao descritos
o hardware e o software desenvolvidos e o protocolo de comunicacao utilizado. Ao usuario final sao disponibili-
zadas duas interfaces, uma via web browser e outra atraves de programacao em C++. As hierarquias de classes
desenvolvidas para dar ao usuario uma visao do sistema bastante proxima do seu problema sao descritas em
detalhes.
Palavras-chave— Sputtering, Controle em tempo real, Interface web, Java, Controle via UDP, Controle
distribuıdo.
1 Introducao
A tecnica do magnetron sputtering (Behrisch andWittmaack, 1991; Mello, 2002) e bastante empre-gada na deposicao de filmes finos ou na fabri-cacao de materiais de microeletronica, como porexemplo memorias magneticas de acesso aleatorioe sensores de cabecotes de leitura magneto resisti-vos (Dieny et al., 1991; Tehrani et al., 2003). Estatecnica consiste em bombardear o material alvocom um feixe de ıons de gas inerte, arrancandoatomos que podem ser depositados em um subs-trato. Dois eletrodos estao presentes em uma ca-mara de deposicao, onde um deles e o alvo do ma-terial a ser depositado (potencial negativo) e o ou-tro e o substrato, que deve ser posicionado opostoao alvo e aterrado (ou mantido em potencial flu-tuante), como mostra a figura 1. O plasma podeser criado aplicando-se uma diferenca de potencialDC para a deposicao da maioria dos metais, ou deradiofrequencia, para os materiais isolantes. Esteplasma e confinado magneticamente na forma deum anel circular sobre o alvo, atraves de linhas decampo gerado por ımas colocados abaixo do alvo.
Este trabalho apresenta o sistema desenvol-vido para automatizar a camara de sputtering fa-bricada no Instituto de Fısica da Universidade Fe-deral do Rio Grande do Sul, semelhante a mos-
Figura 1: Esboco de um sputtering.
trada na figura 2 (Rodriguez, 2007). Esta camaradispoe de seis canhoes (fonte+ımas+alvo) monta-dos verticalmente e dispostos simetricamente numcırculo de aproximadamente 50cm de raio. Cadacanhao possui uma chamine e um obturador pneu-matico. Duas bandejas circulares sao posicionadassobre os canhoes e podem girar em torno de eixosindependentes centrais, sendo que a superior podeacomodar seis substratos e a inferior e dotada deuma abertura circular. A bandeja com a aberturaserve como protecao para a deposicao indesejadaem substratos adjacentes ao do substrato posici-onado diretamente sobre um dos canhoes para o
qual se deseja depositar.
Figura 2: Sputtering do Instituto de Fısica daUFRGS.
Originalmente, o sputtering do Instituto deFısica da UFRGS era acionado manualmente.Deste modo, devido a necessidade de intervencaodo operador em instantes de tempo precisos masrelativamente espacados, a operacao torna-se bas-tante tediosa e sujeita a falhas humanas.
Em sistemas comerciais (Ajaint, 2008),utiliza-se motores de passo para movimentar oeixo das bandejas em posicoes desejadas. Nestetrabalho, optou-se pela utilizacao de motores DCpara girar os eixos das bandejas, devido a maiordisponibilidade de torque, o que simplifica a mon-tagem mecanica. A leitura do posicionamento an-gular das bandejas e realizada atraves de encodersincrementais.
Este trabalho descreve a solucao adotada paraautomatizar o sputtering. As secoes 2 e 3 des-crevem o hardware e o software desenvolvidos en-quanto a secao 4 aborda os detalhes das interfacesdisponıveis para os usuarios do sistema.
2 Descricao do Hardware
A solucao adotada neste trabalho para a automa-tizacao do sputtering utiliza dois controladores eum microcomputador conectados atraves de umaintranet, conforme mostra a figura 3.
Figura 3: Rede sputtering.
O controlador 1 e responsavel por acionar a
bandeja inferior (canhao) e acionar o obturador,enquanto que o controlador 2 aciona a bandeja(substrato). Cada controlador utiliza um PIDpara controlar a posicao da sua bandeja. A re-ferencia e passada para os controladores atravesdo computador conectado a intranet.
Seis micro chaves sao posicionadas sobre a po-lia do motor DC que controla a rotacao do eixo dabandeja com a abertura. A respectiva micro chavee acionada mecanicamente quando a bandeja coma abertura posiciona-se defronte de um dos seiscanhoes. Estas sao conectadas de tal forma que osinal eletrico enviado pelo controlador acione so-mente o obturador correspondente a esse canhao.Portanto, a abertura do obturador de um especı-fico canhao so ocorre quando a abertura da ban-deja esta sobre este mesmo canhao.
Na implementacao do hardware deste traba-lho utilizou-se o modulo dsTINIm390, baseadono microcontrolador DS80C390 (Maxim/Dallas,1999). Este microcontrolador possui interfaces se-riais e CAN e varios pinos I/O para de uso gene-rico. O modulo utilizado possui alem do micro-controlador, um conjunto de memorias e perife-ricos tais como: 512kB de memoria flash, 512kBou 1MB de memoria SRAM, controlador Ether-net 10Base-T, transceiver serial RS-232 e disponi-biliza os barramentos do processador para expan-soes.
Uma placa host foi criada para receber o mo-dulo dsTINIm390. Essa placa contem os conecto-res necessarios para a comunicacao (serial e Ether-net) e faz a interface com o motor e o respectivoencoder incremental. O acionamento do motor efeito por um PWM implementado em hardware.A saıda do PWM esta conectada a uma ponte Himplementada com MOSFETs. A interface com oencoder possui um decodificador em quadratura,permitindo determinar o sentido de giro do motore multiplicando por quatro a resolucao do encoder.Adicionalmente, existe um contador bidirecionalde 16 bits que armazena a contagem de posiciona-mento do encoder. Um interruptor de sincronismoe necessario para fornecer uma referencia inicial aoencoder incremental. A figura 4 apresenta o dia-grama de blocos do conjunto completo, enquantoa figura 5 mostra uma foto da placa utilizada emcada um dos controladores.
Módulo dsTINIm390 Módulo HostFLASHEEPROM
RAM naovolátil
RTC
DS80C390 ETHERNET
CAN SERIAL
RS−232
PWM
Ponte H
AcionadorObturador
InterruptorSincronismo
Encoder deQuadratura
EncoderObturador InterruptorMotor
Barramento doProcessador
Figura 4: Diagrama da placa.
Figura 5: Placa do controlador.
3 Descricao de Software
O modulo dsTINIm390 prove um sistema opera-cional denominado TINI/OS. Este sistema opera-cional e multitarefa com suporte a gerenciamentode memoria e I/O, sistema de arquivos, uma pilhaTCP/IP e uma maquina virtual Java. Um shellsemelhante ao UNIX, baseado em Java, tambem edisponibilizado. O sistema operacional inclui ser-vidores TELNET, FTP, HTTP, um cliente DHCPe um console serial (Loomis, 2001).
A plataforma JVM e conveniente para imple-mentar tarefas de altos nıvel tais quais, servidorde web ou sensoriamento remoto. Entretanto, alinguagem Java e limitada para prover acesso debaixo nıvel, como interfaces com hardware. Essalimitacao e acentuada quando a maquina virtualJava e implementada em software. Neste caso, ta-refas que necessitam velocidade, temporizacao eprecisao tem sua implementacao dificultada.
Esses problemas sao parcialmente soluciona-dos utilizando a JNI (Liang, 1999), que permiteque o codigo Java rodando na maquina virtualchame e seja chamado por aplicacoes nativas (pro-gramas binarios especıficos de um determinadoprocessador). Assim, o acesso a todos os dispo-sitivos presentes na placa host foi implementadoem Assembly e as interfaces sao disponibilizadaspara os programas em Java como funcoes nativas.
Cada dispositivo e modelado por uma classeJava que possui metodos publicos para suportar asoperacoes possıveis, como open() e close() parao obturador e on(), off() e set(double vol-
tage) para o motor. Os objetos destas classesfazem parte de uma classe denominada AIC, e saoimplementados em um pacote Java denominadobr.ufrgs.ece.AIC, como mostrado na figura 6.
O controle da posicao do motor foi feito atra-ves de um controlador PID implementado digital-mente com um perıodo de amostragem de 20 mili-segundos. A princıpio, a linguagem Java por si sonao fornece garantias temporais para que o con-trolador seja executado no tempo adequado. Namaquina virtual Java que roda no modulo dsTI-NIm390, a temporizacao das tarefas e prejudicada
Figura 6: Hierarquia de classes do pacotebr.ufrgs.ece.AIC.
no momento em que o garbage collector e cha-mado. O garbage collector e um servico de geren-ciamento de memoria que periodicamente liberamemoria usada por objetos que ja nao sao mais ne-cessarios. Essa atividade e automatica e pode serinaceitavel para sistemas que com especificacoestemporais restritas (Kim et al., 2000), como nestecaso. A solucao para este problema foi executaro PID fora do escopo do sistema operacional, fa-zendo algo semelhante sistema RTAI-Linux (Dozioand Mantegazza, 2003), como mostra a figura 7.Basicamente a ideia consiste em instalar um tra-tador de interrupcoes que permite a execucao deum kernel de tempo-real que executa com maiorprioridade do que o sistema operacional.
Figura 7: Tarefas no processador.
Assim, o controlador PID executa direta-mente sobre a supervisao deste kernel de temporeal com uma prioridade maior que o sistema ope-racional, comunicando-se com o sistema operacio-nal em Java apenas para receber os sinais de re-ferencia. Desta forma nao e necessario disputar oescalonamento com as outras tarefas e a tempori-zacao e garantida. A desvantagem de desta solu-cao esta no fato que nao pode-se utilizar qualquerfuncao do sistema operacional neste modo, mascomo um controlador PID e simples, nao precisa-
se do sistema operacional. A referencia e passadado sistema operacional para a tarefa de tempo realutilizando a interface JNI.
Desenvolveu-se uma API para aplicacoes detempo-real. Isso foi feito atraves de uma funcaonativa que captura uma interrupcao de alta pri-oridade no processador, e instala um escalonadorpara atender a mesma. A seguir um temporizadore programado para gerar a interrupcao periodica-mente na frequencia desejada.
4 Interface com Usuario
Utilizando a base de hardware e software descri-tas nas secoes 2 e 3 e possıvel criar interfaces parao usuario final. Foram criadas duas interfaces.Uma interface atraves de uma pagina Web, ade-quada para operacoes que serao executadas manu-almente no sputtering e uma interface atraves deprogramacao em linguagem C++, adequada paraautomatizar as operacoes e para operacoes queenvolvem sequencias complexas de movimentacaodas bandejas e abertura e fechamento do obtura-dor. Obviamente, a interface via Web funcionaatraves de um servidor HTTP sobre o protocoloTCP. Ja a interface de programacao em lingua-gem C++ utiliza o protocolo UDP, como mostraa figura 8.
API C++
UDPTCP
HTTP
IP
ETHERNET
API C++
UDPTCP
HTTP
IP
ETHERNET
Controlador Computador
Figura 8: Pilha de protocolos utilizados.
4.1 Interface Web
Esta interface tem como base um operador queutiliza um PC como interface para enviar coman-dos ao sputtering atraves de um browser conven-cional, como mostra a figura 9. Para tanto, foiimplementado em cada controlador um servidorHTTP, que recebe mensagens POST e as inter-preta, passando o valor de posicao como referen-cia para a tarefa de tempo real atraves da interfaceJNI, que entao movimenta o motor, ou executa aabertura e fechamento do obturador.
Na tela aparecem tres opcoes disponıveis aousuario: resetar motor, posicionar motor e abrira obturador. O primeiro comando posiciona omotor na posicao inicial dele definida como zero,identificada pelo interruptor de sincronismo. Aseguir o comando posicionar motor pode ser utili-zado para uma das seis posicoes pre-definidas dasbandejas. O comando para abrir a obturador inici-aliza uma outra tarefa de tempo real para monitoro tempo de abertura do obturador, com precisaode 20 milisegundos.
Figura 9: Interface Web.
Cada comando do usuario atraves do browsergera um POST especıfico que e tratado por umaclasse diferente, todas implementadas em Java.Estas classes redirecionam a pagina enquanto ocomando e realizado para evitar que comandos se-jam enviados em sobreposicao, e utilizam o pacotebr.ufrgs.ece.AIC citado na secao 3 para realizara acao.
O browser e util principalmente para opera-cao manual do sputtering. Porem para a utiliza-cao tıpica do sputtering, esta solucao nao e eficaz.Isto porque a deposicao de grande parte dos tiposde filmes finos deve seguir sequencias de deposi-cao de diversos materiais com temporizacoes pre-especificadas e neste caso nao e interessante umusuario comandar manualmente o fluxo de acoes,por serem tediosas e portanto altamente propen-sas a erro. Desta forma, e desejavel que as opera-coes para cada tipo de filme fossem programadas.Para tal caso tem-se a Interface via API.
4.2 Interface via UDP
Esta interface permite automatizacao de todo oprocesso de deposicao em uma rotina que e exe-cutada automaticamente pelo sputtering. A inter-face Web nao fornece essa possibilidade uma vezque ele executa um comando de cada vez.
Aproveitando que o sistema operacional ofe-rece suporte a pilha UDP/IP, foi implementadoum servidor UDP no sputtering. Quando um cli-ente se conecta nele, ele fica realizando duas tare-fas: enviando mensagens com o seu status e espe-rando para receber um comando. Ao receber umcomando ele o executa e torna a esperar o proximocomando.
O protocolo da aplicacao para o envio de co-mandos e simples e possui o formato generico apre-sentado na figura 10.
Identificador Dados
Figura 10: Formato generico do pacote.
O primeiro byte representa o identificador do
tipo de pacote. Existem um total de quatro tiposde pacote. No sentido controlador-computador hasomente um tipo, definido com o identificar 0x20.Os dados neste pacote sao as informacoes sobreo status do controlador. A figura 11 apresenta oformato deste pacote.
Reservado
0
Ocupado
IndexPosição
7
0x20
72 73 74 103
Figura 11: Pacote de status.
Os primeiros 8 bytes de dados apresentam umvalor em IEEE-754, precisao dupla, contendo aposicao da bandeja em radianos. Os proximos 4bytes contem uma palavra de status aonde o pri-meiro bit informa se a interrupcao de referenciado encoder esta ligada ou nao e o segundo informase o controlador esta executando um comando ounao. Os demais sao reservados para futuras ex-pansoes.
No sentido computador-controlador restam ostres tipos: o identificador 0x01 representa um re-set e nao possui dados, a figura 12 demonstra opacote; o identificador 0x15 e o comando para po-sicionar o motor e contem um pacote de 8 bytescom a posicao em radianos no formato IEEE-754,precisao dupla, conforme a figura 13; o identifi-cador 0x3b identifica o comando de abrir o obtu-rador e contem 4 bytes no formato de 32 bits emcomplemento a 2 contendo o tempo de abertura domesmo em microsegundos, conforme a figura 14.
0
0x01
7
Figura 12: Pacote de reset.
0 7
Posição0x15
71
Figura 13: Pacote de posicao.
Eventualmente o controlador pode receberdois comandos pelas duas interfaces ao mesmotempo. Para evitar que ocorra algum problema,um semaforo e implementado para acessar o hard-ware do controlador, garantido assim que os co-mandos sejam executados em exclusao mutua.
4.3 API C++
Apos a implementacao da interface via API, foiimplementada uma biblioteca que facilite a mon-tagens de programas aplicacao, ou seja, o pro-grama que controlara a deposicao. Para evitarque o programador necessite de conhecimentos deprogramacao em rede montou-se entao uma classe
0 7
Tempo
39
0x3b
Figura 14: Pacote de abertura do obturador.
chamada SPUTTERING que ira representar os con-troladores no computador. A classe SPUTTERING
apresenta uma funcao para cada comando, inter-pretando cada comando no pacote correto e envi-ando atraves da pilha UDP/IP para o controlador.A figura 15 mostra a hierarquia de classes do dis-ponıveis para o usuario.
Figura 15: Hierarquia de classes do disponıveispara o usuario.
As classes que representam os dispositi-vos, AIC_ENCODER, AIC_INDEX, AIC_BRAKE eAIC_MOTOR comunicam-se com as classes equiva-lentes incluıdas no pacote br.ufrgs.ece.AIC edisponıveis no software que esta executando noscontroladores. Esta comunicacao e feita atravesdas funcoes disponıveis na classe AIC_COMM, queabstrai o canal de comunicacao. Neste trabalhoe utilizado apenas o canal de comunicacao queutiliza o protocolo UDP, mas estao disponıveisoutros canais de comunicacao, atraves do barra-mento CAN ou serial RS-232.
Os objetos que representam os dispositivos fı-sicos fazem parte da classe AIC, que abstrai o con-trolador como um todo e serve como base para aclasse AIC_UDP, que tambem e derivada da classeAIC_COMM. A classe AIC_UDP abstrai um contro-lador capaz de comunicar-se atraves do protocoloUDP.
Finalmente, a classe SPUTTERING e derivadada classe AIC_UDP, de forma encapsular os deta-lhes de inicializacao da comunicacao atraves doprotocolo UDP. Assim, o usuario final precisa sa-ber utilizar apenas a classe SPUTTERING, que pos-sui funcoes diretamente relacionadas a aplicacaode controle do sputtering, como posicionar as ban-dejas e abrir o obturador. O codigo abaixo de-monstra exemplo da programacao do sputteringdo ponto de vista do usuario:
#include <sputtering.h>
int main(int argc,char *argv[])
{
SPUTTERING gun("gun");
SPUTTERING substrate("substrate");
gun.reset();
substrate.reset();
gun.reference(10.46);
substrate.reference(10.46);
substrate.shutter(1000000);
return 0;
}
No exemplo sao declarados os dois controlado-res atraves de objetos da classe SPUTTERING, de-nominados gun e substrate. Os argumentos paraa criacao dos objetos sao os nomes dos controla-dores na intranet. Inicialmente utiliza-se a funcaoreset() para posicionar as bandejas na posicaoinicial. A seguir move-se as bandejas para a po-sicao desejada, neste caso 10.46rad com a funcaoreference() e entao o obturador e aberto por 1segundo.
Atraves do desenvolvimento de programas se-melhantes pode-se construir uma biblioteca comprogramas para os diversos tipos de filmes que po-dem ser produzidos pelo equipamento.
5 Conclusao
Apresentou-se o hardware e software de um sis-tema de automacao de um sputtering. O desen-volvimento de um sistema distribuıdo, com con-troladores baseados em microcontroladores e umPC para supervisao permitiram obter-se um sis-tema modular facilmente expansıvel e com flexi-bilidade na interface com o usuario atraves de umbrowser convencional ou atraves de programacaoem linguagem C++.
A utilizacao de microcontroladores que supor-tam um sistema operacional em Java permitiu im-plementar servidores HTTP nos proprios contro-ladores enquanto a interface JNI permitiu que ro-tinas de tempo real fossem implementadas em As-sembly.
O desenvolvimento do software do sistema emlinguagens orientadas a objeto permitiu encapsu-lar todos os detalhes de comunicacao e operacaodo hardware de forma que o usuario final tenhauma visao de programacao bastante proxima doseu problema.
Referencias
Ajaint (2008). <http://www.ajaint.com>.
Behrisch, R. and Wittmaack, K. (1991). Sput-tering by Particle Bombardment, iii edn,Springer-Verlag, USA.
Dieny, B., Speriosu, V. S., Parkin, S. S. P.,Gurney, B. A., Wilhoit, D. R. and Mauri,D. (1991). Giant magnetoresistive insoft ferromagnetic multilayers, Phys. Rev.B(43): 1297.
Dozio, L. and Mantegazza, P. (2003). Realtime distributed control systems using rtai,Object-Oriented Real-Time Distributed Com-puting, 2003. Sixth IEEE International Sym-posium.
Kim, T., Chang, N. and Shin, H. (2000). Boun-ding worst case garbage collection timefor embedded real-timesystems, Real-TimeTechnology and Applications Symposium,2000. RTAS 2000. Proceedings. Sixth IEEE,Washington, DC, USA.
Liang, S. (1999). Java Native Interface: Program-mer’s Guide and Specification, Prentice HallPTR.
Loomis, D. (2001). TINI(TM) Specificationand Developer’s Guide, The (Paperback),Addison-Wesley Professional.
Maxim/Dallas (1999). DS80C390 - Dual CANHigh Speed Microprocessor.
Mello, A. (2002). Instrumentacao para caracteri-zacao e producao de filmes finos nanoestrutu-rados, Tese de mestrado, CBPF, Rio de Ja-neiro.
Rodriguez, W. E. A. (2007). Anisotropia magne-tica e acoplamento de troca em multicama-das de metal de transicao, Tese de mestrado,CBPF, Rio de Janeiro.
Tehrani, S., Slaughter, J. M., Deherrera, M., En-gel, B. N., Rizzo, N. D., Slater, J., Dur-lan, M., Dave, R. W., Janesky, J., But-cher, B., Smith, K. and Grynhewich, G.(2003). Magnetoresistive random access me-mory using magnetic tunnel junctions, Proc.IEEE 91: 703.