PROGRAMAÇÃO E TESTE DE EFETUADOR DE FURAÇÃO E INSERÇÃO DE … · elaboração de diversas...

Anais do XVII Encontro de Iniciação Científica e Pós-Graduação do ITA – XVII ENCITA / 2011

Instituto Tecnológico de Aeronáutica, São José dos Campos, SP, Brasil, 19 de outubro de 2011

PROGRAMAÇÃO E TESTE DE EFETUADOR DE FURAÇÃO E INSERÇÃO

DE PRENDEDORES DE SISTEMA ROBÓTICO

Juliano Augusto de Bonfim Gripp Instituto Tecnológico de Aeronáutica - ITA

Rua H8-C, nº 328, Campus do CTA. CEP: 12228-462, São José dos Campos – SP - Brasil

Bolsista PIBIC-CNPq

[email protected]

Emília Villani Instituto Tecnológico de Aeronáutica – ITA (CCM)

Praça Marechal Eduardo Gomes, 50, Vila das Acácias. CEP: 12228-900, São José dos Campos – SP - Brasil

[email protected]

Carlos Eduardo Oliveira da Silva Instituto Tecnológico de Aeronáutica – ITA (CCM)

Praça Marechal Eduardo Gomes, 50, Vila das Acácias. CEP: 12228-900, São José dos Campos – SP - Brasil

[email protected]

Resumo. O alto nível de competição da indústria aeronáutica mundial demanda a necessidade de automatização de

vários processos na cadeia produtiva desse setor. A automação da furação e inserção de prendedores em chapas

aeronáuticas está sendo realizada em um projeto denominado EFIP (Efetuador de Furação e Inserção de

Prendedores). O trabalho apresentado neste artigo trata da validação de um software de controle do EFIP e tem como

objetivo garantir a tomada de decisão correta do software quando sujeito a uma entrada ou evento aleatório. Este

trabalho foi desenvolvido no software LabVIEW por meio de algumas metodologias de teste, dentre elas a CoFI

(Conformance and Fault Injection), que cria casos de teste de software do ponto de vista do usuário. Diversos

resultados como modelos de estados e tabelas de decisão foram obtidos com a aplicação da CoFI ao EFIP e são

discutidos neste artigo.

Palavras chave: Robótica, Automação, Eletro-mandril, LabVIEW, CoFI, Diagrama de estados.

1. Introdução

O nível de competição da indústria aeronáutica, crescente nas últimas décadas, tem pressionado muitas empresas

desse setor a aumentar a eficiência de seus processos. Com base no ciclo de produção de uma aeronave, o processo de

montagem estrutural aeronáutico se apresenta como um dos mais extensos da cadeia produtiva. Atualmente, na

indústria aeronáutica brasileira, a montagem estrutural de segmentos de fuselagem é realizada em grande parte de forma

manual, o que implica ciclos de produção elevados e conseqüentemente dispendiosos. Um estudo recente apresentado

por Cibiel et al. (2006) elegeu a operação de furação e instalação de prendedores como o melhor processo para ser

automatizado utilizando robôs industriais, dentre as diferentes tarefas executadas manualmente na indústria aeronáutica.

Diante desse panorama, o Projeto AME (Automação da Montagem Estrutural de Aeronaves), desenvolvido pelo

ITA (Instituto Tecnológico de Aeronáutica), voltado à indústria aeronáutica brasileira, tem como objetivo o

desenvolvimento de soluções economicamente viáveis para a automação desses processos. Dentre os subprojetos está o

EFIP (Efetuador de Furação e Inserção de Prendedores), um efetuador robótico que efetua a junção dos segmentos de

fuselagem por meio da furação e inserção de rebites, e constitui o foco deste trabalho.

Nesse contexto, esse projeto enquadra-se como parte da solução para o problema de automação da usinagem

(furação) industrial de alta precisão e acuracidade (dentro de limites aceitáveis), pois trata, em linhas gerais, da

elaboração de diversas rotinas de teste para validação do software de controle específico do EFIP, bem como a

participação na integração de diversos sistemas do EFIP, análise das rotinas de controle, dentre outros fatores.

O escopo deste trabalho constitui algumas etapas, descritas a seguir: estudo de alguns periféricos constituintes do

sistema EFIP e coleta de parâmetros em manuais; aprofundamento do estudo em LabVIEW (software base de controle

do EFIP) particularmente em termos da arquitetura “produtor-consumidor” usada no controle do EFIP; estudo do

sistema de comunicação por meio da placa PCI Servo Motion Controller do fabricante National Instruments;

participação na integração de diferentes Módulos do EFIP e auxílio em testes e ajustes; testes iniciais de sistema de

posicionamento do motor elétrico com uso de placa PCI comum da National Instruments; elaboração de rotinas de

testes usando modelos específicos e a metodologia CoFI (Conformance and Fault Injection) aos principais Módulos do

EFIP, que permitam a validação dos diversos sistemas constituintes do EFIP e garantam o funcionamento correto e

confiável do sistema em diferentes situações (robustez), usando a placa PCI mencionada; refinamento e aplicação dos

Anais do XVII ENCITA, ITA,19 de outubro de 2011

,

testes aos principais Módulos do EFIP, objetivando maior eficiência do sistema e menor chance de erros; integração de

modelos de testes entre os principais Módulos do EFIP; comparação de resultados envolvendo os testes do sistema final

do EFIP com os resultados obtidos em testes anteriores do EFIP usando diferentes hardwares; documentação geral do

projeto.

O projeto foi desenvolvido segundo a metodologia de “Desenvolvimento Integrado de Produto”, no qual se avaliou

a necessidade de testes de um sistema (o EFIP no caso) que atendesse aos requisitos de furação segundo parâmetros

previamente definidos, definiram-se problemas relacionados ao processo, analisaram-se ferramentas que pudessem ser

utilizadas na síntese do projeto visando uma otimização do mesmo, e por fim avaliaram-se os resultados criticamente,

no intuito de melhorar quando necessário.

2. Ferramenta Multifuncional

Esse projeto é complemento de outro projeto de Iniciação Científica (IC), dos mesmos autores, intitulado “Ligação

e Programação de Módulo de Furação com Sistema de Avanço”, e serve como extensão da pesquisa e aperfeiçoamento

de técnicas e testes diversos. O sistema analisado está inserido em um projeto mais abrangente de interesse conjunto do

ITA e da indústria Aeronáutica Brasileira, denominado “EFIP” (Efetuador de Furação e Inserção de Prendedores), no

qual a ferramenta multifuncional (end-effector) está inserida no extremo de um braço mecânico industrial. O robô é

responsável pelo correto posicionamento daquela ferramenta multifuncional, enquanto esta mede alguns pontos de

referência, efetua a furação, aplica o selante e coloca prendedores.

O EFIP possui uma plataforma mecânica e alguns Módulos com funções específicas. Esses outros Módulos e

sistemas estão sendo desenvolvidos por outros pesquisadores, dentre eles doutorandos, mestrandos e graduandos do

ITA, bolsistas de IC do CNPq. Os Módulos (coloridos distintamente na Fig.1) dividem-se em Módulo de Visão (em

rosa, posicionamento do end-effector em local correto para executar as operações), Módulo de Furação (em azul claro),

Módulo de Aplicação de Selante (em marrom), Módulo de Perpendicularidade (em verde-limão) e Módulo de Inserção

de Prendedores (em verde musgo). O sistema atual é mostrado à direita na Fig.1.

Figura 1. Módulos do EFIP constituindo uma ferramenta multifuncional. Esquerda: esquema. Direita: montagem final.

A título de conhecimento, a sequência básica de operação do EFIP compreende as seguintes etapas:

posicionamento do EFIP no ponto de referência através do robô; medição da referência por meio de visão

computacional (Módulo de visão); posicionamento do EFIP na posição de processo através do robô; avanço do sistema

de aproximação longitudinal até apoiar na chapa a ser furada; posicionamento do Módulo de furação pelo sistema

transversal; execução da furação pelo Módulo de furação; posicionamento do Módulo de aplicação de selante pelo

sistema transversal; aplicação de selante pelo Módulo de aplicação de selante; posicionamento do Módulo de inserção

de prendedores pelo sistema transversal; inserção de prendedores pelo Módulo de inserção de prendedores; recuo do

sistema de aproximação longitudinal. A Fig. 2 mostra o EFIP instalado no robô e permite visualizar o sistema principal.

Figura 2. Sistema robótico industrial com EFIP instalado posicionado sobre fuselagem.


,

Alguns outros equipamentos como o sistema de refrigeração, de lubrificação (nebulizador de óleo), de limpeza

(aspirador de cavaco), além de válvulas pneumáticas e outros equipamentos foram ocultados para melhor visualização

do projeto global.

O sistema robótico industrial (alaranjado na Fig. 2) é da fabricante alemã “KUKA Roboter”. Em particular o

sistema usado nesse projeto é o modelo “KUKA KR210 L100-2K S2000”. Esse robô possui 1515 kg ao todo (sem

contar o controle), 6 eixos de rotação (graus de liberdade), controle remoto, suporta até 100 kg de carga no extremo do

braço (payload), mas um total de até 500 kg de carga distribuída. Esse equipamento foi adquirido dentro das

especificações necessárias e instalado no Laboratório de Automação para Montagem Estrutural (LAME), no ITA, para

ser utilizado em diversos experimentos e testes, dentre eles o EFIP.

3. Sistema de controle do EFIP

3.1. Placa NI 7358 e portas I/O

O sistema do EFIP apresentado na secção anterior é controlado, majoritariamente, por uma placa (hardware)

computacional especial, do fabricante National Instruments, instalada em um computador industrial com processamento

adequado. A placa é do tipo “High Performance Stepper / Servo Motion Controllers” e apresenta algumas

características que foram decisivas para sua escolha no projeto: 64 portas de I/O (input / output); possibilidade de

controle de até 8 eixos de movimento; controle configurável do motor de passo e servo; até 4 MHz de taxa de saída do

motor de passo; dentre outras características relevantes. A placa em questão apresenta uma série de entradas e saídas

analógicas e digitais configuráveis que foram parametrizadas para uso conforme necessidade no EFIP.

3.2. Software de controle em LabVIEW e arquitetura “produtor-consumidor”

O software LabVIEW (Laboratory Virtual Instrument Engineering Workbench) é um ambiente de programação

gráfico usado por milhões de engenheiros e cientistas para desenvolver medições sofisticadas, testes e sistemas de

controle em automação utilizando ícones gráficos intuitivos e blocos que se assemelham a um fluxograma. O software

oferece integração com milhares de dispositivos de hardware e provê centenas de bibliotecas embutidas para análise

avançada e visualização de dados. A plataforma é compatível com objetivos múltiplos e sistemas operacionais, e desde

sua introdução em 1986 se tornou um líder de indústria. Esse sistema é do fabricante “National Instruments”, empresa

americana com sede em Austin, Estados Unidos, com operações em 41 países do mundo, produtora de equipamentos de

teste e controle automatizado, software de instrumentação virtual, além de equipamentos auxiliares a estes sistemas.

O grande objetivo/problema deste trabalho é a validação, por meio de testes usando diversas metodologias, do

software de controle do sistema do EFIP que foi tese de Mestrado de Anjos (2010). Esse sistema é bastante complexo e

envolveu vários parâmetros a avaliar, não só em termos de software, pois as rotinas são bastante trabalhosas, como

também de hardware, pois diversos ajustes precisaram ser feitos a fim de tornar o sistema eficiente e confiável.

A arquitetura Produtor-Consumidor é uma arquitetura relativamente difundida no ambiente LabVIEW e aplicada a

um escopo mais abrangente, pois não se limita a sistemas baseados em eventos discretos. A Fig. 3 ilustra um esquema

dessa arquitetura usada no software de controle.

Figura 3. Esquema da arquitetura produtor-consumidor.

Essa arquitetura é um caso particular da arquitetura mestre-escravo. É considerada uma evolução no sentido que

permite o compartilhamento de dados entre múltiplos loops executados em taxas de amostragem diferentes. Desta

forma, possibilita manipulação de múltiplos processos com taxas individuais de execução diferenciadas. A arquitetura

produtor-consumidor é comumente usada em aplicações onde se recebe múltiplos pacotes de dados que devem ser


,

processados de forma assíncrona segundo a ordem de chegada. Outra característica desta arquitetura é a adição de um

buffer de comunicação entre as aplicações produtor e consumidor. Basicamente, esta arquitetura possui dois loops

paralelos. O primeiro, destinado a “produzir” dados e o segundo a “consumir” dados. Uma fila implementa o buffer

entre os loops produtor e consumidor.

A Fig. 4 mostra o Painel Frontal do software de controle usando LabVIEW, a fim de ilustrar a interface de

controle, dentre outros aspectos.

Figura 4. Sistema de Controle do EFIP – Painel Frontal.

A arquitetura de controle produtor-consumidor do LabVIEW não se baseia em uma linguagem de modelagem

específica para sistemas a eventos discretos permitindo atuar de forma mais abrangente. Sua característica de gerenciar

a execução de múltiplos processos se alinha com a concepção modular do EFIP.

Por outro lado, esta arquitetura não preenche todos os requisitos necessários ao software de controle do EFIP. O

sistema EFIP deve gerenciar a execução de atividades que apresentam diferentes tempos de resposta. Por exemplo,

alguns eventos críticos relacionados à segurança, tais como a aquisição dos esforços mensurados pela célula de carga

exige respostas rápidas do sistema de controle. Paralelamente, alguns comandos estão relacionados a processos de

dinâmica relativamente lenta, como o deslocamento de pistões pneumáticos e de servo-posicionadores. Esta

característica do EFIP representa um problema para arquitetura produtor-consumidor padrão do LabVIEW.

3.3. Sequência de operações de outros Módulos do EFIP

Inicialmente esperava-se que fosse possível criar um diagrama de estados (Máquina de Estados Finitos) usando

modelo Mealy (um evento de transição se relaciona diretamente com a saída) que compreendesse todos os estados do

sistema EFIP e fosse capaz de modelar todas as transições.

Conforme se foi descrevendo os Módulos a fundo, e enumerando os passos, percebeu-se rapidamente que essa

hipótese deveria ser descartada, tendo em vista o número de estados de cada Módulo e altíssima complexidade de

integrar os diferentes Módulos do EFIP em um mesmo autômato. Portanto, a alternativa encontrada foi elaborar

diagramas de estados voltados a apenas Módulos específicos do EFIP, como por exemplo, o Módulo de Furação.

Abaixo segue uma sequência simplificada das etapas pelo qual o EFIP passa em uma rotina simples de furação, a fim de

avaliar essas etapas.

1) Ajuste da posição inicial (parametrizada pelo LabVIEW);

2) Posicionamento do Módulo de Visão;

3) Correção de erros nos eixos X e Y (plano da fuselagem);

4) Aplicação de um “pré-clamp” (força de aproximadamente 50N, encostando rótula na fuselagem, objetivando

reduzir vibrações durante a furação);

5) Aplicação de um clamp de 100N, uma força sobre a chapa de modo e evitar vibrações;


,

6) Execução de nova correção com valores vindos da curvatura da rótula;

7) Aplicação de um clamp novamente sobre a estrutura;

8) Posicionamento do motor elétrico (spindle) lateralmente, alinhando com o eixo de furação;

9) Acionamento da bomba de refrigeração;

10) Acionamento do Inversor de frequência que alimenta o motor elétrico;

11) Acionamento de refrigeração (circula fluido refrigerante pelo motor);

12) Acionamento de jato de ar (limpeza da broca);

13) Avanço da broca e execução da furação;

14) Recuo da broca;

15) Desligamento do spindle e sistemas auxiliares;

16) Envio de rebite para o coletor de prendedor, por tubos de sucção;

17) Aplicação de selante;

18) Ajuste do coletor;

19) Alinhamento da Torqueadeira;

20) Avanço da Torqueadeira e captura de rebite;

21) Avanço da Torqueadeira até colocar rebite na fuselagem;

22) Acionamento da Torqueadeira para romper rebite;

23) Descarte do resto do rebite pela Torqueadeira;

24) Recuo da Torqueadeira;

25) Reinício da rotina de posicionamento para novo furo.

3.4. Metodologia CoFI

Como apresentado por Ambrosio (2005) a CoFI (Conformance and Fault Injection) é uma metodologia de teste

baseada em modelos utilizada para validar inicialmente softwares de aplicações aeroespaciais, mas aplica-se à validação

de softwares de controle de modo geral, cujas características se adequem à sua aplicação. A COFI define uma

sistemática para criação de casos de teste de software ou de sistema. Utiliza o conceito de teste caixa-preta: baseia-se

em modelos de estados que traduzem o comportamento do sistema sob teste do ponto de vista de um usuário externo.

Este conceito corrobora com a idéia de que os testes de um sistema ou software não sejam especificados e executados

pela mesma pessoa que desenvolve o aplicativo.

Os detalhes que caracterizam a Metodologia CoFI são:

• a orientação das etapas de teste ao testador;

• a definição de uma sistemática para criação de casos de teste de software ou de sistema;

• a elaboração de projeto visando atender as necessidades de validação de software de modo geral, levando em

conta, portanto, falhas físicas que podem ser provocadas sobre o hardware. Porém permite que outros tipos de falhas

sejam levados em consideração;

• a caracterização de teste caixa-preta: baseia-se em modelos de estados que traduzem o comportamento do sistema

em teste (SUT: system under test);

• a utilização da ferramenta CONDADO, um software auxiliar, para geração automática de casos de teste;

• a combinação de duas abordagens de teste: conformidade e injeção de falhas;

• a decomposição do comportamento do SUT em modelos de estados é feita pela definição de serviços (função

como vista pelo usuário);

• a decomposição de cada serviço por um “tipo de comportamento” frente a falhas que se desejam observar, assim,

criam-se modelos para mapear o comportamento normal (se houvesse ausência de falhas); frente a exceções

especificadas; frente a entradas inoportunas ou caminhos furtivos; dos mecanismos de tolerância a falhas (disparados

pelas falhas de hardware).

3.4.1. Etapas da metodologia CoFI

A sequência de passos da CoFI pode ser descrita do seguinte modo:

1) Identificação:

• dos serviços que um usuário reconhece e pode usar do SUT;

• das falhas físicas que podem ocorrer no hardware (e que o SUT deveria resistir);

• das facilidades/restrições do Sistema de teste mais os pontos de controle e observação (PCO), endereços físicos e

lógicos, etc.;

• dos eventos (comandos) e das ações (respostas) do SUT;

2) Criação dos modelos parciais. Para cada “serviço” (função esperada pelo sistema), definição do comportamento:

• normal (ausência de falhas);


,

• frente a exceções especificadas;

• frente a entradas inoportunas ou caminhos furtivos;

• dos mecanismos de tolerância a falhas (disparados pelas falhas de hardware);

Criam-se máquinas de estados para representar o comportamento do SUT frente a situações normais e anormais:

3) Criação do(s) modelo(s) normal(is):

• A definição de um modelo do comportamento normal de um serviço depende da sequência de eventos que o SUT

normalmente se espera para ser operado em rotina;

• Identificar a operação normal, rotineira a que o SUT vai ser submetido;

• Identificar os eventos e as ações esperadas para esta operação;

• Se esta informação não estiver contida nos documentos, o testador deve requisitá-la.

4) Criação do(s) modelo(s) de exceções especificadas:

• Levantar as exceções que foram citadas nos documentos (o que acontece se temporizações são excedidas, se

comandos errôneos chegam ao invés de comandos corretos, etc..);

• Identificar os eventos e as ações esperadas neste contexto (definindo assim os eventos de exceções);

• Tomar um modelo do comportamento normal do serviço (definido no passo anterior) e modificá-lo:

(i) incluindo os eventos de exceções em novas transições;

(ii) excluindo caminhos já reconhecidos, mas mantendo o modelo conexo, com estado inicial e final.

5) Criação do(s) modelo(s) de Caminhos Furtivos:

Tomar um modelo normal e escrevê-lo como uma tabela de Eventos versus Estados;

Identificar as células em branco da tabela;

Modificar o modelo normal:

(i) incluindo os eventos nos estados onde eles não existiam

(ii) excluindo caminhos já reconhecidos nos passos anteriores

6) Criação do(s) modelo(s) de Tolerância a Falhas:

• Identificar as falhas físicas e definir os eventos de falhas correspondentes;

• Para cada tipo de falha física fazer:

• Tomar um modelo do comportamento normal do serviço e modificá-lo:

(i) incluindo os eventos de falhas em novas transições e;

(ii) excluindo caminhos já reconhecidos, mas mantendo o modelo conexo, com estado inicial e final.

7) Geração automática dos testes:

• Submeter cada modelo (representado por uma máquina de estado) à ferramenta Condado;

• Gerar um conjunto de casos de teste que corresponde à união dos casos de testes gerados para cada máquina.

3.5. Ferramentas MME e CONDADO

Os modelos que mapeiam os comportamentos normal, frente a exceções especificadas e com caminhos furtivos

foram submetidos ao Modelador de Máquina de Estados (MME), um software desenvolvido pelo projeto ATIFS (INPE,

2002). Esta ferramenta recebe as máquinas de estados e gera um arquivo de texto específico que carrega as

características dos modelos de entrada. Os arquivos gerados pelo MME fornecem a entrada necessária à ferramenta

CONDADO (MARTINS et al., 1999).

A ferramenta CONDADO por sua vez gera de forma automática os casos de testes. A CONDADO percorre a

estrutura da máquina de estados identificando os caminhos possíveis. A cada caminho está atrelado um conjunto de

entradas e suas respectivas saídas oriundas das transições referentes à máquina de estados de entrada. Este conjunto de

entradas e saídas de um determinado caminho corresponde a um caso de teste.

4. Resultados obtidos

Muitos resultados foram obtidos ao longo do projeto e refletem a aplicação prática dos resultados anteriores que

abordaram uma visão geral do problema e das ferramentas de abordagem utilizadas. Os principais resultados, além do

conhecimento agregado tanto na teoria quanto na prática, referem-se ao desenvolvimento de diagramas de estados em

diversas versões, sendo aqui apresentados apenas os mais relevantes, sequências de testes usando a CONDADO,

comparações com outros autômatos referentes ao mesmo sistema, tabelas de Eventos versus Estados, dentre outros

detalhes.


,

4.1. Módulo de Furação segundo a CoFI

Conforme a metodologia da CoFI explicitada no item 3.4.1 deste relatório, foram desenvolvidos, passo a passo, as

etapas para elaboração da série de testes, focando inicialmente no Módulo de Furação do EFIP. Passadas as etapas de

identificação das funções do sistema e seus requisitos criou-se, após várias versões corrigidas, o autômato que traduz o

modo normal do sistema, sem falhas, conforme se observa na Fig. 5.

Figura 5. Diagrama de estados (Modo Normal) – Módulo de Furação.

Analisando a Fig. 5, pode-se perceber um estado de INÍCIO e outro de FIM evidentes, bem como estados

intermediários, cuja transição se dá por meio da chegada de eventos, e estes caracterizam uma saída. Pensando em teste

“caixa-preta”, o testador não está interessado de que forma esses eventos ocorrem, mas sim na interpretação em alto

nível do procedimento a seguir no caso de ocorrer tal evento. Por exemplo: uma vez que se chegou ao estado

“Deslocando_x”, que é um estado transitório de deslocamento entre a posição de recuo e a posição de alinhamento para

furação, o próximo estado “Plat_Pos_Fur_x” será atingido apenas quando o sensor de deslocamento acusar a posição

alcançada, pensando em alto nível, sem se preocupar com detalhes de hardware. Para o programador, o mesmo evento

seria caracterizado de modo mais detalhado como “porta X da Placa de Motion em nível alto”. Esse afastamento do

testador com relação a detalhes de software e hardware, pensando de modo mais intuitivo caracteriza a metodologia

CoFI. A sequência de transições está didática e permite fácil compreensão do leitor. Vale ressaltar que a palavra

colocada após o nome do evento de transição caracteriza a saída relacionada àquela transição. Na transição comentada,

por exemplo, a saída era “Visual_PlatMecFlur”, que significa o acendimento de um LED no painel frontal do software

de controle, por exemplo, que é didático à avaliação do testador. Observa-se ainda que “ApOK” quer dizer que toda

parte de Alimentação dos sistemas elétricos e Pressões de sistemas Pneumáticos deve ser sempre verificada para

garantir o bom funcionamento do sistema.

Dando continuidade à CoFI, foi gerado também um autômato com base no primeiro, mas que compreendesse

estados auxiliares, aqui caracterizados como estados de erro, pois traduzem situação previstas, por exemplo, em casos

de sobreaquecimento em alguma etapa do processo. A Fig. 6 mostra esses detalhes.

A construção do Modo de Exceções Especificadas é baseada no modelo normal do sistema e inserem-se estados

que caracterizem situações esperadas de ocorrer, mas fora da sequência de eventos no caso sem falhas (normal).

Analisando a Fig. 6, vê-se que os estados em azul claro são estados de sobreaquecimento do motor elétrico, por

exemplo. Vale ressaltar que diversos outros estados de erro poderiam ser inseridos, mas isso sobrecarregaria o desenho

e o número de testes cresceria muito, dificultando tal procedimento. Após essa etapa, criou-se uma planilha apresentada

nas Fig. 7 e 8, contendo todos os eventos e estados do Autômato previstos para esse Módulo, com base na Fig.6.


,

Início

Deslo-

cando_X

Plat_Pos

Fur_X

Refrig

_ON

Selo_ON

Aspira-

dor_ON

Nebuliza-

dor_ON

Pot_Spindle

_ON

Avançan-

do_Y

Pos_Fur_Y

Jato_Ar

ON_Furan-

do

Recuan-

do_Y

Pos_

Recuado_Y

Motor_

OFF

Jato_Ar_

OFF

Nebuliza-

dor_OFF

Motor

_ON

Selo_

OFF

Aspirador_

OFF

Cond_Min_

OK

AlimPresOK

ApOK_SelPlatMecFur /

LEDLabV_ModFur

ApOK_SensorModFur /

Visual_PlatMecFlur

ApOK_AcionaRefig /

Visual_RefrigON

ApOK_AcionaSeloSpindle /

Visual_SeloON

ApOK_AcionaAspirador /

Visual_AspiradorON

ApOK_AcionaPotSpinlde /

LED_LABV_ModFur

ApOK_AcionaNebulizador /

Visual_NebulizadorON

ApOK_AcionaSpindle /

Cursor_V > Vmin ;

Visual_Motor_ON

ApOK_AvançaSpindle /

Visual_AvançaY

ApOK_SpindleAvançado /

Visual_posAvançado

ApOK_Aciona_JatoAr /

Visual_JatoArON

ApOK_Recua_Spindle /

Visual_RecuaY

ApOK_SpindleRecuado /

Visual_PosRecuada

ApOK_DesligaSpindle /

Cursor_V = Vmin

Visual_MotorOFF

ApOK_DesligaJatoAr /

Visual_JatoArOFF

ApOK_DesligaNebulizador /

Visual_NebuizadorOFF

ApOK_Desliga_Aspirador /

Visual_AspiradorOFF

ApOK_SensorModFur &

NãoFalha

FIM

ApOK_Desliga /

FimOperação

Refrig

_OFF

Sobrea-

quece1

Sobrea-

quece2

Sobrea-

quece3

ApOK_T>Tmax /

Visual_MotQuente_Msg.

ApOK_T>Tmax /


ApOK_DesligaNebulizador /

Visual_NebuizadorOFF

ApOK_DesligaSpindle /

Cursor_V = Vmin

Visual_MotorOFF

ApOK_T>Tmax /


ApOK_T>Tmax /


ApOK_Recua_Spindle /

Visual_RecuaY

Figura 6. Diagrama de estados (Modo com Exceções Especificadas) – Módulo de Furação.

Na coluna esquerda das Fig. 7 e 8 verificamos alguns eventos e na linha superior alguns estados. Como objetivo é

analisar Entradas (eventos) diversas para Estados quaisquer, analisa-se o efeito de cada evento sobre cada estado. Por

exemplo, seja o evento “Aciona_Refrig & T.A.P_OK”, que quer dizer ao testador “há acionamento da refrigeração e

condições mínimas (Temperaturas, alimentações e Pressões estão adequadas)”. Segundo a tabela de caminhos furtivos

elaborada, devemos observar que o software de controle do EFIP não execute nenhuma ação (indicado por X) nos casos

em que aquele evento chegar a Estados diferente de “PLAT_POS_FURAÇÃO_X” ou “REFRIGERAÇÃO_ON”. Ainda

nessas situações tomou-se o cuidado de indicar em cinza o destino da próxima transição (próximo estado) para o caso

de Modo Normal, e indicar a próxima transição em amarelo para os casos de Modo com Exceções Especificadas,

ambos antes das barras nas células, e após as barras a saída esperada. Os demais casos marcados com “X” devem ser

ignorados pelo sistema, ou seja, situações em que as entradas não são as esperadas no estado em questão.


,

Figura 7. Tabela de Caminhos Furtivos (Furação) – Eventos x Estados - parte 1 de 2.

Figura 8. Tabela de Caminhos Furtivos (Furação) – Eventos x Estados - parte 2 de 2.

4.2. Módulo de Furação usando MME e CONDADO

Utilizando a MME e CONDADO, com base na metodologia CoFI, pôde-se obter alguns resultados relevantes que

corroboraram a aplicabilidade da metodologia e a utilidade dessas ferramentas.

O diagrama didaticamente mostrado da Fig. 6 foi redesenhado no software MME a fim de gerar os casos de teste

do Módulo de Furação do EFIP. Nesse software inserem-se os Estados, e as transições relacionadas a cada um deles, de

forma coerente. Depois de mapeadas todas as entradas e saídas de cada estado, gera-se um arquivo específico (base de

fatos) desse software que será utilizado pelo CONDADO quando for criada a sequência de testes. A Fig. 9 mostra essa

montagem naquela plataforma, cujos nomes de estados correspondem à nomenclatura apresentada nas Fig. 7 e 8.


,

Figura 9. Modo Exceções Especificadas – Módulo de Furação no software MME.

Gerada a base de fatos pela MME, a CONDADO é um aplicativo que usa esses dados para gerar em modo texto a

sequência de testes. Essa sequência de testes nada mais é do que um arquivo texto contendo uma sequência de estados

segundo caminhos distintos, que devem ser seguidos e ter as saídas observadas para entradas genéricas. A título de

ilustração, segue um trecho do arquivo, que percorre certo caminho no autômato. Ao todo, segundo aquele diagrama da

Fig. 9, há 17 caminhos possíveis. Todos esses caminhos devem ser testados para validar o software, somente para este

Módulo de Furação, além dos caminhos furtivos. Diante do número de Módulos, e da quantidade de testes por

Módulos, pode se ter uma idéia da quantidade de testes a serem feitos para validar o software de controle de um sistema

como o EFIP. Na lista de comandos abaixo, os parâmetros dentro do comando “senddata” se referem aos eventos de

entrada, que são os mesmos da Fig.6, que caracterizam as transições. Já os parâmetros dentro do comando “recdata”

referem-se às saídas esperadas em cada transição. Uma sequência de testes é feita analisando-se linha por linha os

eventos no software de controle e analisando se a saída corresponde ao esperado, por isso a complexidade e volume de

trabalho dessas ações.

senddata(L,AlimPresOK) recdata(L,LEDLabVcondOK) senddata(L,APokSelPlatMecFur) recdata(L,LEDLabVmodFur)

(. . .)

senddata(L,APokDesligaRefrig) recdata(L,VisualRefrigOFF)

Diversos testes de furação foram executados com base na metodologia apresentada, atentando para a sequência de

testes gerada a partir do software Condado, efetuando ajustes no sistema quando necessário. A versão do software

utilizada nos testes, ainda em desenvolvimento, mostrou ausência de problemas de posicionamento da plataforma

mecânica nas 3 posições padrão dos Módulos do EFIP. Mesmo assim, o sistema não promove o avanço ou recuo da

torqueadeira ou do motor caso haja desalinhamento da plataforma mecânica nos momentos furação ou inserção de

rebite. O único problema de posicionamento constatado ocorreu uma vez no avanço ao longo do furo, quando o

sensoriamento dessa posição era feito anteriormente por apenas um encoder. Posteriormente, foi inserido um

instrumento de grande acurácia, denominado régua óptica, a fim de confirmar o posicionamento juntamente com o

encoder. Ainda devido ao processo construtivo do software, não foram implementadas ainda situações de

sobreaquecimento, previstas no diagrama apresentado na Fig. 6. Entretanto, é relevante ressaltar que o software deve

promover o desligamento imediato do sistema em caso de sobreaquecimento, com exceção do momento de furação,

quando se deve comandar o recuo do motor, ainda girando, e posterior desligamento. Caso desligue-se o motor durante

a furação, pode ocorrer dano à broca durante a sua retirada do furo.

Por fim, diversos testes de bancada foram feitos a fim de melhorar a qualidade do furo sobre a chapa de metal

desejada, no intuito de reduzir ao máximo fatores como gravidade e vibrações possíveis quando acoplado no braço

robótico. Após o ajuste ideal dos parâmetros de furação com mínima influência externa indesejada atuando, testes sob

condições mais rigorosas poderão ser executadas. Apesar disso, o sistema mostra-se adequado para atender aos

requisitos de projeto.

4.3. Módulo de Visão segundo a CoFI e softwares auxiliares

De maneira semelhante ao explicitado para o Módulo de Furação, utilizou-se a metodologia CoFI para o

desenvolvimento do modelo do Módulo de Visão. A Fig. 10 resume os diagramas de estados criados representados de

maneira conjunta, em que os estados em azul referem-se ao modo normal, com transições em azul e verde. O estado

vermelho e as transições destacadas em vermelho referem-se ao modo com exceções especificadas.


,

Figura 10. Modo normal e com exceções especificadas do Módulo de Visão do EFIP (legenda de eventos à direita).

De maneira análoga ao mostrado no caso do Módulo de Furação, criou-se uma tabela de caminhos furtivos para o

Módulo de Visão, com a mesma metodologia, a fim de estabelecer as decisões do sistema diante de entradas aleatórias.

Utilizando os software MME e Condado, foi possível montar uma versão simplificada da Máquina de estados do

Módulo de Visão e uma sequência de testes coerente. Optou-se pela simplificação do modelo teórico da Fig. 10 de

modo a reduzir os casos de teste, desprezando-se na geração dos caminhos de teste o estado de “STOP” e o estado em

que Diâmetro do Furo é maior que o Diâmetro Máximo de Furo, resultando 16 casos a analisar. Esse diagrama,

juntamente com a ferramenta Condado, foram utilizados para a geração dos casos de teste do sistema.

Algumas considerações sobre os testes devem ser ressaltadas, como o fato de a interface do LabVIEW

corresponder ao esperado em termos de execução e comandos em cada teste. Os testes efetuados que não dependiam da

análise se realmente a posição desejada foi alcançada tiveram sucesso. Tal comprovação será feita posteriormente por

meio de medição de laser radar (este mapeia a posição inicial e final de um objeto que se mova no espaço) a fim de

comprovar a margem de tolerância permitida, tendo em vista a contínua fase de testes do projeto.

Foram inseridas mensagens de erro nos casos convenientes, conforme lista de testes, e as saídas corresponderam

coerentemente às entradas nas transições. Por fim, desprezou-se o estado de diâmetro do furo maior que o tolerado (que

praticamente não será observado e foi desconsiderado nos testes, devido à insuficiente resolução da imagem para

analisar tal característica), implicando testes em geral bem sucedidos.

4.4. Módulo de Inserção de Prendedores segundo a CoFI e softwares auxiliares

Seguindo procedimentos semelhantes aos casos anteriores, estudou-se o Módulo de Inserção de Prendedores e

tornou-se possível a criação do diagrama de estados apresentado na Fig. 11, segundo a metodologia CoFI. Essa figura

evidencia os estados do Modo Normal em azul, bem como os estados do Modo com exceções especificadas, composto

inclusive pelos estados e transições evidenciados em vermelho.

Tabelas de caminhos furtivos para o caso do Módulo de Inserção de Prendedores foram criadas segundo a mesma

metodologia apresentada. Construiu-se ainda o diagrama de estados do Módulo de Inserção de Prendedores no software

MME, que também segue o mesmo procedimento apresentado no caso do Módulo de Furação.

Com base neste diagrama e na ferramenta Condado, foram gerados os casos de teste do Módulo. Com relação aos

testes de modo geral houve sucesso, tornando necessário o ajuste apenas de pequenos detalhes, como inserção de

mensagem de erro em caso de não chegar o rebite, o que necessitou o envio de mais um comando de envio de rebite; no

caso de a torqueadeira não atingir a posição ao longo do furo. Posteriores problemas a corrigir foram a verificação de

alinhamento da plataforma mecânica no Módulo em questão, com posterior mensagem de erro no caso de não haver

sucesso (em caso de desalinhamento, não ocorre avanço, garantindo 3 posições possíveis), e administração do problema

físico do caso em que mais de um rebite é enviado por vez, o que deve ser impedido fisicamente.


,

Figura 11. Modo Normal e Exceções Especificadas – Módulo de Inserção de Prendedores (legenda à direita).

5. Conclusões

Apesar de o projeto ser grandioso e desafiador em termos de conhecimento agregado e atividades realizadas, o

cronograma de trabalho proposto foi cumprido, de acordo com a evolução natural e a interdependência entre as

atividades que se seguiram, sujeito a apenas pequenos ajustes. A quantidade de conhecimento e experiência acumulados

nesse período corroboram a importância de trabalhos como esse de Iniciação Científica para a formação do engenheiro

e a ligação à carreira científica. Certamente bastante trabalho foi executado, principalmente no que se diz respeito à

elaboração de modelos finais de diagramas de estados para diversos Módulos do EFIP, geração de rotinas de teste e

execução propriamente dita dos testes no EFIP, mas com planejamento e critério tais objetivos foram cumpridos.

Portanto, o trabalho seguiu as metas estipuladas e apresentou bons resultados, com discussão de resultados de

testes apresentadas ao final dos itens 4.2, 4.3, e 4.34 O apoio de infraestrutura dos laboratórios do ITA, em especial o

LAME, contribuiu significativamente para o avanço do projeto, bem como a equipe de profissionais envolvidos,

possibilitando que este projeto tenha contribuição valiosa para o projeto do EFIP, e por extensão para o avanço

científico em termos de automatização da indústria aeronáutica brasileira.

6. Agradecimentos

Agradecimentos especiais a Emília Villani, Carlos Silva, José Anjos, Guilherme Coracini e Carlos Eguti pelo apoio

nas atividades do projeto. Grato ao CNPq pelo suporte financeiro e à equipe e às instalações do CCM/LAME.

7. Referências

Ambrosio, A. M., 2005, “CoFI: uma abordagem combinando teste de conformidade e injeção de falhas para validação

de software em aplicações espaciais”. Instituto Nacional de Pesquisas Espaciais, São José dos Campos, Brasil, 209p.

Anjos, J. M. S., 2010, “Proposta de arquitetura de software de controle para efetuador robótico multifuncional”. Tese de

Mestrado em Sistemas Aeroespaciais e Mecatrônica, Instituto Tecnológico de Aeronáutica, São José dos Campos,

Brasil, 121 p.

ATIFIS: Ambiente de Testes baseado em injeção de Falhas por Software. Website acessado em 08/2010. <http://www.inpe.br/atifs/ferramentas/ferramenta_mme.php>, <http://www.inpe.br/atifs/ferramentas/ferramenta_condado.php>.

ATIFIS: Ambiente de Testes baseado em injeção de Falhas por Software. Website acessado em 08/2010.

Cibiel, C., Prat, P., 2006, “Automation for the Assembly of the Bottom Wing Panels on Stringers for the A320”, SAE

Transactions, Paper Number 2006-01-3143.

Gripp, J. A. B., 2010, “Ligação e programação de Módulo de furação com sistema de avanço”. Artigo de Iniciação

Científica – Anais do XVI ENCITA, Instituto Tecnológico de Aeronáutica, São José dos Campos, Brasil, 12 p.

Johnson, G. W., Jennings, R., 1994, “LabVIEW Graphical Programming - Practical Application in Instrumentation and

Control”, Ed. Series Editor, Estados Unidos da América, 608p.

Martins, E.; Sabião, S. B.; Ambrosio, A. M., 1999, “ConData: a Tool for Automating Specification-based Test Case

Generation for Communication Systems”. Software Quality Journal, Vol.8, No. 4, pp. 303-319.

PROGRAMAÇÃO E TESTE DE EFETUADOR DE FURAÇÃO E INSERÇÃO DE … · elaboração de diversas...

Documents

Transcript of PROGRAMAÇÃO E TESTE DE EFETUADOR DE FURAÇÃO E INSERÇÃO DE … · elaboração de diversas...