Upload
vodieu
View
212
Download
0
Embed Size (px)
Citation preview
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
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
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
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.
Anais do XVII ENCITA, ITA,19 de outubro de 2011
,
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
Anais do XVII ENCITA, ITA,19 de outubro de 2011
,
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;
Anais do XVII ENCITA, ITA,19 de outubro de 2011
,
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);
Anais do XVII ENCITA, ITA,19 de outubro de 2011
,
• 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.
Anais do XVII ENCITA, ITA,19 de outubro de 2011
,
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.
Anais do XVII ENCITA, ITA,19 de outubro de 2011
,
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 /
Visual_MotQuente_Msg.
ApOK_DesligaNebulizador /
Visual_NebuizadorOFF
ApOK_DesligaSpindle /
Cursor_V = Vmin
Visual_MotorOFF
ApOK_T>Tmax /
Visual_MotQuente_Msg.
ApOK_T>Tmax /
Visual_MotQuente_Msg.
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.
Anais do XVII ENCITA, ITA,19 de outubro de 2011
,
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.
Anais do XVII ENCITA, ITA,19 de outubro de 2011
,
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.
Anais do XVII ENCITA, ITA,19 de outubro de 2011
,
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.
Anais do XVII ENCITA, ITA,19 de outubro de 2011
,
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.