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: diegos@ece.ufrgs.br, nagamine@if.ufrgs.br, fetter@ece.ufrgs.br

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.