TCC Martin 2020

Universidade Federal de Santa Catarina
Centro de Blumenau
Departamento de Engenharia de
Controle e Automação e Computação
Martin Hermes Anschau
Sistema de Verificação Automática de Testes no

Desenvolvimento de Firmwares de Inversores de Frequência
Blumenau
2019
Martin Hermes Anschau
Sistema de Verificação Automática de Testes no

Desenvolvimento de Firmwares de Inversores de
Frequência
Trabalho de Conclusão de Curso apresentado à Universidade Fede-

ral de Santa Catarina como parte dos requisitos necessários para a
obtenção do Título de Engenheiro de Controle e Automação.
Orientador: Prof. Dr. Carlos R. Moratelli
Universidade Federal de Santa Catarina

Centro de Blumenau
Departamento de Engenharia de
Controle e Automação e Computação
Blumenau
2019
Scanned by CamScanner
Dedico este trabalho aos pilares da minha vida:
família, amigos e professores.
Agradecimentos
Primeiramente agradeço à família da minha mãe, por sempre ter me proporcionado,

mesmo diante de alguns problemas, uma atmosfera saudável onde pude exercer tudo aquilo
que fez com que eu chegasse até aqui. Eu devo quase tudo o que sou a ela. Agradeço ao
meu pai por ajudar a fomentar minha educação, me apoiar em situações difíceis e pelas
viagens divertidas e sem rumo durante a graduação.
Agradeço à todos os meus amigos de vida e colegas de universidade, especialmente
ao André Granemann, ao Gustavo Link e ao Christian Borba, que tive muita sorte de
conhecer, compartilhar momentos e evoluir juntamente durante o lapso de tempo em que
estivemos próximos. O mundo é melhor com pessoas como eles e isso me é motivador.
Agradeço imensamente à Universidade Federal de Santa Catarina e ao campus de
Blumenau, que me proporcionaram todo o ferramental técnico e teórico pelos quais pude
aprender intensamente algumas das coisas mais interessantes que já conheci. Agradeço a
todos os professores da automação da UFSC e, principalmente, ao Leonardo Mejia Rincón,
por ter me provido bagagem científica durante mais de dois anos na academia e ao Carlos
Roberto Moratelli, meu orientador neste importante Trabalho de Conclusão de Curso.
Agradeço à WEG e toda a equipe do setor de desenvolvimento de inversores de baixa
tensão, lugar onde conheci ótimos profissionais, como o Osvaldo, Gabriel, Guilherme e
Horácio e onde passei cinco meses desenvolvendo o projeto que contribuiu para a concepção
deste documento.
Por fim, os meus agradecimentos mais que especiais são para a minha mãe, Jaqueline,
que sempre batalhou para que eu e meu irmão pudéssemos nos tornar grandes homens e
para meu irmão, Eduard, com quem sempre pude debater e refletir sobre as coisas que a
vida oferece. Vocês foram os melhores.
"Nada é mais repugnante do que a maioria, pois ela compõe-se de uns poucos
antecessores enérgicos; velhacos que se acomodam; de fracos que se assimilam, e da
massa que vai atrás de rastros, sem nem de longe saber o que quer."
(Johann Wolfgang von Goethe)
Resumo
Com a constante evolução em termos de computação e eletrônica os inversores de

frequência têm possuído cada vez mais tecnologias embarcadas. Para que o inversor de
frequência seja desenvolvido com rapidez e entregue qualidade final para as suas aplicações
toda sua infraestrutura, física e lógica, deve estar funcionando de maneira plena. A parte
lógica desse dispositivo é estruturada por meio de um firmware o qual é executado por
um ou mais microprocessadores, que devem interpretar e compilar uma grande gama de
códigos computacionais. Durante o desenvolvimento desses dispositivos é normal que
ocorram falhas e diversos testes sejam realizados até sua validação. Com a finalidade de
diminuir a ocorrência de erros nos testes dos firmwares de inversores de frequência em
desenvolvimento, este trabalho propõe o estudo, projeto e validação de uma alternativa
que visa verificar testes de forma automatizada antes de uma nova versão de firmware ser
lançada, gerando ainda um histórico de resultados de testes. Para a realização do projeto,
toda uma estrutura relacionando conceitos que envolvem a linguagem de programação
Python, protocolos de comunicação industriais, consumo de dados do Application Lifecycle
Management, interface gráficas de usuário e ferramentas de integração contínua, como o
Jenkins, deve ser sistematizada a fim de corroborar a proposta original do trabalho. Por
fim, resultados envolvendo a configuração automática de parâmetros de um inversor foram
demonstrados.
Palavras-Chave: 1. Inversor de Frequência. 2. Firmware. 3. Python. 4. API rest.
Abstract
With the constant evolution of computing and electronics, the firmware for frequency
inverters is becoming more and more complex. For its quick development and final quality
assurance, the developer must guarantee that its physical and logical infrastructure is
fully working. The logical part of the frequency inverter is structured through a firmware
which is executed by one or more microprocessors that must interpret and compile a wide
range of computational code. During the development of these devices, it is normal for
the occurrence of failures, and various tests have to be performed until their validation.
With the focus to reduce the occurrence of errors in the firmware under tests, this work
proposes the study, design, and validation of an alternative that aims to verify tests
automatically in inverters before a new version to be released, generating a constant
history of tests results. For the realization of the project, a whole structure integrating
concepts involving Python programming language, industrial communication protocols,
data consumption of the Application Lifecycle Management through rest API, graphical
user interfaces and continuous integration tools, such as Jenkins, must be systematized
in order to corroborate the original work proposal. Finally, some results involving the
automatic configuration of parameters of an inverter were performed.
Keywords: 1. Frequency Inverter. 2. Firmware. 3. Python. 4. rest API.
Lista de figuras
Figura 1 – Inversor de frequência CFW500 da WEG S.A. [1] . . . . . . . . . . . . 19

Figura 2 – Estimativa de uso de máquinas elétricas na indústria [Fonte: Franchi
[2]]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Figura 3 – Retificador do inversor [Fonte: Franchi [2]]. . . . . . . . . . . . . . . . . 20
Figura 4 – Saída de controle do inversor [Fonte: Franchi [2]]. . . . . . . . . . . . . 20
Figura 5 – Inversor aplicado a um motor de indução trifásico [Fonte: Franchi [2]]. 21
Figura 6 – Blocos de componentes do inversor [Fonte: Franchi [2]]. . . . . . . . . . 21
Figura 7 – IHM do CFW500 da WEG S.A. [3] . . . . . . . . . . . . . . . . . . . . 23
Figura 8 – Modelo do ciclo de vida de um software. . . . . . . . . . . . . . . . . . 30
Figura 9 – Formato de mensagem do protocolo ModBus RTU. . . . . . . . . . . . 31
Figura 10 – Exemplo de troca de mensagens entre mestre e escravo com ModBus
RTU [Fonte: Adaptado de Tamboli et al. [4]]. . . . . . . . . . . . . . . 32
Figura 11 – Exemplo de um GUI e um CLI. . . . . . . . . . . . . . . . . . . . . . . 35
Figura 12 – Ilustração da placa Raspberry Pi 3B+ [5]. . . . . . . . . . . . . . . . . 38
Figura 13 – Arquitetura do projeto com o uso estação remota através de um Rasp-
berry Pi. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Figura 14 – Arquitetura mestre/escravo utilizando no Jenkins. . . . . . . . . . . . . 39
Figura 15 – Ilustração da arquitetura básica do projeto. . . . . . . . . . . . . . . . 43
Figura 16 – Atividades por nível do projeto. . . . . . . . . . . . . . . . . . . . . . . 44
Figura 17 – Ilustração da arquitetura básica do projeto. . . . . . . . . . . . . . . . 46
Figura 18 – Exemplo de ordem cronológica no desenvolvimento do firmware. . . . . 49
Figura 19 – Fluxo de planejamento dos testes no ALM. . . . . . . . . . . . . . . . . 50
Figura 20 – Detalhamento de um requisito de teste no ALM. . . . . . . . . . . . . . 51
Figura 21 – Exemplo de um teste no ALM. . . . . . . . . . . . . . . . . . . . . . . 52
Figura 22 – Atividades relacionadas ao nível de hardware do projeto. . . . . . . . . 53
Figura 23 – Fluxograma lógico de um teste exemplo. . . . . . . . . . . . . . . . . . 56
Figura 24 – Fluxograma da lógica de execução dos testes. . . . . . . . . . . . . . . 61
Figura 25 – Formato XML dos dados resultantes de um teste. . . . . . . . . . . . . 63
Figura 26 – Exemplo de histórico de resultados no ALM. . . . . . . . . . . . . . . . 63
Figura 27 – Exemplo de histórico de resultados gerado localmente. . . . . . . . . . 64
Figura 28 – Interface gráfica de usuário com seus componentes evidenciados. . . . . 66
Figura 29 – Interface de linha e comando do projeto. . . . . . . . . . . . . . . . . . 67
Figura 30 – Modelo de execução do Jenkins. . . . . . . . . . . . . . . . . . . . . . . 68
Figura 31 – Diagrama das conexões físicas do sistema proposto. . . . . . . . . . . . 69
Figura 32 – Dinâmica esperada para o teste 1. . . . . . . . . . . . . . . . . . . . . . 72
Figura 33 – Dinâmica obtida para o teste 1 na versão 0.70 do firmware. . . . . . . . 73
Figura 35 – Dinâmica esperada para o teste 2. . . . . . . . . . . . . . . . . . . . . . 75
Figura 38 – Históricos locais de resultados gerados. . . . . . . . . . . . . . . . . . . 79
Figura 39 – Histórico remoto gerado no ALM (versão 0.70 do firmware). . . . . . . 79
Figura 40 – Histórico remoto gerado no ALM (versão 0.71 do firmware). . . . . . . 80
Lista de tabelas
Tabela 1 – Exemplos de parâmetros do motor e inversor . . . . . . . . . . . . . . . 24

Tabela 2 – Exemplos de sistemas embarcados e seus tipos de mercado. . . . . . . . 36
Tabela 3 – Parâmetros do motor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Tabela 4 – Descrição do teste 1 a partir do ALM . . . . . . . . . . . . . . . . . . . 71
Tabela 5 – Descrição do teste 2 a partir do ALM . . . . . . . . . . . . . . . . . . . 75
Lista de Siglas e Abreviaturas
UFSC Universidade Federal de Santa Catarina

CC Corrente Contínua
CA Corrente Alternada
WEG Werner, Eggon e Geraldo
CPU Central Processing Unit
CC Corrente Contínua
IGBT Insulated Gate Bipolar Transistor
SA Sociedade Anônima
IGBT Insulated Gate Bipolar Transistor
HTTP Hypertext Transfer Protocol
CLP Controlador Lógico Porgramável
HMI Human-Machine Interface
IHM Interface Homem-Máquina
RTU Remote Terminal Unit
CRC Cyclic Redundancy Check
IP Internet Protocol
ODVA Open DeviceNet Vendors Association
CAN Controller Network Area
ACII American Standard Code for Information Interchange
HTML Hypertext Markup Language
API Application Programming Interface
ALM Application LifeCycle Management
HP Hewlett-Packard
PC Personal Computer
GUI Graphical User Interface
CLI Command Line Interface
DVD Digital Versatile Disc
SO Sistema Operacional
IC Integração Contínua
CI Continuous Integration
DC Direct Current
SD Secure Digital Card
SSH Secure Shell
URL Uniform Resource Locator
XML Extensible Markup Language
Sumário
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.1 Objetivos do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2 A empresa WEG Equipamentos Elétricos . . . . . . . . . . . . . 15
1.3 Estrutura do documento . . . . . . . . . . . . . . . . . . . . . . . 17
2 REVISÃO DAS TECNOLOGIAS UTILIZADAS . . . . . . . . 18

2.1 Inversores de frequência . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1.1 Princípios básicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.2 Unidade central de processamento . . . . . . . . . . . . . . . . . 22
2.1.3 Interface homem-máquina . . . . . . . . . . . . . . . . . . . . . . 22
2.1.4 Parametrização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.5 Protocolos de comunicação em inversores . . . . . . . . . . . . . 24
2.2 Importância dos firmwares nos inversores . . . . . . . . . . . . 26
2.3 Protocolo HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.3.1 Funcionamento e aplicação no projeto . . . . . . . . . . . . . . . 28
2.4 API rest’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.4.1 Application Lifecycle Management (ALM) . . . . . . . . . . . 29
2.5 Protocolo ModBus RTU . . . . . . . . . . . . . . . . . . . . . . . 31
2.6 Linguagem Python . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.7 Importância e utilização de interfaces gráficas em sistemas . . 34
2.8 Sistema embarcado utilizando Raspberry Pi . . . . . . . . . . . 35
2.8.1 Conceito de sistemas embarcados . . . . . . . . . . . . . . . . . . 35
2.8.2 Raspberry Pi e sua importância no projeto . . . . . . . . . . . . 37
2.9 Jenkins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.10 Trabalhos relacionados . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.10.1 Automação de testes Hardware-in-the-loop do sistema embar-
cado de um trator . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.10.2 O impacto no custo, qualidade e tempo de comercialização
utilizando automação de testes . . . . . . . . . . . . . . . . . . . 41
3 ARQUITETURA DO PROJETO . . . . . . . . . . . . . . . . . 42
3.1 Níveis da arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.2 Integração do software na arquitetura . . . . . . . . . . . . . . . 45
4 METODOLOGIA E IMPLEMENTAÇÃO DO PROJETO . . 48

4.1 Planejamento de testes . . . . . . . . . . . . . . . . . . . . . . . . 49
4.1.1 Requisitos de testes . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.1.2 Criação do teste e descrição de etapas . . . . . . . . . . . . . . . 51
4.1.3 Execução do teste no ALM . . . . . . . . . . . . . . . . . . . . . . 52
4.2 Execução automatizada de parâmetros . . . . . . . . . . . . . . 53
4.3 Execução automatizada de testes . . . . . . . . . . . . . . . . . . 55
4.3.1 Verificação de requisitos . . . . . . . . . . . . . . . . . . . . . . . . 58
4.4 Modelo de execução dos testes . . . . . . . . . . . . . . . . . . . 60
4.4.1 Laço de execução . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.5 Geração de histórico de resultados . . . . . . . . . . . . . . . . . 61
4.5.1 Histórico remoto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.5.2 Histórico local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.6 Utilização de interface gráfica de usuário . . . . . . . . . . . . . 64
4.6.1 Utilização de CLI para integração com o Jenkins . . . . . . . . 66
5 VALIDAÇÃO E RESULTADOS . . . . . . . . . . . . . . . . . . 69
5.1 Teste 1: frenagem DC na partida para dois tipos de controle 70
5.1.1 Versão 0.70 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.1.2 Versão 0.71 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.2 Teste 2: aplicação de rampa inversa de parada . . . . . . . . . 74
5.2.1 Versão 0.70 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.2.2 Versão 0.71 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.3 Históricos de resultados . . . . . . . . . . . . . . . . . . . . . . . . 78
5.3.1 Local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.3.2 Remoto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6 CONSIDERAÇÕES FINAIS . . . . . . . . . . . . . . . . . . . . 81
6.1 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
REFERÊNCIAS BIBLIOGRÁFICAS . . . . . . . . . . . . . . . 83
14
1 Introdução
O acionamento de máquinas e equipamentos mecânicos por motores elétricos é um as-

sunto de grande importância econômica. Atualmente, a maioria dos motores encontrados
nos processos industriais tem alimentação trifásica, ou seja, alguns tipos de motores de
indução (assíncronos), motores síncronos e motores de ímã permanente [6].
A maior parte das aplicações usa a variação da velocidade do motor, que é ditada
pelos requisitos dos processos. Por muito tempo foram utilizados sistemas mecânicos e
motores de corrente contínua (CC) para oferecer a variação de velocidade necessária. Já
nos anos 60, com o advento de materiais semicondutores, esses paradigmas começaram a
mudar drasticamente. Contudo, foi a partir dos anos 80 que semicondutores de potência
fornecendo alto desempenho e confiabilidade foram desenvolvidos, permitindo o controle
eletrônico da velocidade dos motores [7].
No momento atual, um dos dispositivos mais utilizados para o controle e variação
de velocidade de motores é o inversor ou conversor de frequência. O inversor é um dis-
positivo que possibilita o controle preciso de torque e velocidade de motores, provendo
também uma maior eficiência energética e segurança no acionamento. Esses conversores
possuem, basicamente, uma entrada ligada à rede de energia e uma saída que é aplicada
ao dispositivo que deve ser controlado.
Além de dispositivos de potência, os inversores são produtos tecnológicos microproces-
sados. A unidade central de processamento (CPU) de um inversor de frequência pode ser
formada por um ou mais microprocessadores ou microcontroladores, dependendo do fa-
bricante [6]. Estes são os componentes que permitem o funcionamento geral do inversor:
armazenamento de informações (parâmetros e dados do sistema), comunicação e gera-
ção de pulsos de disparo para os IGBT’s (Insulated Gate Bipolar Transistors), que são
transistores utilizados para o chaveamento da transmissão de potência. A ferramenta que
promove a infraestrutura para o correto acionamento através do inversor é o seu firmware.
Ele pode ser compreendido como um conjunto de componentes computacionais que co-
mandam as funções lógicas da unidade de processamento do inversor. Com isso, também
se pode afirmar que os inversores consistem em sistemas embarcados, pois são sistemas
computacionais projetados para determinada aplicação.
Para que as funcionalidades de um inversor de frequência ocorram corretamente, esse
sistema embarcado deve ser desenvolvido adequadamente. Norteando-se por essa pre-
missa, o desenvolvedor do firmware deve garantir seu funcionamento ao final do projeto,
visando sua comercialização. Durante o desenvolvimento do dispositivo, testes de funci-
onalidades são realizados em cada parte do sistema a fim de garantir o sucesso de sua
performance final. Todavia, no desenvolvimento de inversores, geralmente não são rea-
Capítulo 1. Introdução 15
lizados testes de integração do sistema, o que pode gerar consequências como perda na
qualidade da estrutura final, atrasos na entrega do produto e retrabalhos.
1.1 Objetivos do projeto

Diante das ideias apresentadas anteriormente, a divisão de Pesquisa e Desenvolvimento
de Inversores de Baixa Tensão, do departamento de Drive Seriados da WEG Drives &
Controls (empresa pertencente ao grupo WEG), onde este projeto foi desenvolvido, tem
visado melhorar o processo de desenvolvimento do firmware embarcado no desenvolvi-
mento de uma nova linha de inversores de frequência.
Atualmente os desenvolvedores de software têm de lidar com grandes quantidades de
códigos computacionais e manutenção de aplicações [8]. No desenvolvimento dos novos
inversores ainda não se utilizam alternativas automatizadas para testar o produto de
forma integrada a partir do lançamento de novas versões. De forma breve, então, o
objetivo principal do projeto é conceituar e desenvolver um sistema capaz de realizar um
conjunto de testes automatizados no inversor, de forma antecipada ao lançamento de uma
nova versão do firmware. Através dos resultados dos testes seria possível centralizar as
informações relativas ao projeto em desenvolvimento em um banco de dados e controlar
os requisitos das versões a serem lançadas, garantindo maior confiabilidade do software
desenvolvido.
À frente disso tudo, pode-se dizer que, para alcançar o objetivo geral do projeto, os
objetivos específicos traçados são os seguintes:
1. Estruturar detalhadamente os testes a serem verificados;
2. Tomar ciência do estado atual do firmware do inversor;
3. Desenvolver um software embarcado para a realização dos testes;
4. Realizar testes integrados, que envolvem todas as partes do inversor;
5. Centralizar as informações de cada teste em um banco de dados;
6. Verificar erros e falhas inesperdas no firmware;
7. Integrar o projeto com interface gráfica de usuário.
1.2 A empresa WEG Equipamentos Elétricos

A WEG S.A. atualmente é uma empresa multinacional, de origem brasileira, no ramo
de equipamentos elétricos. Foi fundada na cidade Jaraguá do Sul, em Santa Catarina,
através da união de três sócios: Werner, Eggon e Geraldo.
Produzindo inicialmente motores elétricos, a WEG ampliou suas atividades a partir da

década de 80, com a produção de componentes eletroeletrônicos, produtos para automação
industrial, transformadores de força e distribuição, tintas líquidas e em pó e vernizes
eletroisolantes. A empresa se consolidou não só como fabricante de motores, mas como
fornecedora de sistemas elétricos industriais completos.
Hoje em dia a WEG produz soluções para diversos segmentos do mercado, oferecendo
produtos nas áreas de energia, motores, automação, transmissão e distribuição e tintas.
Para tal, a empresa conta com mais de 40 parques fabris, instalados por todos os conti-
nentes do globo. Além disso, a empresa possui outras 34 filiais comerciais e distribuidoras
em mais de 120 países [9].
O seu sucesso comercial pode ser consequência dos princípios que norteiam a empresa.
São eles:
• Missão: Crescimento contínuo e sustentável, mantendo a simplicidade;
• Visão: Ser referência global em máquinas elétricas, com ampla linha de produtos,
provendo soluções eficientes e completas;
• Valores: Companhia Humana, Trabalho em Equipe, Eficiência, Flexibilidade, Ino-

vação e Liderança.
Com expertise em diversas áreas de negócio, a WEG consolidou-se nos seguinte ofícios
[10]:
• Motores elétricos: possui uma completa linha de motores e caixas redutoras,

com altos níveis de eficiência. Sendo os principais produtos motores de indução,
síncronos, motores de corrente contínua e caixas de redução;
• Automação: Variedade completa de dispositivos elétricos eletrônicos para o apri-

moramento da produtividade. As soluções na área consistem em conversores, dis-
positivos de controle, painéis elétricos, dispositivos de segurança, sistemas de auto-
mação, tecnologias residenciais, capacitores, entre outros;
• Transmissão e distribuição: fornecimento de soluções envolvendo transformado-

res de força e distribuição, transformadores a seco e reatores de força;
• Energia: manufatura de máquinas grandes, como tubo e hidrogeradores, geradores

eólicos, geradores e turbinas a vapor. Já foram realizado diversos projetos impor-
tantes;
• Tintas e vernizes: produz uma linha extensa de tintas industriais, tintas em pó e

vernizes industriais, anticorrosivos e automotivos.
Diante do exposto, pode-se salientar que o projeto ocorreu no interior da área de

negócios dita automação, na divisão de desenvolvimento de drives de baixa tensão. Sendo
assim, se prossegue para a seção que aborda a estruturação do atual documento.
1.3 Estrutura do documento

Neste capítulo fez-se uma abordagem sobre a ideia geral, objetivos e justificativa do
projeto, assim como um resumo sobre a empresa onde o mesmo foi desenvolvido. Os
demais capítulos são resumidos abaixo.
• No Capítulo 2 são delineadas revisões, explicações e os fundamentos das tecnologias

importantes utilizadas para a realização deste trabalho;
• No Capítulo 3 é discutida a arquitetura generalizada do projeto, capítulo em que as

estruturas básicas do seu funcionamento e as tecnologias utilizadas são explicadas
de forma integrada;
• O Capítulo 4, sobre metodologia e implementação do projeto, apresenta de forma

mais detalhada como as tecnologias foram implementadas e utilizadas a fim de
promover o alcance dos objetivos propostos;
• O Capítulo 5 se refere aos testes e resultados obtidos segundo a arquitetura ela-

borada para o projeto. Detalhes mais significantes da implementação também são
evidenciados nesse capítulo;
• O Capítulo 6 se refere às considerações finais do projeto diante dos resultados ob-

tidos, partindo dos objetivos considerados. Nesse capítulo também serão discutidos
os possíveis trabalhos e implementações futuros a serem desenvolvidos a partir do
que foi realizado neste projeto.
18
2 Revisão das tecnologias utilizadas
Este capítulo aborda toda a base técnica e teórica utilizada para atingir os objetivos
propostos, mencionados na introdução deste documento. O mesmo é delineado seguindo
a ordem cronológica do emprego das tecnologias. Portanto, aqui serão tratados os con-
ceitos, definições e aplicações sobre inversores de frequência (Seção 2.1), importância dos
firmwares nos inversores (Seção 2.2), protocolo de comunicação HTTP (Seção 3), API
rest’s (Seção 4), Application Lifecycle Management (Seção 5), protocolo ModBus RTU
(Seção 6), linguagem Python (Seção 7), Importância e utilização de interface gráficas em
sistemas (Seção 8), Sistema embarcado utilizando Raspberry Pi (Seção 9), Jenkins (Seção
10) e trabalhos relacionados (Seção 11).
2.1 Inversores de frequência

O inversor - ou drive - de frequência é o objeto que motivou o desenvolvimento deste
projeto junto à WEG. De acordo com o que foi abordado no Capítulo 1 deste documento,
deve-se ressaltar que os inversores atualmente não são meros dispositivos de transmissão
de potência. Ao contrário disso, estes são aparelhos de potência computadorizados, que
oferecem uma gama de recursos ao usuário que os utiliza.
Antigamente se utilizavam motores CC para a obtenção de controle preciso de velo-
cidade em processos. Contudo, isso acarretava diversos problemas como elevado custo e
necessidade de retificação da tensão de entrada para alimentar o motor. Com o advento
da eletrônica de potência, aliada a necessidade de diminuição de custos e aumento da
produção, surgiu a automação. Nesse cenário, um grande número de equipamentos foi
produzido para as mais diversas finalidades dos setores industriais. Juntamente com o
CLP (Controlador Lógico Programável), o inversor de frequência é um dos dispositivos
de automação mais utilizado. Este dispositivo, versátil e dinâmico, permitiu o controle
de motores menores e com mesma performance que os CC [6]. Um exemplo de inversor é
o CFW500, da WEG S.A., ilustrado conforme a Figura 1.
Capítulo 2. Revisão das tecnologias utilizadas 19
Figura 1 – Inversor de frequência CFW500 da WEG S.A. [1]
O inversor trata-se de um produto em que o usuário pode configurar e visualizar

parâmetros, como os de variação de velocidade, frequência do motor e tempos de rampa
de aceleração, assim como permitir visualização em tempo real e armazenamento dessas
informações para uso futuro. Sendo assim, além do seu principio básico de funcionamento,
o inversor possui uma central de processamento e, opcionalmente, uma interface homem
máquina (HMI), onde o usuário pode enviar comandos e receber informações pertinentes
ao motor.
Com todos os aspectos observados até aqui, se torna trivial inferir sobre a importância
desses dispositivos nos processos industriais. Atualmente estima-se que dois terços do
consumo de eletricidade nas indústrias seja através dos motores elétricos. Para tanto,
os mesmos são utilizados em diversas aplicações. A Figura 2 apresenta um gráfico com
estimativa do percentual de consumo que representa o tipo de máquina elétrica utilizada
nas indústrias [2].
Figura 2 – Estimativa de uso de máquinas elétricas na indústria [Fonte: Franchi [2]].

Dando continuidade ao estudo sobre os inversores, dispositivo de fundamental impor-

tância para este projeto, segmenta-se ainda este capítulo em alguns tópicos necessários,
conforme Seções 2.1.1 (princípios básicos), 2.1.2 (unidade central de processamento), 2.1.3
(interface homem-máquina), 2.1.4 (parametrização) e 2.1.5 (protocolos de comunicação
em inversores).
2.1.1 Princípios básicos

Com avanços sucessivos na eletrônica de potência, os inversores possuem a sua parte
de controle composta, majoritariamente, por transistores do tipo IGBT, um transistor bi-
polar de porta isolada. Seu princípio básico de controle consiste na variação da frequência
de entrada (linha de alimentação) através de conversores de frequência. Esses conversores
possuem três etapas: retificador, controle do circuito e saída. Cada parte é explicada
brevemente abaixo.
1. Retificador: por normas nacionais, a tensão fornecida na rede oscila em 60Hz

(entrada Vca conforme a Figura 3), sendo transformada pelo retificador em um
tensão contínua (Vcc conforme a Figura 3) pelo circuito chamado de retificador de
onda completa. A dinâmica da tensão de saída referente a esta etapa do inversor é
ilustrada conforme a Figura 3.
Figura 3 – Retificador do inversor [Fonte: Franchi [2]].
2. Controle: a tensão contínua gerada na saída do retificador é conectada a saída

dos terminais de transistores que têm seu controle de chaveamento comandado por
um microprocessador, o que torna esta etapa extremamente confiável. Atualmente
existem alguns tipos de controle consolidados, como o controle escalar e o vetorial.
Nesta etapa a tensão contínua derivada do retificador é chaveada e transformada
em um sinal alternado, conforme a ilustração da figura Figura 4.
Figura 4 – Saída de controle do inversor [Fonte: Franchi [2]].

3. Saída: com a parte de controle consolidada é possível estabelecer a tensão de saída

para o motor desde o sinal contínuo de saída do retificador e transformada em um
sinal alternado por meio do chaveamento promovido na etapa de controle. Dentre
outras coisas, este fato sugere uma independência do conversor quanto à rede de
alimentação em que está conectado, fato que permite com que o mesmo possa ul-
trapassar a frequência nominal da rede. A saída resultante do inversor é um sinal
senoidal.
Por intermédio da união das três etapas do drive, é estabelecido um conversor de

frequência que pode ser aplicado a um motor de indução trifásico, aspecto detalhado
conforme a Figura 5.
Figura 5 – Inversor aplicado a um motor de indução trifásico [Fonte: Franchi [2]].
Para fornecer controle e energia necessários para a realização das etapas mencionada
acima, o inversor pode ser abstraído em alguns blocos de componentes independentes. Os
mesmos são ilustrados conforme a Figura 6.
Figura 6 – Blocos de componentes do inversor [Fonte: Franchi [2]].
Alguns desses blocos são discutidos com mais detalhes nas próximas seções deste ca-
pítulo, de acordo com sua importância para o projeto. É necessário salientar que as
particularidades envolvendo a parte eletrônica do inversor são suprimidas neste trabalho,
pois não houve a necessidade de realizar cálculos embasados em seus aspectos físicos. Isso
deve-se ao fato de que a dinâmica fornecida pelo inversor foi apenas aplicada, sem levar em
conta maiores detalhes. Dentre os componentes essenciais do dispositivo, deve-se ressaltar
um maior envolvimento da unidade central de processamento, interface homem-máquina,
parametrização, firmware e protocolos de comunicação, conceitos expostos a seguir.
2.1.2 Unidade central de processamento

A CPU de um inversor de frequência pode ser formada por um ou mais micropro-
cessadores ou microcontroladores, dependendo do fabricante. É nesse bloco que estão
as informações mais importantes do sistema, como parâmetros de entrada, informações
armazenadas e comando de geração de pulsos para os transistores [6]. Além disso a CPU
promove o estabelecimento de redes de comunicação, que permite interconectar o inversor
com outros dispositivos.
Para o atual projeto, a CPU consiste em um componente fundamental, pois os testes
se baseiam no seu funcionamento. É na CPU que toda a infraestrutura do firmware do
inversor é gravada e operada. Portanto, o seu bom funcionamento é essencial para garantir
que todas as funcionalidades do drive ocorram sem problemas durante sua utilização.
2.1.3 Interface homem-máquina

Usualmente chamada de IHM ou, em inglês, HMI (Human Machine Interface), é um
dispositivo que permite visualizar o que está acontecendo no inversor através de uma tela
(ou display) e parametrizá-lo de acordo com a aplicação em que o inversor está sendo
utilizado.
Através dela é possível acessar visualmente as diferentes grandezas do motor, como
tensão, corrente, frequência, falhas, entre outras. Além disso, é uma ferramenta que
permite comandar o desligamento e ligamento do inversor e variar sua velocidade através
da mudança de parâmetros.
Na Figura 7 tem-se o detalhe da IHM remota do inversor CFW500, desenvolvido pela
WEG S.A.
Figura 7 – IHM do CFW500 da WEG S.A. [3]
Para este projeto o seu uso foi necessário para observar o delineamento dos testes
executados sobre o motor. A IHM foi utilizada para verificar a dinâmica de algumas
grandezas físicas em forma numeral ou a partir de gráficos.
2.1.4 Parametrização
Geralmente os inversores possibilitam ao usuário interagir e manipular algumas va-
riáveis que permitem ajustar o funcionamento do aparelho para determinada aplicação.
Nessas ferramentas, as variáveis são chamadas de parâmetros.
Assim, os parâmetros são usados para executar as funções do inversor e os mesmos são
alocados na CPU através do firmware. Os principais tipos de parâmetros de um inversor
são:
• Parâmetros de leitura: variáveis que podem ser visualizadas no display, mas não
podem ser alteradas, como, por exemplo, tensão (%), corrente (%) e potência ativa.
• Parâmetros de regulação: são valores ajustáveis a serem utilizados pelas funções

do inversor de frequência, como tensão inicial, tempo de rampa de aceleração e
desaceleração, entre outros.
• Parâmetros configuração: parâmetros que definem as características do inversor,

funções a serem executadas, entradas e saídas (analógicas e digitais), etc.
• Parâmetros do motor: valores que indicam as características nominais do motor a

ser utilizado, como, por exemplo, corrente do motor e fator de serviço.
Dependendo do fabricante, cada tipo de configuração pode possuir diversos tipos de

parâmetros. Nos inversores da WEG, os parâmetros possuem nomenclatura padrão, onde
o caractere ”P” é seguido por um identificador numérico. A Tabela 1 apresenta alguns
exemplos de parâmetros presentes nos inversores WEG e seus identificadores.
Tabela 1 – Exemplos de parâmetros do motor e inversor
Nome Identificador Parâmetro

Referência de velocidade 1 P0001
Velocidade do motor 2 P0002
Corrente do motor 3 P0003
Tensão do link DC 4 P0004
Frequência do motor 5 P0005
Fonte – do Autor
Outros parâmetros comumente implementados nos inversores são aqueles que contro-
lam a dinâmica dos motores. Neste trabalho, por exemplo, utilizaram-se os controles do
tipo V/f e VVW. O tipo V/f controla de forma escalar a razão entre tensão e frequência
do motor a partir de valores programados. Já o VVW (Voltage Vector WEG) é, de forma
resumida, um controle do tipo vetorial desenvolvido pela WEG.
Nos inversores a parametrização é feita através de alguns protocolos de comunicação,
que serão tratados posteriormente neste capítulo, ou através de sua IHM, dependendo
apenas de requisitos de projeto e recursos disponíveis.
No caso deste projeto, trataremos mais adiante, na etapa de desenvolvimento dos
testes (Capítulo 4), o ajuste de parâmetros através de um protocolo de comunicação
chamado ModBus, muito utilizado em chão de fábrica. Parâmetros como os mencionados
na Tabela 1 e alguns outros parâmetros importantes para o desenvolvimento do projeto
serão discorridos posteriormente.
2.1.5 Protocolos de comunicação em inversores

Na década de 1960, em algumas indústrias e laboratórios, existiam mainframes (com-
putadores de grande porte) e terminais onde os usuários conseguiam realizar cálculos e
algumas outras funções que geralmente demoravam a retornar os resultados previstos.
Neste caso, o computador era a central de dados e o terminal poderia ser utilizado para
manipulá-los ou programá-los de maneira remota. Diante dessa simples ação, o início do
uso de técnicas de redes de comunicação estava marcado.
Assim como hoje, a comunicação entre os dispositivos incluía os seguintes requisitos
[11]:
• Uma interface (serial ou paralela);
• Unidade de informação (bit);
• Definição de código para representar letras e números;
• Definição de um protocolo para envio, recepção e detecção de falhas.

Nos anos 70 surgiram os primeiros microprocessadores, fazendo com que o custo de

computadores diminuíssem. Com isso, a velocidade de processamento aumentou e aplica-
ções mais complexas foram desenvolvidas.
Nesse cenário se percebeu que computadores integrados seriam mais rápidos que a
utilização de mainframes. O desenvolvimento de técnicas de interconexão era crescente,
com o aval de empresas que desejavam o compartilhamento de seus dados e recursos. Os
primeiros setores informatizados foram o financeiro e o de recursos humanos. Posterior-
mente, então, partiu-se para a informatização do chão de fábrica. Os primeiros métodos
de comunicação foram marcados pelo uso de fita K7, cartões perfurados, entre outros.
Ainda segundo Stemmer (2010) [11]:
"[...] para melhorar este ambiente de comunicação era necessário considerar to-
pologias de rede apropriadas para o chão de fábrica. Uma comunicação ponto
a ponto, por exemplo, poderia ser inviável se uma máquina falhasse. Deve-
ria se considerar o ambiente, muitas vezes hostil, tempo de resposta crítico,
segurança de dados crítica e grande quantidade de equipamentos."
Nos anos 80, então, a ideia era definir uma rede única, que poderia ser utilizada
em todos os setores de uma fábrica. Essa ideia não vigorou e acabou não entrando em
conformidade com o paradigma atual de redes de comunicação. No presente, ocorre, na
comunicação empresarial, uma divisão da rede em sub-redes. Isso se torna viável, pois
os tipos de dados utilizados em uma empresa pode variar muito de acordo com o nível
hierárquico de sua integração fabril.
Visto a necessidade da implantação de redes de comunicação de chão de fábrica que
satisfizessem os requisitos necessários para uma boa operabilidade, varias tentativas de
padronização ocorreram.
O paradigma atual das redes de comunicação industriais reside no uso de tecnologias
que variam seus protocolos de comunicação. Por definição, um protocolo é um conjunto
de regras sobre como sobre a comunicação entre os elementos de uma rede industrial
e sua escolha depende da aplicação. Por exemplo, para um inversor se comunicar com
um computador, com um HMI ou com algum dispositivo de chão de fábrica como um
controlador lógico programável, ambos devem ser amigáveis com o mesmo protocolo.
Podem ser citados como os protocolos atuais mais utilizados em inversores de frequên-
cia:
• DeviceNet: DeviceNet é uma rede de baixo nível que proporciona comunicações

utilizando o mesmo meio físico entre dispositivos, é pouco custosa e possui protocolo
aberto [12].
• Profibus: O Process Field Bus é um protocolo desenvolvido pela Siemens, que

se utiliza de cartões de controle, para conectar os CLP’s, computadores e outros
aparelhos ao barramento de sensores e atuadores. Hoje, ele é um padrão aberto de

rede. Em outras palavras, ele é livre e independente de fabricantes, podendo ser
usado por qualquer um [13].
• Profinet: O Profinet é um padrão de automação da associação PROFIBUS interna-

cional para implementação e integração de soluções baseadas em Ethernet industrial.
Ele suporta a integração de um simples dispositivo digital de campo a aplicações
de tempo crítico (real time) complexas, bem como a integração de automação de
manufatura baseadas em componentes [14].
• ModBus: O ModBus é um protocolo de comunicação de dados utilizados em sis-

temas de automação. Foi criado em 1979 e continua sendo um dos protocolos mais
utilizados em CLP’s desde então [15]. Em inversores de frequência, o modelo mais
utilizado de comunicação é o RTU (Remote Terminal Unit).
• Ethernet/IP: O Ethernet/IP é uma rede Ethernet industrial padronizada pela

ODVA e baseia-se na arquitetura encapsulada do TCP/IP. O termo IP significa
“Industrial Protocol” e não deve ser confundido com o protocolo IP da suíte de
protocolos TCP/IP [16].
• CAN: O Controller Network Area (CAN) é um protocolo de comunicação serial

que suporta o controle sistemas de tempo real provendo um alto grau de segurança.
Muito utilizado em automóveis para o fluxo de informações dos veículos, atualmente
o protocolo é adotado pela indústria, tendo em vista sua robustez e confiabilidade.
• BACnet: Building Automation and Control Networks (BACnet) é um protocolo

de comunicação que vem sendo utilizado para automação predial e domótica desde
1995, quando foi criado [17].
Na operação de verificação de testes proposta neste trabalho, decidiu-se optar pelo

protocolo ModBus RTU, devido à sua flexibilidade. Este é um dos mais antigos proto-
colos usados em redes industriais para aquisição de sinais de instrumentos e comando
de atuadores através de portas seriais. Pelo fato de ser um protocolo aberto, é utili-
zado em milhares de equipamentos e é uma das soluções mais economicamente viáveis em
automação industrial [18].
2.2 Importância dos firmwares nos inversores

Atualmente, uma série de dispositivos eletrônicos estão disponíveis possuindo fun-
cionalidades intrínsecas. Aparelhos de televisão, celulares e computadores podem ser
exemplos de sistemas usados no cotidiano que dependem de sensores, atuadores e outros
componentes periféricos para serem operados. Segundo Gajjar [19]: "[...] para que o uso
de tais dispositivos ocorra de maneira coerente, recursos dos seus softwares associados
devem ser devidamente acessados e interpretados."
Este software, que age como uma interface entre o hardware e o usuário, é chamado
de firmware.
Neste campo, como foi mencionado anteriormente, também estão os inversores. Eles
são uma gama de equipamentos computadorizados, pois possuem microprocessadores,
que têm sua lógica comandada por um firmware. Este pode ser operado de maneiras
diferentes, variando de modelo e fabricante.
Para se obter um firmware de alta performance para o inversor, é necessário dispor de
boas práticas de programação. Uma prática comum na industria é a reusabilidade. Isso
está fundamentado na necessidade de aproveitar ao máximo o tempo despendido no seu
desenvolvimento, e de evitar que seja gasto tempo desenvolvendo diversas vezes trechos
de código com funcionalidades similares [20].
Este pode ser um aspecto conveniente no desenvolvimento de firmwares, todavia exis-
tem algumas contrapartidas. Algumas informações atuais indicam que praticamente me-
tade da estrutura geral de um inversor de frequência é composta por trechos de códigos
computacionais programados em suas unidades de processamento.
Isso sugere que, se ocorrerem erros em termos de programação computacional, o de-
senvolvimento do inversor pode sofrer atrasos desnecessários, utilizar recursos de uma
maneira não otimizada e causar prejuízos para as empresas fornecedoras e para seus con-
sumidores e clientes.
Assim é trivial assumir que o firmware é o tema central do projeto. O desenvolvimento
de um projeto que visa a verificação intensiva de testes do software do inversor aliado a
uma geração de histórico de falhas e êxitos pode ser um método de garantia de qualidade
interno. Portanto, essas são ações que possibilitam a minimização de adversidades no
projeto dos equipamentos, como erros de programação, atrasos e utilização ineficiente de
recursos, tanto financeiros quanto humanos, pela equipe.
2.3 Protocolo HTTP

O HTTP (Hypertext Transfer Protocol) é um protocolo que define padrões e regula-
menta a troca de informações entre servidores que hospedam sites, computadores e outros
sistemas informacionais. Segundo Tim Berners-Lee (et al., 1996) [21]:
"[...] o HTTP é um protocolo de camada de aplicação que possui clareza e

velocidade necessária para sistemas de informação distribuídos, colaborativos
e de mídia. O protocolo vem sendo utilizado na Web desde o início dos anos
90, na sua versão 1.0."
O propósito original do HTTP, criado por Tim Berners, também criador da World
Wide Web, foi a de compartilhar informações na Web de maneira descomplicada. Em
1991, Tim delineou as motivações do uso de seu protocolo: ter capacidade de transferência
de arquivos, habilidade de requisição de dados no formato de hipertexto, negociação do
formato dos arquivos e a habilidade de remeter ao cliente outro servidor. Para comprovar
o conceito idealizado, um protótipo foi feito utilizando algumas dessas características:
• A solicitação do cliente é uma mensagem representada por um caractere do tipo

ASCII;
• A solicitação é terminada por intermédio de uma resposta do servidor;
• A resposta do servidor é a transmissão de um caractere ASCII em formato HTML;
• A conexão é finalizada com a transferência completa do arquivo.
Com tais aspectos o sistema se mostrava viável, pois estava em conformidade com
protocolos Telnet, muito utilizados na época. Assim nascia a primeira versão do HTTP,
o HTTP 0.9.
Diante do que foi desenvolvido em 1991, o HTTP sofreu uma evolução rápida e cons-
tante até chegar em sua versão 1.0, em que não se compartilhava apenas documentos de
hipertexto, mas arquivos que ofereciam dados mais ricos. Assim, um crescente número
de desenvolvedores Web começaram a produzir diversos servidores e clientes experimen-
talmente para perceber se outros usuários adotariam o protocolo. Desde então, vários
padrões de uso e desenvolvimento do HTTP foram criados.
Com as várias tentativas de padronização, enfim chegou-se à versão 1.1, em 1997,
quando o protocolo se tornou um padrão oficial para utilização na internet. Muitos pro-
blemas ainda vinham sendo encontrados, o que fazia com que várias atualizações fossem
feitas. Até 1999, então, muitas otimizações aconteceram como: comunicações mais está-
veis, transferência fragmentada de dados, requisições por tamanho de bytes, solicitações
múltiplas ao servidor, entre outras.
Com muitas coisas acontecendo na internet, como novos tipos de dados, novos tipos
de dispositivos de informação e velocidade de transmissão mais aceleradas, chegou-se à
versão mais atual do HTTP, a versão 2.0, sendo focada em melhorias na performance da
transmissão dos dados.
2.3.1 Funcionamento e aplicação no projeto

De forma generalizada, o HTTP é um protocolo que funciona através da manipulação
de requisições de usuários feitas ao servidor que opera segundo este protocolo. Essas
requisições são chamadas de métodos ou verbos HTTP. Os principais verbos do protocolo
são listados abaixo.
• GET: utilizado para obter informações HTTP;
• PUT: realiza upload de informações HTTP;
• DELETE: exclui informações HTTP;
• POST: cria novos recursos HTTP.
Com esse métodos é possível manipular uma grande gama de recursos (ou tipos de
dado) como JSON, XML, HTML e CSV. No projeto a ideia de utilização de servidores
HTTP serve para aplicar métodos sobre uma API de gerenciamento de testes, o Appli-
cation Lifecycle Management (ALM), abordado posteriormente na Seção 2.4.1. A mani-
pulação dos seus dados é feita através da conversação entre o endereço virtual do ALM e
um algoritmo feito na linguagem Python, que utiliza seus recursos. Isso torna possível o
gerenciamento e geração de históricos de resultados dos testes realizados sobre o inversor.
2.4 API rest’s

Do inglês, Application Programming Interface, ou interface de programação de apli-
cação, é um conjunto de rotinas e padrões estabelecidos por um software ou programa
de computador para a utilização de suas funcionalidades por outros aplicativos que não
devem se envolver nos detalhes de sua implementação.
Um API oferece recursos utilizáveis somente por programação. Um exemplo disso,
nos Sistemas Operacionais (SO), é a existência de API’s que permitem a criação de ja-
nelas, botões, acessar arquivos, entre outros recursos. Contudo, uma API é distante de
tarefas essenciais, como manipulação de memória do computador e alocação de recursos,
funcionalidades que são implementadas exclusivamente pelo SO.
Nesse âmbito de acessar recursos de outros aplicativos por meio de um software, en-
tão, surgiu o que se chamam de API rest’s ou API request’s. API rest é um estilo
de arquitetura de comunicação comumente usadas no desenvolvimento de aplicações de
WEB services. Os requests (requisições, em português), nesse caso, são independentes e
geralmente baseados no protocolo HTTP.
O API rest utilizado no projeto foi o módulo requests implementado e utilizado na
linguagem Python. O mesmo promove toda a estrutura para estabelecer comunicação em
HTTP com o Application Lifecycle Management, ferramenta empregada para gerenciar
os testes realizados sobre o inversor e gerar o histórico dos seus resultados.
2.4.1 Application Lifecycle Management (ALM)

No presente, os projetistas de software lidam com o desenvolvimento e manutenção de
uma larga e complexa escala de sistemas. Por esse motivo, muitos modelos de ciclo de
vida de produto foram introduzidos para definir diferentes tipos de ciclo de atividades,
focando em diferentes objetivos. Objetivos tais como requisitos de engenharia, design,
desenvolvimento e testes. A separação das atividades nesses modelos de ciclo de vida
auxiliam o processo de gerenciamento do projeto [8]. Em termos didáticos o tempo de
vida de um software tem seu modelo de ciclo de vida aproximado conforme a ilustração
da Figura 8.
Figura 8 – Modelo do ciclo de vida de um software.
Paralelamente a essa ideia, ferramentas que auxiliam no gerenciamento de produtos

e softwares têm surgido e se mostrado uma opção interessante para separar as ativida-
des de um projeto. Uma dessas ferramentas de gerenciamento é o Application Lifecycle
Management, desenvolvido pela HP e MicroFocus.
O ALM ou, em português, Gerenciamento de Ciclo de Vida do Software é um padrão de
gestão de projetos que especifica, desenha, desenvolve e testa a aplicação de um software.
Além da gestão de projetos, o sistema gerencia as requisições, o desenvolvimento e permite
a garantia de qualidade do programa.
O tempo de vida de um projeto pode ser definido como o período entre seu início e seu
fim. O ALM pode ser definido como um processo voltado para a coordenação e avaliação
das atividades necessárias durante esse ciclo de vida do produto ou software [22].
Através da utilização contínua do ALM, o desenvolvimento de um projeto pode alcan-
çar benefícios como:
• Acompanhamento e medição de índices de performance;
• Gerenciamento centralizado de processos e fluxos de tarefas;

• Ganho de visibilidade dos recursos do software;
• Aumento de comunicação entre os desenvolvedores da aplicação.
Neste projeto, o ALM foi usado como padrão de gerenciamento do testes realizados no
firmware do inversor através das funcionalidades de criação de requisitos e planos de testes
e utilização do protocolo HTTP para manipular informações e gerar um histórico completo
de resultados que podem ser acessados localmente ou remotamente pelos integrantes da
equipe de desenvolvimento de software.
2.5 Protocolo ModBus RTU

O ModBus é um protocolo de comunicação de dados utilizados em sistemas de auto-
mação. Foi criado em 1979 e continua sendo um dos protocolos mais utilizados em CLP’s
desde então. Em inversores de frequência, o modelo mais utilizado de comunicação é o
RTU (Remote Terminal Unit) [15].
O modelo RTU do ModBus é um protocolo empregado para desenvolver comunicações
do tipo mestre/escravo (usualmente mater/slave) ou cliente/servidor entre dispositivos
inteligentes. A partir dessa comunicação, interfaces do tipo RS-232, RS-422, RS-485 e
Ethernet podem ser usadas como camada física, dependendo das especificações da mesma.
O RS-232 é um cabo que oferece comunicação com topologia do tipo duplex, em que o
dispositivo pode transmitir e receber dados ao mesmo tempo. Já o RS-485, igualmente
ao padrão Ethernet, é uma camada física do tipo half-duplex, onde dados podem ser
transmitidos e recebidos um após o outro. Esses meios físicos variam entre si em aspectos
como a taxa de transmissão de dados.
Para o funcionamento do protocolo a camada física é responsável pelo endereço do
dispositivo escravo, bits de início e fim, código CRC (código para detecção de erros),
time out. Em adição à isso existe também a camada de dados, responsável pela função
de rejeitar ou aceitar mensagens, reposicionar dados e manter a comunicação em estado
ocupado (usualmente, busy). Neste protocolo, a mensagem possui tamanho de 32 bits do
tipo ponto flutuante ou inteiro. Para estabelecer comunicação, o dispositivo mestre envia
uma pergunta ao dispositivo escravo, que responde de acordo com o que foi recebido [4].
Um detalhe dos tipos e tamanho de dados ModBus de um dispositivo é ilustrado conforme
a Figura 9.
Figura 9 – Formato de mensagem do protocolo ModBus RTU.

Diante do que foi discutido anteriormente, pode-se afirmar que os dados do disposi-
tivo escravo podem ser lidos por um mestre (computador), através do protocolo. Para
a comunicação ser estabelecida o escravo tem um endereço próprio, que é acessado pelo
mestre. A partir disso, dados referentes ao escravo podem ser lidos ou escritos. Estes
também possuem endereçamento próprio, com tamanho variável de informações. Em ter-
mos visuais, a troca de mensagens entre os dois dispositivos pode ser detalhada conforme
a Figura 10.
Figura 10 – Exemplo de troca de mensagens entre mestre e escravo com ModBus RTU
[Fonte: Adaptado de Tamboli et al. [4]].
Com as características mencionadas do protocolo, pode-se dizer que a sua implementa-

ção física e lógica não oferecem muitas dificuldades, pois não necessitam muitos recursos.
Tais qualidades foram essenciais para o sua utilização no presente projeto. Tendo em
vista a topologia de comunicação promovida pelo ModBus, no projeto foram utilizados
computadores como mestres e inversores como escravos, conectados entre si através de
uma interface padrão Ethernet. Algumas particularidades das implementações e metodo-
logias adotadas em termos dessa comunicação são discutidas no decorrer do documento,
nos Capítulos 3 e 4.
2.6 Linguagem Python

A linguagem de programação Python foi criada pelo holandês Guido Von Rossum,
influenciado pelas linguagens SETL e ABC, sendo iniciada no fim de 1989. O Python
é um exemplo de linguagem de alto nível, como Perl e Java, por exemplo. Além desse
paradigma, existem linguagens de baixo nível, também chamadas de linguagens montagem
ou "linguagens assembly".
O fato é que os computadores executam apenas programas escritos em linguagem

de máquina. Sendo assim, o programa escrito em alto nível deve ser interpretado e
compilado nos momentos prévios à sua execução. Contudo, suas vantagens são enormes.
Primeiramente, a programação é muito mais simples, curta e clara. Além disso, pode-se
dizer que essas linguagens são portáteis, ou seja, elas podem ser executadas em diferentes
tipos de computadores sem sofrer muitas alterações. Programas escritos em linguagens
de baixo nível devem ser reescritos quando executados em sistemas diferentes [23].
Em outras palavras, algumas características essenciais que tornam o Python uma
linguagem de alto nível são mencionadas abaixo [24].
• Pode ser utilizada para o desenvolvimento de programas convencionais ou Web;
• Pode ser estendida para as linguagens C ou C++;
• Tem sua estrutura construída de forma consistente (apresenta classes, módulos e

pacotes);
• Possui estruturas de controle usuais com if, if-else, if-elif, while e uma coleção abran-
gente de operadores para a estrutura for;
• Tem suporte para programação orientada a objetos.
Uma das características mais importantes desta linguagem atualmente é a quanti-

dade de recursos existentes, desenvolvidos por meio de uma comunidade ativa. Várias
bibliotecas com diferentes funcionalidades visam tornar o uso da linguagem ainda mais
simples.
Nos últimos tempos a utilização do Python em áreas como a de visão computacional,
ciência de dados e aplicações web tem sido cada vez mais crescente. De acordo com o
site GitHub [25], a linguagem aparece em segundo lugar de um ranking que apresenta as
linguagens de programação mais utilizadas em códigos abertos na plataforma.
No caso deste projeto, o Python foi fundamental. A linguagem oferece estruturas
lógicas para consolidar a utilização de interface gráfica de usuário, promover a comuni-
cação via protocolo ModBus através de uma biblioteca chamada pymodbus, que oferece
todos os recursos necessários para transmitir, decodificar e receber dados seriais através
de dispositivos que utilizam o protocolo. Além disso, foi utilizada a biblioteca requests,
presente na biblioteca oficial do Python. Tal biblioteca permite ao usuário carregar e
enviar dados HTTP utilizados na maioria dos sites presentes na rede. Isso torna possível
a geração remota de histórico de resultados dos testes com a manipulação de dados do
ALM, ferramenta fundamentada anteriormente, no Capítulo 3.
2.7 Importância e utilização de interfaces gráficas em

sistemas
Em computação, a interface gráfica do usuário (abreviadamente "GUI", do inglês
Graphical User Interface) é um programa que permite a interação com dispositivos digitais
por meio de elementos gráficos como ícones e outros indicadores visuais, em contraste a
interface de linha de comando. Foi criada pela Xerox, mas somente se tornou um produto
através da Apple [26].
A interação promovida por um GUI se realiza, geralmente, por meio de mouse, teclado
ou cliques na tela (em smartphones, por exemplo), capacitando o usuário a selecionar
ícones ou símbolos do sistema operacional a fim de obter resultado prático. Nesse cenário,
os símbolos são chamados de widgets e são agrupados em kits.
Um ambiente gráfico é um software feito para facilitar e tornar prática a utilização do
computador por meio de representações visuais do sistema operacional. Pode-se dizer que
o tempo para a criação de novas soluções é reduzido através de uma boa implementação
da interface gráfica em um sistema. Assim, quão mais rápidas novas soluções são criadas,
mais facilmente elas são levadas aos usuários, tornando o processo de design de uma GUI
mais efetivo [27].
Em 1983, Buxton demonstrou que a maior parte dos problemas de design de interfa-
ces gráficas poderiam ser contornados através do redesenho da mesma ao invés de utilizar
linhas de código [28]. Com isso, linguagens como Visual Basic tornaram possível a par-
ticipação de pessoas com os mais diferentes níveis de habilidades no desenvolvimento de
uma interface de usuário. Assim, pode-se prever que, para a criação de interfaces gráficas,
é necessário não apenas o papel do programador, mas também o auxílio de profissionais
como designers, por exemplo.
Em oposição ao GUI existe o CLI (Command Line Interface), ou, em português,
interface de linha de comando. Em muito casos o CLI pode ser mais fácil e rápido
para acessar recursos computacionais, visto que os mesmos são traduzido em linhas de
comando. Contudo, uma GUI bem feita pode proporcionar uma experiência simples e
eficaz ao usuário de sistemas operativos. Para estabelecer uma comparação entre os dois
tipos de interface, na Figura 11 apresentam-se um exemplo de GUI e um exemplo de CLI.
(a) Exemplo de um CLI escrito em bash. (b) Exemplo de um GUI.
Figura 11 – Exemplo de um GUI e um CLI.
Como se percebe conforme a Figura 11, o CLI se trata de uma interface mais simples,
geralmente relacionado com usuários mais experientes, pois o mesmo deve conhecer bem
o sistema operativo para operá-lo nas linhas de comando. Em contradição a isso, o
GUI é uma interface geralmente rica em objetos, que fornece ao usuário informações e
ferramentas visuais para uma operação mais acessível do sistema.
A partir do cenário envolvendo o uso de interfaces em aplicações de computador, fez-se
o estudo de que a implementação de uma interface gráfica de usuário para o projeto traria
alguns benefícios. A operação principal de execução de testes e outras funcionalidades do
projeto se tornariam mais práticas e desenvolvedores ou usuários leigos em programação
poderiam utilizar o projeto de maneira mais acessível.
2.8 Sistema embarcado utilizando Raspberry Pi

Neste trabalho também foi utilizado o conceito de sistemas embarcados no desen-
volvimento do software para a verificação de testes nos inversores de frequência. Para
tanto, esse fato demanda o conhecimento básico acerca desse sistema e qual foi a forma
de realizá-lo. Portanto, esta seção está segmentada em duas partes: a de Conceito de sis-
temas embarcados (Seção 2.8.1) e a de Raspberry Pi e sua importância no projeto (Seção
2.8.2) .
2.8.1 Conceito de sistemas embarcados

Os sistemas embarcados muitas vezes podem ter uma definição confusa. De forma ge-
ral, sistemas embarcados são sistemas de computador dedicados, podendo ser distinguidos
de outros sistemas como computadores pessoais ou supercomputadores.
Para tornar a definição mais clara, pode-se dizer que os sistemas embarcados são mais
limitados fisicamente (ou em hardware) que um computador pessoal, sendo projetados
para executar tarefas específicas [29].
Na atualidade muitos dispositivos eletrônicos podem ser classificados como sistemas

embarcados e, por ser um conjunto muito vasto de equipamentos, não existe uma definição
que abrange a todos. Exemplos de sistemas embarcados amplamente usados são exibidos
conforme a Tabela 2.
Tabela 2 – Exemplos de sistemas embarcados e seus tipos de mercado.
Mercado Sistemas
Automobilístico Ignição, controle de motor e sis-
tema de freios.
Eletroeletrônicos Televisões, DVD’s, Videogames,
brinquedos, refrigeradores, telefo-
nes, celulares, câmeras, entre ou-
tros.
Medicina Bombas de infusão, máquinas de
diálise, monitores cardíacos, entre
outros.
Indústria Sistemas robóticos
Redes Roteadores, Hubs e Gateways.
Automação de escritório Impressora, Fax, monitores, scan-
ners, entre outros.
Fonte – NOERGAARD, 2013 [29].
Para que o sistema funcione corretamente, de acordo com suas aplicações, deve-se
considerar algumas características durante o seu projeto. Um sistema embarcado, de
forma geral, é constituído pelos seguintes componentes e suas atribuições básicas [30].
• Processador: deve ser escolhido de forma a promover a velocidade necessária para

o sistema realizar suas tarefas. Deve-se levar em conta o tamanho e complexidade
das tarefas executadas.
• Memória: é uma parte importante do sistema e é influenciada fortemente pela ar-

quitetura do software embarcado. É o componente que promove o armazenamento
das informações para a inicialização e execução das tarefas contidas no sistema.
• Periféricos: um sistema embarcado deve se comunicar com outros dispositivos de

fora. O que permite isso são os periféricos. Periféricos podem ser sensores, saídas
de áudio, vídeo, conexões, entre muitos outros dispositivos. A maioria dos peri-
féricos são baseados em saídas binárias, seriais, valores analógicos, telas e saídas
dependentes de tempo.
• Software: os componentes de software agregam boa parte do valor do sistema em-

barcado. É o aspecto que define o que o sistemas faz, assim como a sua performance.
• Algoritmos: os algoritmos são as peças-chave do software. São códigos e comandos

que permitem o software exercer suas tarefas. Basicamente, o algoritmo processa
matematicamente as informações externas de forma a interpretá-las e gerar sinais
de controle, usados pelo sistema.
Sistemas embarcados, então, podem ter sua arquitetura baseada em microprocessado-

res, microcontroladores ou placas de desenvolvimento prontas, como o Raspberry Pi.
2.8.2 Raspberry Pi e sua importância no projeto

O Raspberry Pi diz respeito à uma linha de minicomputadores criados para diminuir o
custo da computação e tornar a programação acessível para um público mais abrangente.
Com o seu lançamento bem sucedido em 2012, atualmente existem desenvolvedores no
mundo focados no desenvolvimento de novas aplicações e dispositivos dedicados ao uso
da placa [31].
Apesar de possuir pequeno porte, o dispositivo é um microcontrolador potente, dis-
pondo um hardware complexo. O modelo de placa utilizado no projeto é o 3B+, que
possui as especificações técnicas citadas abaixo e é ilustrado conforme a Figura 12.
• Processador Broadcom BCM2837B0, Cortex-A53 (ARMv8) 64-bit SoC @ 1.4GHz;
• 1GB LPDDR2 SDRAM;
• 2.4GHz e 5GHz IEEE 802.11.b/g/n/ac wireless LAN, Bluetooth 4.2, BLE;
• Gigabit Ethernet over USB 2.0 (taxa de transferência máxima de 300 Mbps);
• GPIO de 40 pinos;
• Interface HDMI;
• 4 portas USB 2.0;
• Conector CSI para câmera do Raspberry Pi;
• Conector DSI display para connectar o Raspberry Pi a uma tela touchscreen;
• Saída de vídeo composto e áudio através do plug P4;
• Slot cartão micro SD para carregamento do sistema operacional e armazenamento

de arquivos;
• Entrada de fonte DC micro USB 5V/2.5A;
• Suporte a Power-over-Ethernet (PoE) (requer HAT PoE separadamente).

Figura 12 – Ilustração da placa Raspberry Pi 3B+ [5].
Diante das características físicas e técnicas mencionadas acima, atualmente o Rasp-

berry Pi pode ser empregado em diversas aplicações capazes de substituir o uso do compu-
tador pessoal a fim de economizar espaço, processamento e, não menos importante, custos.
Entre os sistemas mais desenvolvidos com a placa estão: sistemas de visão computacional,
impressoras 3D, servidores Web, videogames portáteis, controladores para robôs, estações
de rádio e ensino de programação computacional em geral.
Neste projeto, o Raspberry Pi foi utilizado para embarcar o sistema de verificação de
testes utilizando a distribuição Linux, denominada Raspbian. Por se tratar de um sistema
operacional, o mesmo é composto por bootloader, kernel, aplicações, ambientes gráficos,
entre outros [32].
Com isso, o Raspberry pode executar programas do mesmo modo que um computador
convencional faz. O seu uso no projeto proporciona à equipe de desenvolvimento uma
estação de verificação de testes remota de baixo custo, de modo que os integrantes possam
realizar testes remotos no inversor através de protocolo de rede SSH (Secure Shell) e locais
por meio de interface gráfica de usuário.
A arquitetura generalizada da concepção de uma estação remota utilizando uma Rasp-
berry Pi e comunicação SSH para o envio de dados pertinentes ao sistema de verificação
automatizada de testes pode ser visualizada conforme a Figura 13.
Figura 13 – Arquitetura do projeto com o uso estação remota através de um Raspberry

Pi.
2.9 Jenkins
A integração contínua (IC) ou, do inglês, Continuous Integration (CI) é um processo
do desenvolvimento em que os desenvolvedores entregam seus trabalhos com frequência
para que esses sejam executados e testados antes de sua aprovação [33].
Em termos de CI, o Jenkins é um dos softwares mais populares atualmente. Jen-
kins é uma ferramenta de código aberto, desenvolvido em Java, que auxilia virtualmente
a construção e testes de projetos de software. Segundo seus desenvolvedores, a tarefa
básica do Jenkins é executar passos pré definidos, conhecidos como Jobs, baseados em
gatilhos ou comandos. Em adição a essas características, o Jenkins permite aos usuários
o estabelecimento de notificações sobre o andamento do desenvolvimento do projeto [34].
De forma geral, a ferramenta funciona como um servidor em que o desenvolvedor é
capaz de condicionar um ambiente de integração com várias configurações e comandos de
gatilho interessantes para o desenvolvimento de software. Sendo um servidor, a ferramenta
pode operar em uma arquitetura mestre/escravo, onde o mestre pode executar certos jobs
em diferentes tipos de plataformas ou sistemas operacionais. Esta arquitetura pode ser
visualizada conforme a Figura 14.
Figura 14 – Arquitetura mestre/escravo utilizando no Jenkins.
Os Jobs são scripts ou comandos computacionais escritos na linguagem bash. A partir

desses comandos uma gama enorme de recursos pode ser acessada. Dentre as tarefas mais
realizadas por meio do Jenkins está a automação do build (construção) de projetos de

software, para agilizar seu desenvolvimento.
Neste projeto, o Jenkins foi utilizado para promover a integração contínua e garantia
de qualidade do software do inversor, na medida em que a equipe de desenvolvimento
entrega novas versões. Com isso, jobs apropriadamente configurados verificam e testam a
performance do firmware periodicamente. Todavia, por se tratar de uma ferramenta que
executa o projeto, ela não foi utilizada como fonte de testes e resultados neste trabalho,
abordados no Capítulo 5 deste documento. Mais informações sobre a utilização do Jenkins
neste trabalho são pautadas nos Capítulos 3 e 4.
2.10 Trabalhos relacionados

Com o objetivo de entender e levantar alguns sistemas de automatização ou verifi-
cação de testes em diferentes sistemas, foram analisados alguns projetos. O primeiro
trabalho relacionado aborda um sistema do tipo Hardware-in-the-loop para automatizar
testes sobre o sistema embarcado de tratores, ideia semelhante à apresentada neste do-
cumento, contudo em âmbitos distintos. O segundo trabalho aborda a importância em
aspectos industriais e financeiros de automatizar os testes em projetos que envolvam o
desenvolvimento de software.
2.10.1 Automação de testes Hardware-in-the-loop do sistema

embarcado de um trator
O trabalho feito por Satyam Raikwar, Wani Laxmikant Jijyabhau, Arun Kumar e
Sreenivasulu Rao, todos membros do setor de pequisa e desenvolvimento da empresa
Tractors and Farm Equipment Ltd, da Índia, visa aumentar a performance dos tratores
desenvolvidos na empresa com a implantação de um sistema de automação e verificação
de testes. Os integrantes da equipe se depararam com a migração de sistemas mecânicos
de controle dos tratores para sistemas embarcados, os quais deveriam ser testados para
garantia de qualidade. O sistema de automação de testes consiste em um Hardware-in-the-
loop, plataforma que permite a execução de testes em tempo real de sistemas embarcados,
para a autoexecução das funcionalidades lógicas e de controle do nível de hardware dos
tratores. Com isso se percebeu que uma considerável quantidade de tempo foi reduzida se
comparado aos testes manuais realizados anteriormente à implantação deste projeto [35].
2.10.2 O impacto no custo, qualidade e tempo de comercializa-

ção utilizando automação de testes
O projeto realizado e documentado por Divya Kumar e K. K. Mishra, ambos do Ins-
tituto Nacional de Tecnologia Motilal Nehru National em Allahabad, na Índia, objetiva
desmistificar a ideia de que a automação de testes em softwares consomem muito tempo.
Utilizando o mesmo conceito aplicado ao desenvolvimento de uma aplicação computacio-
nal, ambos concluíram que, embora a automação de testes seja algo custoso no início de
sua implantação, os seus resultados a médio e longo prazo trazem benefício no que diz
respeito aos custos, qualidade e tempo de entrega do software para o mercado [36].
42
3 Arquitetura do projeto
Neste capítulo é abordada, de forma sucinta, a forma de integração de todas as tec-

nologias, expostas anteriormente, no desenvolvimento do projeto. À frente ao que foi
exposto no Capítulo 2, pode-se inferir que uma fragmentação de tarefas é necessária para
que o os objetivos do projeto sejam atingidos. Como se sabe, o sistema proposto deve
executar os testes sobre o hardware e firmware de um inversor em desenvolvimento, par-
tindo de comandos do usuário, gerando um histórico completo de resultados dos testes
por intermédio de um software de gerenciamento de aplicações.
Diante disso, estabeleceu-se uma hierarquia de arquitetura de implementação de três
camadas (ou níveis), de forma que o escopo do projeto siga a estrutura delineada abaixo.
• 1o nível: condiz com o nível mais alto de execução: o gerenciamento. Corresponde

à utilização do HP Application Lifecycle Management para a geração de histórico
acerca dos resultados dos testes sobre o inversor;
• 2o nível: é o nível intermediário do escopo do projeto. Corresponde à execução

do mesmo, utilizando algoritmos em Python que permitem a comunicação e mani-
pulação de parâmetros do inversor, conferindo o envio de dados e resultados para
o ALM. O algoritmo é executado em um computador pessoal, sistema embarcado
(Raspberry Pi 3) ou em algum servidor de automação, que neste caso é o Jenkins
(a partir de um PC);
• 3o nível: refere-se ao nível mais baixo do projeto. Corresponde aos dispositivos

que serão testados que, neste caso, são inversores de frequência WEG em estado de
desenvolvimento.
Diante disso, os níveis são abordados de maneira mais detalhada na Seção 3.1.
3.1 Níveis da arquitetura

A partir do que foi exposto no início deste capítulo, pode-se afirmar que existe uma
arquitetura de projeto clara e simples, que visa atender todos objetivos propostos. De
forma visual, tem-se a ilustração para arquitetura básica do projeto, conforme a Figura
15.
Capítulo 3. Arquitetura do projeto 43
Figura 15 – Ilustração da arquitetura básica do projeto.
Para fundamentar melhor o propósito de cada camada do projeto, tem-se uma expan-
são dos aspectos técnicos abordados por cada uma delas, conforme a próxima ilustração.
De forma geral, as atividades desempenhadas por cada nível do projeto são ilustradas
Figura 16 – Atividades por nível do projeto.

Conforme Figura 16, o primeiro nível permite especificar requisitos de testes a partir
de diferentes versões do firmware, estabelecer um planejamento de como os testes devem
ser executados e, a partir da execução dos testes, organizar um histórico de resultados de
forma centralizada. O segundo nível é o execucional, cerne de toda a lógica do projeto.
Nesse nível é operado o algoritmo que realiza as funções de comunicação (Raspberry
Pi/Inversor, PC/Inversor e Jenkins/Inversor), execução dos testes, geração e exportação
de resultados local e remota (por meio do ALM) e interface de usuário. Por fim, o
terceiro nível é representado pelo hardware em que os testes são executados, ou seja, os
inversores propriamente ditos. Neles é possível executar parâmetros de forma automática
e acompanhar a dinâmica do teste através da interface homem-máquina.
3.2 Integração do software na arquitetura

A concepção do software que integra as tecnologias tratadas até aqui é parte funda-
mental deste trabalho. O mesmo permite organizar a infraestrutura lógica para a operação
nos três níveis da arquitetura do projeto. Até então foram mencionados os recursos téc-
nicos utilizados e a ideia geral do projeto. Para unir esses dois aspectos é necessário que
o software permita uma interface entre o usuário e o projeto de verificação. Portanto,
a infraestrutura lógica do projeto deve possibilitar o controle do inversor e a geração de
histórico dos testes realizados através de algoritmos computacionais.
Os algoritmos utilizados no trabalho estão separados em três pastas principais, as
quais possuem diferentes finalidades.
• Pasta config: responsável pelas configurações de parâmetros do inversor e estabele-

cimento de conversação com o ALM através da API rest. requests e configurações
de verificação de erros;
• Pasta fastrun: destinada ao estabelecimento de comunicação com o inversor e his-

tórico local de testes.
Pasta history: pasta interior ao diretório fastrun que armazena os resultados de
testes localmente;
• Pasta tests: pasta contendo os testes a serem verificados.
Da forma em que foram caracterizadas, as pastas podem estar associadas a mais de um

nível da arquitetura do projeto. Para acessar estas pastas existem dois tipos de interface
de usuário: linhas de comando (CLI) e interface gráfica de usuário (GUI). Dentre outras
funcionalidades, a execução do projeto por linhas de comando ou interface gráfica permite
as ações listadas abaixo.
• Seleção de testes a serem executados;

• Comunicação com o inversor;
• Execução dos testes;
• Geração de histórico local;
• Compartilhamento de informações com o ALM.
Deve-se ressaltar que, para a utilização de integração contínua do projeto com o Jen-
kins, apenas a interface de linha de comando é utilizada. Em linhas gerais, as tarefas
efetuadas pelo software do projeto ocorrem segundo uma ordem de execução, que é ilus-
trada conforme o fluxograma da Figura 17.
Figura 17 – Ilustração da arquitetura básica do projeto.

Com o que foi exposto neste capítulo é possível estabelecer uma organização geral a
respeito do funcionamento do projeto. O próximo capítulo se refere à metodologia e a
forma que cada nível foi implementado.
48
4 Metodologia e implementação do
projeto
Este trabalho foi fundamentado na utilização de conceitos de várias ferramentas dis-

tintas. Para organizá-las de uma maneira lógica estabeleceram-se três níveis de funcio-
namento da sua arquitetura. Com o entendimento deles é possível estabelecer, de forma
detalhada, como as ferramentas são utilizadas para alcançar o objetivo proposto no co-
meço deste documento.
Para a concepção de um sistema que baseado na verificação de testes do firmware
de um inversor é necessário conhecer algumas particularidades de como o conjunto hard-
ware/firmware opera. A metodologia implementada no projeto visa testar o sistema e
verificar se erros - mais conhecidos como bugs - ocorrem a partir do lançamento de novas
versões desse conjunto.
Durante o desenvolvimento do software, os integrantes da equipe de desenvolvimento
podem lançar novas funcionalidades (conhecidas como features) ou parâmetros. Com a
criação de uma quantidade razoável de novas features, uma versão subsequente do sistema
é lançada, requerendo sua validação que, de forma geral, é uma etapa que visa garantir
o funcionamento adequado do sistema. Na etapa de validação do firmware são realizados
testes unitários (em cada parte do software), com a utilização de ferramentas como ana-
lisador de dados, osciloscópios e debuggers. O projeto em questão consiste em adicionar
uma fase intermediária entre o lançamento da versão e a validação do sistema, pois é no
decorrer da validação alguns bugs são descobertos e podem afetar o funcionamento do
sistema como um todo. Com a utilização do conceito de verificação do sistema a partir
de testes anteriores à validação, é conferida uma ordem cronológica de fatos no decorrer
do desenvolvimento, que pode ser exemplificado conforme a Figura 18.
Capítulo 4. Metodologia e implementação do projeto 49
Figura 18 – Exemplo de ordem cronológica no desenvolvimento do firmware.
Para estabelecer uma relação confiável entre o desenvolvimento do firmware e a veri-

ficação de testes, a implementação do projeto integrou as diversas ferramentas abordadas
no capítulo de revisão de tecnologias utilizadas, as quais possuem objetivos distintos. O
projeto desenvolvido foi implementado tanto em um computador pessoal para a execução
do projeto através do CLI, GUI e Jenkins, assim como, portado para um sistema embar-
cado em Raspberry Pi utilizando GUI e CLI, sem promover qualquer diferença em sua
arquitetura.
As próximas seções abordam alguns conceitos implementados no projeto, como o pla-
nejamento de testes, execução automatizada de parâmetros e testes, modelo de execução
dos testes, geração de histórico de resultados e utilização de interface gráfica de usuário.
4.1 Planejamento de testes

O projeto tem como o objetivo retornar verificações precisas de uma gama de testes
executada sobre os parâmetros de um inversor na medida em que novas versões do seu
sistema são lançadas.
Um teste é basicamente uma execução sequencial de parâmetros seguindo alguns crité-

rios lógicos a fim de corroborar ou não determinados requisitos. Neste caso, os requisitos
dos testes estão ligados ao funcionamento e dinâmica esperados das funcionalidades do in-
versor. Para se especificar e planejar requisitos de testes se utiliza o ALM. Para a execução
do teste ser verificada de acordo com os seus requisitos, é necessário que o desenvolvedor
siga certa ordem lógica no seu planejamento. Para o planejamento do teste fluir de forma
eficiente, a seguinte ordem de etapas deve ser seguida:
1. Especificação de requisitos;
2. Criação/definição do teste;
3. Planejamento e descrição das etapas;
4. Execução do teste.
Este planejamento é detalhado visualmente na Figura 19.
Figura 19 – Fluxo de planejamento dos testes no ALM.
4.1.1 Requisitos de testes

No ALM, para assegurar uma validação ou verificação de um teste de maneira mais
otimizada há a possibilidade de criar e gerenciar requisitos de testes. Os requisitos, neste
caso, são especificações de valores esperados para os parâmetros do inversor, os quais são
testáveis. Quando criados, os requisitos podem ser usados para mais de um teste. Por
este motivo esta deve ser a primeira etapa do planejamento de testes.
Para esta funcionalidade, o software apresenta a ferramenta requirements em que é
possível criar e detalhar uma gama de requisitos. Na ferramenta, dentre outros parâme-
tros, o requisito deve apresentar, fundamentalmente, uma descrição detalhada e alguns
metadados, como o autor, data de criação e projeto em que será utilizado.
Com a utilização do requisito, outras informações importantes são adquiridas, como a

inclusão do requisito em testes e histórico de resultados. Um requisito de testes pode ser
detalhado visualmente conforme a Figura 20.
Figura 20 – Detalhamento de um requisito de teste no ALM.
A partir do estabelecimento dos requisitos é possível instanciar um novo teste, que

pode ser dependente dos requisitos gerados.
4.1.2 Criação do teste e descrição de etapas

Com a determinação de requisitos, o ALM torna possível a criação de testes. O teste
é uma forma literal de como algumas etapas devem ser executadas a fim de atingir alguns
objetivos. Por padrão um teste pode ter infinitos passos. Cabe ao desenvolvedor do teste,
então, determinar critérios lógicos e possíveis para que o teste seja cabível. Para criar e
descrever um teste, o ALM dispõe da ferramenta Test Case, onde é possível definir um
nome para o teste, criar e descrever etapas de execução, além de descrever os resultados
esperados. Nesta ferramenta também se faz possível designar os requisitos aplicáveis ao
teste. Por padrões internos de desenvolvimento, os testes devem ser escritos na língua
inglesa. A Figura 21 apresenta um exemplo de definição e descrição de etapas de um teste
utilizado no projeto. O teste visa a verificação do parâmetro DC Braking at Start, que
significa frenagem DC na partida/início, em português.
Figura 21 – Exemplo de um teste no ALM.
A partir da concepção de um teste, conforme a Figura 21, o teste adquire um iden-

tificador padrão ou ID e algumas informações como a data de criação, autor e requisitos
relacionados.
No projeto atual a maioria dos testes serão executados em dois ou mais passos. Para
o mesmo teste é possível estabelecer um número variável de etapas a serem executadas,
dependendo apenas da objetividade de suas especificações. Ademais, com a realização
desta etapa o teste adquire um identificador, o qual permite sua execução, gerenciamento
e geração de histórico de resultados, assunto abordado na Seção 4.3.
4.1.3 Execução do teste no ALM

A última etapa do planejamento de um teste refere-se à sua execução. É na execução
do teste que falhas podem ser identificadas.
Neste projeto a execução de teste é realizada de forma automática por meio de algo-
ritmos escritos na linguagem Python, os quais funcionam com a utilização de módulos de
comunicação com o inversor e com o gerenciamento de testes do ALM. A execução de um
teste no ALM depende estritamente do ID relacionado ao teste a ser executado.
A partir da execução de um teste pode-se verificar o alcance de requisitos e a geração
de um histórico de resultados, tanto local quanto em nuvem (no ALM). O histórico de
testes é discutido com mais profundidade na Seção 4.5, sobre geração de histórico de
resultados.
4.2 Execução automatizada de parâmetros

De acordo com o que foi discutido no segundo capítulo deste documento, os inver-
sores de frequência operam de acordo com a variação de diferentes tipos de parâmetros,
geralmente configurados através de ação humana, mesmo que em limitadas ocasiões. A
parametrização depende, basicamente, de aspectos físicos do motor utilizado e caracte-
rísticas do processo. Na indústria a configuração e execução de parâmetros é comumente
realizada através do IHM (Interface Homem-Máquina). O IHM é um dispositivo simples
e eficiente para a parametrização de inversores para as mais diversas aplicações de campo.
Contudo, ele não se trata de uma interface que pode automatizar o processo da mudança
dessas variáveis, caso seja necessário.
Este aspecto pode ser facilmente contornado tendo em vista que o inversor oferece
diversos protocolos de comunicação. O ModBus, usado no projeto, é um protocolo sim-
ples e depende apenas de um cabo de transmissão padrão Ethernet para interconectar o
inversor ao dispositivo mestre. Portanto, com um computador e um cabo do tipo RJ-45
se tem uma estrutura física completa para operar um inversor, eliminando a ação manual
de operação no dispositivo. A figura Figura 22 apresenta a topologia da comunicação
entre o computador e o inversor.
Figura 22 – Atividades relacionadas ao nível de hardware do projeto.
A partir do que foi discutido na Seção 2.5 pôde-se entender como os dados do inversor
escravo podem ser lidos pelo computador, que atua como um mestre por meio do protocolo
utilizado. De forma geral, através do protocolo ModBus o inversor possui um endereço
IP próprio. Nesse protocolo, seus dados e parâmetros são tratados como registradores, os
quais possuem valores numéricos. Os parâmetros, por exemplo, possuem endereçamentos
particulares, em que uma ou mais informações podem ser acessadas.
Diante da topologia de comunicação e da organização dos dados no inversor, basta
apenas formular a parte lógica de comunicação com o protocolo. Há muitas formas de
implementar a camada de transporte de uma comunicação serial. Neste caso a linguagem

Python, fundamentada no segundo capítulo, foi utilizada para promover a base lógica
desse aspecto. Para conseguir estabelecer a conversação de informações entre inversor e
o computador utilizando o ModBus, foi utilizada a biblioteca pymodbus.
A partir da documentação do módulo, todas as funções de comunicação do ModBus
podem ser implementadas. Dentre outras funções, as principais utilizadas no projeto tem
o objetivo de:
• Estabelecer comunicação com o endereço IP do escravo;
• Decodificar tipos de dados;
• Ler dados dos registradores;
• Escrever dados nos registradores.
Um exemplo de código em Python, onde o parâmetro de velocidade da rampa de

um inversor com endereço de IP 192.168.0.1 é lido e escrito utilizando a biblioteca, é
apresentado abaixo.
1 import pymodbus # importa a b i b l i o t e c a pymodbus
2
3 in vers or = inicia_comunicacao ( 1 9 2 . 1 6 8 . 0 . 1 )
4
5 velocidade_rampa = le_parametro ( 3 0 0 ) # v e l o c i d a d e da rampa
6 e s c r e v e _ p a r a m e t r o ( 1 0 0 , 3 0 0 ) # e s c r e v e v e l o c i d a d e de 100rpm para a rampa
Listing 4.1 – Algoritmo para o estabelecimento de comunicação com o inversor.
No exemplo acima, o parâmetro com identificador 300 é o de velocidade da rampa. A

ideia geral discutida nesta seção é utilizada para estabelecer a criação de testes, que seguem
uma ordem de execução de parâmetros. As funções de escrita e leitura de parâmetros
ocorrem no script que envolve o protocolo de comunicação do projeto, presente na pasta
fastrun. Os algoritmos das funções para escrever e ler parâmetros do inversor são listados,
respectivamente, abaixo.
1 d e f e s c r e v e _ p a r a m e t r o ( v a l o r , parametro ) :
2 erro = 0
3
4 w h i l e e r r o r <= 3 : # Try t o r e a d r e g i s t e r f o r 3 t i m e s
5 r e g i s t e r _ o l d = c l i e n t . r e a d _ h o l d i n g _ r e g i s t e r s ( parametro , count =1,
u n i t =255)
6 print ( register_old )
7 i f not r e g i s t e r _ o l d . i s E r r o r ( ) : # Check t c p c o n n e c t i o n whit t h e
r e g i s t e r read
8 break
9 else :
10 e r r o r += 1
11
12 c l i e n t . w r i t e _ r e g i s t e r ( parametro , v a l u e=v a l o r , count =1, u n i t =255) #
write r e g i s t e r
Listing 4.2 – Função de escrita de parâmetro.
1 d e f le_parametro ( parametro ) :
2 error = 0
3
4 w h i l e e r r o r <= 3 :
5 r e g i s t e r _ d a t a = c l i e n t . r e a d _ h o l d i n g _ r e g i s t e r s ( parametro , count =1,
u n i t =255)
6 i f not r e g i s t e r _ d a t a . i s E r r o r ( ) :
7 break
8 else :
9 e r r o r += 1
10
11 r e g i s t e r _ d a t a _ d e c o d e d = BinaryPayloadDecoder . f r o m R e g i s t e r s (
r e g i s t e r _ d a t a . r e g i s t e r s , b y t e o r d e r=Endian . Big ,
wordorder=Endian . Big )
12 data = r e g i s t e r _ d a t a _ d e c o d e d . decode_16bit_uint ( )
13
14 r e t u r n data
Listing 4.3 – Função de leitura de parâmetro.
Na função de escrita de parâmetros há, primeiramente, a tentativa de leitura do re-

gistrador a fim de encontrar algum erro de resposta. Caso o erro ocorra, há outras duas
tentativas de leitura. Se não houver a ocorrência de erro, o novo valor é escrito no regis-
trador do parâmetro, conforme a linha 12 da listagem 4.3.
A função de leitura de parâmetros do inversor tenta captar erros no registrador de
forma análoga ao algoritmo de escrita. Se não houver a ocorrência de erros, o valor
presente no parâmetro é lido e retornado.
As particularidades que envolvem o desenvolvimento e criação dos mesmos serão vistas
na Seção 4.3.
4.3 Execução automatizada de testes

Este é o tópico central deste capítulo, o qual discorre basicamente da aplicação das
ferramentas importantes tratadas até aqui para a elaboração de algoritmos que mesclam
a descrição de testes criados no ALM com a execução automatizada de parâmetros, temas
discutidos nas duas primeiras seções deste capítulo.
Como já foi debatido neste documento, considera-se um teste como um conjunto de
etapas a serem executadas, segundo critérios plausíveis, a fim de se atingir determinados
requisitos. Com uma elaboração descritiva detalhada de um teste no ALM é possível

escrever um algoritmo ou script de computador de forma a traduzir essa descrição em
um algoritmo computacional para a execução de suas etapas de forma automatizada no
inversor de frequência.
Como exemplo de teste a ser automatizado, tem-se os passos descritos conforme a
Figura 20. Os mesmos podem ser descritos pelo fluxograma lógico, vistos na Figura 23.
Figura 23 – Fluxograma lógico de um teste exemplo.
Como pode-se notar através da figura acima, na descrição dos passo 1, 2 e 3 alguns
parâmetros estão descritos de forma não numérica. Como por exemplo:
• Corrente do motor = corrente nominal informada no motor utilizado (4,5A neste

exemplo);
• Frenagem DC no início = valor 1;
• Comando RUN = ID 664 para valor 3;
• Comando STOP = ID 664 para valor 2.
Todos os parâmetros mencionados possuem um valor numérico passado como infor-

mação através do protocolo ModBus RTU. Com a ciência de toda a descrição de passos,
parâmetros e valores, a elaboração de um script em Python, que executa o teste, é pos-
sível. O teste deve ser escrito de maneira simples, de forma a não mostrar detalhes das
implementações de outras bibliotecas utilizadas no programa, como a pymodbus. Por-
tanto, já se leva em conta que a comunicação entre mestre e escravo já foi estabelecida e
resta apenas a transmissão, recepção e tratamento lógico dos dados.
Isto posto, o algoritmo em Python desenvolvido para o teste é mostrado abaixo, de

acordo com cada passo a ser executado. Vale ressaltar ainda que é nesse algoritmo que o
ID adquirido pelo teste através do ALM deve ser implementado com uma variável, assim
como sua descrição.
1 # T e s t e exemplo − frenagem CC de p a r t i d a
2
3 D e s c r i c a o = " Execucao de p a r a m e t r o s para t e s t a r a f u n c i o n a l i d a d e de
frenagem DC de p a r t i d a " # d e s c r i c a o do t e s t e
4
5 R e c u r s o s = [ " motor " , " e n c o d e r " ]
6
7 ID = 200 # i d e n t i f i c a d o r do t e s t e
8
9 # Passo 1
10 def step1 () :
11 # Writing p a r a m e t e r s
12 w r i t e P a r a m e t e r ( 1 , 3 0 7 ) # Braking a t s t a r t
13 w r i t e P a r a m e t e r ( 5 0 , 2 9 9 ) # Braking time a t s t a r t
14 w r i t e P a r a m e t e r ( 1 0 0 , 3 0 1 ) # Braking s p e e d
15 w r i t e P a r a m e t e r ( 2 0 0 , 3 0 2 ) # DC b r a k i n g c u r r e n t
Listing 4.4 – Passo 1 do teste exemplo.
O algoritmo da Listagem 4.5 atribui aos parâmetros 307, 299, 301 e 302 os valores
descritos na Figura 23. Esta etapa se refere à configuração inicial de alguns parâmetros
importantes para a execução do teste.
1 # Passo 2
2 def step2 () :
3 w r i t e P a r a m e t e r (RAMP_START, CONTROL_WORD_ETHERNET) # Run ramp
4 dc_current1 = readParameter ( 3 ) # r e a d i n g DC c u r r e n t a t ramp s t a r t
5
6 c u r r e n t S p e e d = readParameter (MOTOR_SPEED)
7 # Current s p e e d r e a d i n g u n t i l i t r e a c h e s t h e s e t up s p e e d l i m i t
8 while currentSpeed < speedLimit :
10
11 # a s s e r t de comparacao de v a l o r e s
12 TestAssertEqualNumber ( 0 . 0 5 , ( motor_current / 1 0 ) ∗ 0 . 2 , dc_current1 / 1 0 )
O passo 2 se refere à leitura do sinal de corrente DC no início da execução da rampa

(linha 4). Esta etapa ocorre até a rampa atingir seu limite (laço da linha 8). Após isso,
o passo é finalizado com a comparação entre o valor dc_current1 e o valor esperado para
a variável do parâmetro.
1 # Passo 3
2 def step3 () :
3 # Stop t h e ramp
4 w r i t e P a r a m e t e r (RAMP_STOP, CONTROL_WORD_ETHERNET)
5
6 # While c u r r e n t s p e e d >= 1 : do n o t h i n g
7 w h i l e c u r r e n t S p e e d >= 1 :
9
10 # Catch t h e f i n a l DC c u r r e n t v a l u e
11 dc_current2 = readParameter ( 3 )
12
13 # a s s e r t de comparacao de v a l o r e s
14 TestAssertGreaterNumber ( dc_current2 / 1 0 , 0 )
O passo 3 do teste é iniciado com a parada da rampa. O laço da linha 7 ocorre até a
leitura da velocidade do motor atingir valor igual ou menor a 1. Ao final da execução do
passo, a variável dc_current2 é comparada com o valor esperado, que é 0 neste caso.
A partir do estabelecimento do algoritmo do teste, pode-se fazer o estudo de como a
verificação de falhas ocorre por meio comparações de valores. Essa comparação de valores
é dada por asserts, relações entre valores que dependem de regras matemáticas. Este
aspecto é tratado no próximo tópico.
4.3.1 Verificação de requisitos

A verificação dos requisitos é o que relaciona o valor esperado ao valor obtido em
determinada etapa do teste. Ou seja, se refere à uma comparação que deve respeitar al-
guma regra, esta proposta através de critérios plausíveis de acordo com o funcionamento
do inversor. No projeto de verificação de testes existem quatro tipos de regras ou asserts,
para verificar a conformidade dos testes com seus requisitos. Os asserts são basicamente
comparações de valores obtidos e esperados de parametrizações em determinados momen-
tos do teste realizado. Os quatro tipos presentes no atual estado do projeto são listados
a seguir, com suas regras.
1. Valor Igual: neste caso o valor obtido deve ser igual ao resultado esperado, com
alguma margem de erro admitida pelos desenvolvedores. A função executada é
TestAssertEqualNumber(valor obtido, valor esperado), em que o retorno obedece a
seguinte relação:
• Se o valor esperado é diferente do valor obtido:

• Calcula o erro percentual, dado por Erro:
valorobtido − valoresperado
Erro(%) = |( )|.100 (4.1)
valorobtido
• Passo é falho (failed);

• localError = 1;
• Caso contrário, passo aprovado (passed).
2. Valor menor: neste caso o valor obtido deve ser menor que o resultado esperado,
independentemente da margem de erro. A função executada é TestAssertSmaller-
Number(valor obtido, valor esperado), em que o retorno obedece a seguinte relação:
• Se o valor obtido é menor que o valor esperado:

• localError = 1;
3. Valor maior: neste caso o valor obtido deve ser maior que o resultado esperado. A
função executada é TestAssertGreaterNumber(valor obtido, valor esperado), em que
o retorno atende a seguinte relação:
• Se o valor obtido é maior que o valor esperado:

• localError = 1;
4. Valor dentro de uma faixa: o valor obtido durante o teste deve estar contido em
uma faixa de valores. A função para este assert é TestAssertWithin(valor obtido,
valor menor, valor maior). O retorno da função respeita a seguinte regra:
• Se o valor obtido é maior que o valor menor e menor que o valor maior:
• Passo é aprovado (passed);
• Caso contrário, passo reprovado (failed) e localError = 1;
No exemplo trazido nesta capítulo, o teste contém duas comparações: TestAssertE-

qualNumber, na linha 12 da Listagem 4.6 e TestAssertGreaterNumber, na linha 14 da
Listagem 4.7. A partir do momento em que o assert é realizado durante o teste, seu re-
sultado é salvo e manipulado posteriormente. Desta forma, além de retornar o resultado
da comparação, é possível conhecer a origem da sua falha e relatá-la.
4.4 Modelo de execução dos testes

Até o último tópico a arquitetura geral de um teste pôde ser entendida desde a geração
de seus requisitos, sua descrição de execução e forma de execução no ALM. Contudo, o
projeto permite a execução de mais de um teste, de acordo com a lógica de execução
padronizada e utilizada no projeto.
No momento em que o script de um teste é criado, deve-se atribuí-lo um nome. Em
seguida o teste deve ser salvo na pasta tests do projeto. Por padrão o nome do teste deve
respeitar a seguinte regra:
• Verificar o ID do teste no ALM;
• Criar o teste e atribuir seu nome da forma test_<ID>;
• Por exemplo, um teste com ID = 200, recebe o nome de test_200;
Com o nome estabelecido, cada teste deve conter uma função que também depende
do seu ID e da quantidade de passos do teste. A função deve ser escrita da forma
teste_<ID>. Para um teste com ID = 200, por exemplo, o script em Python da função
pode ser exemplificada conforme o seguinte algoritmo.
1 # MAIN FUNCTION
2 def teste_200 ( ) :
3 step1 () # c a l l t e s t ’ s step1
4 step2 () # c a l l t e s t ’ s step2
Listing 4.7 – Função principal do teste exemplo.
Conforme o código da listagem acima é perceptível que a função, quando chamada,

executa as funções step1 e step2 do teste, já tratadas anteriormente. A partir disso é
possível estabelecer uma lógica de execução dos testes em um laço no programa principal.
4.4.1 Laço de execução

No programa principal - ou arquivo main do projeto -, acessado pela interface de
usuário (conforme a Figura 17), está presente a lógica de execução dos testes criados no
projeto. A partir da interface de usuário é possível selecionar os testes a serem executados.
Na medida em que os testes são selecionados, um array (lista) chamado lista_testes, de
tamanho variável de acordo com a quantidade de testes selecionado (n testes), é preenchido
com as strings dos nomes dos testes (test_<ID>) respeitando a ordem de seleção imposta
pelo usuário.
Em seguida, um iterador é inicializado como nulo (contador = 0) e a lista contendo os
testes selecionados é executada em um laço de repetição de acordo com o iterador. Dentro
do laço de execução o algoritmo funciona de modo a importar os atributos (funções e
variáveis) de cada teste presente na lista. Após importar os atributos, há a chamada da

função principal do script do teste (test_<ID>), o qual executa os passos do mesmo. O
laço é repetido até executar o último teste presente no array, finalizando a execução dos
testes. A arquitetura de execução pode ser ilustrada conforme a Figura 24.
Figura 24 – Fluxograma da lógica de execução dos testes.
A arquitetura de execução de testes estabelecida no projeto confere ao usuário a fle-

xibilidade de escolher uma gama de testes a serem executados. A partir dessa ideia é
possível ainda gerar uma visão global dos acontecimentos de cada execução.
4.5 Geração de histórico de resultados

A geração de histórico de resultados dos testes realizados sobre o firmware do inversor
é parte importante do projeto. É a partir deste conceito que o desenvolvedor pode acom-
panhar a evolução do algoritmo presente no inversor na medida em que o dispositivo é
desenvolvido.
No projeto existem dois tipos de geração de histórico: remota e local. A geração
remota de histórico de resultados se remete à utilização do ALM, que promove o acesso
aos históricos em rede, não necessariamente no local onde os testes são executados. Já a
geração de histórico local se remete ao histórico criado apenas no dispositivo (computador
ou Raspberry Pi) onde os testes foram executados.
4.5.1 Histórico remoto

A partir do último tópico é possível estabelecer onde as possíveis falhas podem ocorrer
em um teste por meio dos asserts, comparações que relacionam os valores obtidos e
esperados para os parâmetros do inversor. Esta ideia é o cerne para a geração de histórico
de resultados. Para a geração de um histórico sólido, em que todos os desenvolvedores
possam ter acesso aos resultados durante o desenvolvimento do firmware, foi escolhido o
ALM. O ALM, como tratado anteriormente, permite a manipulação de recursos HTTP
através de métodos.
Após a execução total dos testes, utilizam-se os conceitos de comunicação através do
protocolo HTTP. O método utilizado para enviar informações HTTP ao ALM é chamado
POST, implementado através de API rest em linguagem Python. Para enviar os resultados
ao ALM, é necessário conhecer o URL que as armazena. Sabendo disso, uma das formas
de enviar informações dos resultados dos testes de forma organizada é utilizando o formato
XML, padrão utilizado para descrever diversos tipos de dados. Basicamente, os dados em
formato XML são separados por chaves e seus valores.
No caso do projeto, os dados para a utilização do XML são aqueles gerados a partir
dos asserts dos testes. As informações resultantes através dos asserts devem ser fiéis
aos dados XML que podem ser informados e no ALM. Assim, os asserts promovem os
seguintes dados, também presentes no ALM: ID do teste, nome do teste, resultado do
teste (ou status), comentários e lista de erros.
Para exemplificar o caso, abaixo seguem as informações resultantes de um teste exem-
plo.
• ID: 500;
• Nome: test_500;
• Status: Failed;
• Comentários: None;
• Erros: Step2 - 50%
De forma genérica, o XML do resultado do teste exemplificado acima é apresentado

Figura 25 – Formato XML dos dados resultantes de um teste.
Para enviar esses dados ao ALM de maneira correta, um algoritmo utilizando a API
rest requests, escrita em linguagem Python, é invocado após a realização do assert. Na
linha 3 da listagem 4.9 é apresentada a função que envia o conteúdo XML, estabelecido
através do assert, para o ALM.
1 # POST de i n f o r m a c o e s do t e s t e para o ALM
2
3 POST = r e q u e s t s . p o s t (ALM_ID, data=a s s e r t )
Listing 4.8 – Algoritmo de POST para o ALM.
Na listagem acima o método requests.post possui os argumentos URL e data que se

referem, respectivamente, ao URL em que o dado deve ser enviado e ao dado a ser enviado
(os dados do assert, neste caso).
Com os dados formatados corretamente, é possível, então, salvar os resultados dos
testes de maneira remota no ALM, que armazena todos os resultado em um ambiente
chamado Test Runs. Um exemplo de histórico gerado a partir da execução de seis testes
pode ser visto conforme a Figura 26.
Figura 26 – Exemplo de histórico de resultados no ALM.
Clicando sobre o teste desejado, é possível ter acesso aos outros dados resultantes, como
comentários e erros. Adicionalmente, há a geração de histórico local, que é armazenado
em arquivo texto.
4.5.2 Histórico local

O histórico local é gerado de forma mais simples que o histórico criado no ALM,
pois necessita apenas da criação de um arquivo texto contendo os dados resultantes da
execução dos teste. O arquivo texto é criado na pasta history do projeto, que armazena os
resultados de todos os testes executados, cada qual com um nome específico. No arquivo
são listados dados importantes como ID do teste, nome do teste, autor da execução, testes
executados, resultados do teste, data e tempo de execução.
O arquivo local gerado após a execução dos mesmos testes exemplificados na Figura 26
pode ser visto conforme a Figura 27.
Figura 27 – Exemplo de histórico de resultados gerado localmente.
Diante dos conceitos abordados nesta seção é possível estabelecer uma geração com-
pleta e flexível de resultados a partir dos teste executados utilizando o projeto proposto
neste documento.
4.6 Utilização de interface gráfica de usuário

O uso de interfaces gráficas promove um ganho em termos práticos e visuais em de-
terminados sistemas de computação. A partir delas o usuário tem acesso a ferramentas e
informações de maneira simples. A partir dessa ideia decidiu-se criar uma interface gráfica
para promover um ambiente completo de execução e gerenciamento dos testes realizados
sobre o inversor.
A mesma foi desenvolvida na linguagem padrão do projeto, o Python, e um framework
completo para a criação, manipulação e manutenção de GUI’s, chamada PyQt, foi uti-
lizado. O PyQt é uma biblioteca que empacota o Qt no interpretador Python. O Qt é
baseado na linguagem C++ e possui licença livre para programas não comerciais.
O emprego do PyQt para a criação de uma interface gráfica permitiu a utilização de
diversos objetos, como entradas e janelas de texto, caixas de seleção, botões e utilização de
imagens. Com base na utilização desses recursos algumas especificações para a interface
foram levantadas, tais como as mencionadas abaixo.
• Lista de testes presentes no projeto:

Disponibiliza ao usuário uma lista contendo os testes selecionáveis para execu-
ção;
• Botão para a execução de testes:

Permite executar uma lista com os testes selecionados pelo usuário de maneira
prática;
• Caixa com descrição dos testes:

Fomenta ao usuário a visualização de uma descrição sucinta do teste selecionado
na lista de testes;
• Acesso às pastas do projeto:

Botão para o acesso a pastas importantes do projeto;
• Filtragem de testes:
Lista de itens para permitir a filtragem dos testes por seus recursos utilizados;
• Mensagens em tempo da execução de testes:

Disponibilizar ao usuário mensagens importantes em tempo de execução;
• Botão de acesso aos resumos de execução:

Permitir o acessos à visão global das execuções realizadas, permitindo ao usuário
ter uma referência de falhas durante a execução dos testes.
Assim, uma interface foi desenvolvida fundamentando-se nas especificações citadas. A

mesma é ilustrada conforme a Figura 28, com o ressalte do seus componentes.
Figura 28 – Interface gráfica de usuário com seus componentes evidenciados.
4.6.1 Utilização de CLI para integração com o Jenkins

O Jenkins é a ferramenta utilizada para promover uma integração contínua no de-
senvolvimento do firmware. Até o desenvolvimento do projeto de verificação de testes, o
mesmo foi utilizado para automatizar o build do software do inversor. Como o desenvolvi-
mento do mesmo é elaborado por mais de uma pessoa, cada qual desenvolvendo diferentes
partes do sistema, se torna inviável realizar construções individuais do código. Para con-
tornar esse problema, o Jenkins possibilita a entrega das alterações de cada integrante da
equipe para um repositório central, que constrói o código total e possibilita a criação de
testes.
Portanto, a utilização do Jenkins no projeto ocorre após a etapa de construção do
código. Devido à sua arquitetura de funcionamento, o uso do Jenkins foi baseado em um
script que permite a execução do projeto em linhas de código utilizando um CLI. Este
aspecto pode é melhor apresentado conforme Figura 29.
Figura 29 – Interface de linha e comando do projeto.
Na figura acima o comando list -A é executado, o qual apresenta a lista contendo todos
os testes. Além desse comando, existem outros, conforme a lista abaixo.
• run <opções>: executa os testes, onde as opções são os testes a serem executados
ou todos os testes (run -A).
Exemplo: run test_505;
• list <opções>: lista os testes, onde as opções são a filtragem de testes (list -F ) e a
listagem de todos os testes (list -A);
• history: gera histórico remoto dos resultados dos testes executados através da API
rest;
• quit: comando para abortar o programa.
O Jenkins, então, executa o projeto da mesma forma a qual o programa apresentando

na Figura 29 faz, todavia isso é realizado dentro de um servidor, em que o Jenkins opera.
Assim, após executar Jobs e tarefas intermediárias relacionadas ao desenvolvimento e
construção do firmware do inversor, o Job de execução de testes do projeto de verificação
é executado. Esse fato pode ser visualizado conforme a Figura 30.
Figura 30 – Modelo de execução do Jenkins.
Com o exemplo da figura acima, o Jenkins basicamente realiza um Job que executa
todos os testes por meio do comando run -A e, após isso, gera o histórico dos testes
executados através do comando history.
69
5 Validação e Resultados
Diante de toda a gama de ferramentas e técnicas abordadas neste documento, assim

como, a metodologia de implementação e integração das mesmas ao projeto, se faz possível
realizar alguns testes com o objetivo de qualificar o uso do sistema de verificação de testes
desenvolvido. Para a realização dos testes, utilizou-se como base uma estação contendo
o projeto embarcado em um Raspberry Pi (modelo 3B+) conectado a um inversor de
frequência em estágio de desenvolvimento com um motor WEG acoplado. Durante o
andamento do sistema de verificação, a equipe de software lançou duas versões do firmware
do inversor. A partir disso foi possível determinar se alguma funcionalidade foi melhorada
a partir da concepção de uma nova versão lançada. Vale ressaltar ainda que para levantar
os resultados promovido pelo projeto não se utilizou o Jenkins. Em adição a isso, os testes
foram executados a partir da interface gráfica de usuário.
A montagem física do sistema proposto, com suas devidas conexões entre dispositivos
é ilustrada conforme a Figura 31.
Figura 31 – Diagrama das conexões físicas do sistema proposto.
A partir disso, realizou-se a verificação de dois testes, executados um após o outro,

sendo os mesmos descritos abaixo:
• Teste 1: frenagem DC na partida para controle V/f e controle VVW, explicados

conforme a Seção 2.1.4;
• Teste 2: aplicação de rampa de parada em sentido anti-horário.
As versões do firmware utilizadas para fazer o levantamento dos resultados foram as

versão 0.70 e versão 0.71. Para avaliar o funcionamento do sistema foram analisados os
Capítulo 5. Validação e Resultados 70
gráficos de velocidade (em rpm) em função do tempo (em segundos) da dinâmica do mo-
tor. Os dados dos gráficos utilizados neste capítulo foram obtidos através da análise da
dinâmica das variáveis do motor por meio da IHM do inversor e, em seguida, foram plo-
tados utilizando um software computacional, permitindo gerar o material dos resultados
que esta seção do documento promove. Ademais, as características parametrizadas do
motor utilizado para os dois testes podem ser vistas conforme a Tabela 3.
Tabela 3 – Parâmetros do motor
Características Valor
Tensão nominal 220V
Corrente nominal 4.5A
Frequência de entrada 60Hz
Fonte – do Autor
Para seccionar este capítulo de uma maneira objetiva, cada teste, com seus resultados,
são separados por seção, as quais são divididas de acordo com os resultados obtidos nas
versões 0.70 e 0.71 do firmware do drive.
5.1 Teste 1: frenagem DC na partida para dois tipos

de controle
O teste 1 se refere a uma frenagem DC na partida utilizando dois tipos de controle:
V/f e VVW. Nesse teste são parâmetros a frenagem DC, controle V/f e controle VVW.
A partir das informações fornecidas ao ALM, este teste é dividido em dois passos
(steps) e quatro asserts devem ser realizados, descritos conforme a Tabela 4.
Tabela 4 – Descrição do teste 1 a partir do ALM
Teste 1: Frenagem DC na partida para controles V/f e VVW

Etapas Descrição e expectativas
Passo 1 Configurar parâmetros do motor; Configurar tipo
de controle para V/f; Configurar parâmetro de fre-
nagem DC na partida para 20% da corrente nomi-
nal do motor; Partir o motor durante 1s em ve-
locidade máxima (1800rpm) e, após isso, parar a
rampa. Expectativas: o assert 1 deve ocorrer no
início da partida e atender o requisito de corrente
configurada no parâmetro de frenagem DC; o as-
sert 2 deve ocorrer ao final da rampa, momento em
que não deve haver corrente no motor.
Passo 2 Configurar tipo de controle para VVW; Partir o
motor durante 1s em velocidade máxima (1800rpm)
e, após isso, parar a rampa. Expectativas: o as-
sert 1 deve ocorrer no início da partida e atender o
requisito de corrente configurada no parâmetro de
frenagem DC; o assert 2 deve ocorrer ao final da
rampa, momento em que não deve haver corrente
no motor.
Fonte – do Autor
A partir das descrições de cada etapa do teste, pode-se perceber que duas rampas
devem ser partidas, uma após a outra, para dois tipos diferentes de controle proveniente
do inversor. Neste caso, a rampa deve apresentar dinâmicas iguais no decorrer da aplicação
dos dois tipos de controle. Em adição a isso, os quatro asserts executados durante o teste,
nos momentos t1 , t2 , t3 e t4 respeitam as condições listadas a seguir.
1. Assert 1 : comparação entre a corrente obtida e 20% da corrente nominal parame-

trizada (0.20 x 4,5A = 0.9A):
função AssertEqualNumber(valor obtido, 0.9);
2. Assert 2 : comparação entre a corrente obtida e corrente nula (0A):

função AssertGreaterNumber(valor obtido, 0);
3. Assert 3 : comparação entre a corrente obtida e 20% da corrente nominal parame-

trizada (0.20 x 4,5A = 0.9A):
função AssertEqualNumber(valor obtido, 0.9);
4. Assert 4 : comparação entre a corrente obtida e corrente nula (0A):

função AssertGreaterNumber(valor obtido, 0).
Diante das informações acima, a curva esperada ao decorrer da execução do teste é

ilustrada conforme a Figura 32.
Figura 32 – Dinâmica esperada para o teste 1.
A partir do gráfico acima é possível conceber que a curva tracejada em azul se refere
à curva esperada para o teste e as bolinhas ou pontos esverdeados se referem aos quatro
asserts que devem ocorrer durante o teste.
Em seguida são apresentados os resultados do teste para as versões 0.70 e 0.71 do
firmware.
5.1.1 Versão 0.70

A versão 0.70 do firmware do inversor foi lançada antes do desenvolvimento do pro-
jeto. A partir desta versão os primeiros testes do projeto de verificação de testes foram
realizados.
O teste 1, descrito anteriormente, deveria atender a alguns requisitos, executados por
quatro asserts. Com a configuração de todos os parâmetros exigidos para o teste, obteve-se
o resultado conforme a Figura 33.
Figura 33 – Dinâmica obtida para o teste 1 na versão 0.70 do firmware.
A partir da figura acima, pode-se conceber que o resultado obtido, conforme a curva
avermelhada, está de acordo com o a curva esperada para o teste. Os pontos azulados
também são aspectos visuais que verificam isso. Quantitativamente, os valores atingidos
pela corrente do motor durante o teste, em cada instante de tempo das comparações para
os asserts, foram os seguintes:
• Instante t1 : corrente do motor lida = 0.9A;
• Instante t2 : corrente do motor lida = 0A;
• Instante t3 : corrente do motor lida = 0.9A;
• Instante t4 : corrente do motor lida = 0A.
De acordo com os valores obtidos e mencionados acima para, pode-se dizer que as
especificações dos asserts foram atendidas perfeitamente. Em seguida é apresentado o
resultado do mesmo teste para versão 0.71, que deverá ser análogo ao que foi obtido neste
tópico.
5.1.2 Versão 0.71

Mesmo tendo sido aprovado na versão 0.70, o teste 1 deve ser realizado novamente
nas próximas versões para promover um histórico completo de resultados no decorrer da
utilização do projeto. É o que ocorre com a utilização da versão 0.71 do firmware.
A partir dessas ideias o teste foi realizado, resultando em um gráfico ilustrado conforme
a Figura 34.
De acordo com a figura acima, pode-se dizer que o teste 1 foi corroborado novamente,
obtendo resultados análogos aos anteriores, realizados na versão 0.70. Contudo, esta
evidência não pode presumir que o teste aprovará os parâmetros utilizados nas versões
futuras do firmware. Assim sendo, o mesmo deve ser testado a cada nova versão.
5.2 Teste 2: aplicação de rampa inversa de parada

O teste 2 se refere à aplicação de uma rampa de parada com sentido inverso. Neste
teste nenhum tipo de controle promovido pelo inversor foi utilizado.
De acordo com a informação fornecidas ao ALM, o teste deve ser executado em duas
etapas, verificando dois asserts. A descrição completa do teste é descrita conforme a
Tabela 5.
Tabela 5 – Descrição do teste 2 a partir do ALM
Teste 2: Rampa de parada com sentido inverso

Etapas Descrição e expectativas
Passo 1 Configurar parâmetros do motor; Configurar
rampa de partida no sentido horário; Configurar
rampa de parada no sentido anti-horário; Partir o
motor durante 1s em 900rpm e, após isso, parar a
rampa. Expectativas: o assert 1 deve ocorrer a
partir do momento em que o motor atinge 900rpm.
O erro máximo de 5%.
Passo 2 Executar a rampa de parada após 1s em 900rpm.
Expectativas: o assert 2 deve ocorrer no mo-
mento em que a rampa de parada é executada, mo-
mento em que o motor deve operar sua velocidade
ainda em 900rpm. O erro deve ser de no máximo
5%.
Fonte – do Autor
A partir dos termos descritivos sobre o teste, o gráfico da dinâmica temporal esperada
após sua execução é ilustrado conforme a Figura 35.
Figura 35 – Dinâmica esperada para o teste 2.
Os asserts, que devem ocorrer em t1 e t2 , devem respeitar as regras retratadas abaixo.
1. Assert 1 : comparação entre a velocidade obtida e velocidade parametrizada (900rpm):

função AssertEqualNumber(valor obtido, 900);
2. Assert 2 : comparação entre a velocidade obtida e velocidade parametrizada (900rpm):

função AssertEqualNumber(valor obtido, 900).
Igualmente ao que foi realizado com o teste 1, o teste 2 foi executado e verificado nas
versões 0.70 e 0.71 do firmware do inversor.
5.2.1 Versão 0.70

A execução do teste 2 no projeto de verificação para a versão 0.70 do firmware surtiu
em um resultado não esperado pela equipe do projeto. O mesmo é ilustrado conforme a
Figura 36.
A partir do gráfico acima, é visualmente notável que ocorreu alguma falha ocorreu no
momento t2 , quando ocorre a comparação para o assert 2 com a ativação da rampa de
parada inversa. É visível um pico de velocidade do motor, que atinge aproximadamente
1025rpm. Ademais a comparação para o assert 1 é visivelmente corroborada em t1 .
Os resultados quantitativos obtidos para a velocidade do motor nos dois instantes (t1
e t2 ) são descritas abaixo.
• Instante t1 : velocidade lida do motor = 900rpm;
• Instante t2 : velocidade lida do motor = 1024.94rpm.
Assim, pode-se dizer que o primeiro assert foi corroborado. Em t2 , o segundo assert,
dado pela função AssertEqualNumber(1024.94, 900) retornou o seguinte erro percentual
entre o valor obtido e o esperado:
1024.94 − 900
Erro(%) = |( )|.100 (5.1)
1024.94
Erro(%) = 12, 189 (5.2)
O erro máximo esperado para o teste, conforme a descrição do ALM, é de 5%, valor
que foi ultrapassado. Portanto, o lançamento de novas versões do firmware deve evitar a
perpetuação da falha no parâmetro de rampa de parada inversa.
5.2.2 Versão 0.71

A partir do teste realizado na versão 0.70, pôde-se perceber a ocorrência de um bug
a partir do momento em que o parâmetro de rampa da parada com sentido inverso foi
executado. Com a ciência de tal fato, a equipe de desenvolvimento do software do inversor
tomou providência para corrigir a falha.
O mesmo teste foi realizado e retornou um resultado apropriado em relação à dinâmica
esperada para o mesmo. O gráfico gerado para o teste 2 na versão 0.71 é ilustrado conforme
a Figura 37.
Diferentemente do resultado obtido no tópico anterior, em que o teste foi realizado

a partir da versão 0.70 do firmware, o gráfico apresenteu uma curva que condiz com a
dinâmica esperada. Visualmente, os dois asserts presentes no teste foram corroborados.
Em termos quantitativos, os resultados obtidos para os dois instantes (t1 e t2 ) são relatados
abaixo.
• Instante t1 : velocidade lida do motor = 900rpm;
• Instante t2 : velocidade lida do motor = 900rpm.
Diante dos resultados vistos acima, pode-se dizer que a nova versão do firmware foi
de grande valia para a evolução da execução do teste. A partir da ocorrência da falha
durante a execução do teste sobre a versão 0.70, medidas foram tomadas para melhor
o desempenho do firmware, o que resultou na corroboração da utilização do projeto de
verificação de testes para o teste em questão.
A partir das execuções dos testes abordados neste capítulo é possível é possível realizar
a geração de históricos local e remoto (por meio do ALM) dos resultados. Com há também
um aspecto de enriquecimento em termos de análise de resultados, tema também proposto
neste documento.
5.3 Históricos de resultados

Os históricos gerados após a execução dos testes abordados neste capítulo podem ser
tanto locais, por meio de arquivo texto, ou remotos, por meio do Application Lifecycle
Management, da HP. Ambos podem ser utilizados para resumir a evolução do algoritmo
do firmware do inversor e dos testes realizados em si.
O primeiro histórico abordado é o local, em seguida se faz uma análise do histórico
gerado remotamente.
5.3.1 Local
Conforme o que foi discorrido no Capítulo 4, o histórico local gerado é baseado em
um arquivo texto, contendo algumas informações importantes a respeito da execução. O
mesmo é gerado após a execução de testes e arquivado em uma pasta local do projeto.
Como observação deste capítulo, os testes 1 e 2 abordados anteriormente são nomeados
como test_505 e test_401 respectivamente. Desta forma, a execução dos testes sobre
as versões 0.70 e 0.71 do firmware retornaram históricos locais ilustrados conforme a
Figura 38.
(a) Histórico local para a versão 0.70. (b) Histórico local para a versão 0.71.
Figura 38 – Históricos locais de resultados gerados.
Com base nas figuras acima, os históricos locais corroboram a ideia dos resultados
obtidos anteriormente, nesta seção. Além disso, o histórico local é importante para manter
um histórico sobre a evolução das execuções dos testes, permitindo ao usuário o acesso à
informações importantes como data, testes realizados e autor da execução dos testes.
5.3.2 Remoto
O histórico remoto diz respeito ao histórico de resultados gerado no ALM após a exe-
cução dos testes pelo usuário. Dentre muitas outras funcionalidades que ALM promove,
como o gerenciamento de requisitos de testes, criação e planejamento de testes, um dos
mais importante é o acompanhamento da evolução dos testes a partir do Test Run.
A partir da execução dos testes trazidos neste capítulo, a geração de histórico no ALM
para a versão 0.70 do firmware é ilustrada conforme a Figura 39.
Figura 39 – Histórico remoto gerado no ALM (versão 0.70 do firmware).

Em adição ao que foi visto no histórico gerado localmente, pode-se conceber a partir
da figura acima, que o ALM apresenta a etapa do teste em que houve ocorrência de falha.
O histórico remoto no ALM gerado após a execução dos testes sobre a versão 0.71 do
firmware é apresentado abaixo, conforme a Figura 40.
Figura 40 – Histórico remoto gerado no ALM (versão 0.71 do firmware).
De acordo com a figura acima, pôde-se corroborar novamente o que foi abordado neste
capítulo no que tange os resultados obtido através da execução dos testes. Vale ressaltar
que, além de apresentar um histórico completo dos resultados das execuções feitas, o ALM
permite aos desenvolvedores acessá-los remotamente de seus computadores, possibilitando
uma flexibilidade maior para o acompanhamento da evolução do projeto do firmware.
81
6 Considerações finais
O presente documento propõe a ideia, desenvolvimento e concepção de um sistema

capaz de verificar testes executados no desenvolvimento de inversores de frequência, na
WEG Drives & Controls. Inversores são dispositivos cujas aplicações impactam signi-
ficativamente nos aspectos produtivos e, consequentemente, financeiros das indústrias e
processos em que os mesmos são empregados. Para processos de movimentação de cargas,
controle de esteiras, bombas, ventilação e sistemas hidráulicos operarem com confiabili-
dade e segurança, um inversor de frequência com boa estrutura, física e lógica, deve se
fazer presente.
Com a evolução gradativa da eletrônica de potência e da eletrônica digital, estes dispo-
sitivos evoluíram e adquiriram características cada vez mais tecnológicas. Além de meros
provedores de potência para outros equipamentos e máquinas, os inversores tornaram-se
sistemas embarcados, permitindo estabelecimento de comunicação através de diferentes
protocolos de redes, recepção de dados a serem executados e fornecimento de informações
importantes acerca dos processos em que são utilizados.
Para gerir essa estrutura complexa existe o firmware, componente essencial do in-
versor, responsável por viabilizar toda a sua infraestrutura lógica. Por ser complexo, o
desenvolvimento do firmware demanda tempo e validação de inúmeros trechos de códigos
computacionais, que afetam de forma total a qualidade da aplicação do inversor.
Diante de todos os conceitos mencionados acima, o projeto desenvolvido permitiu a
existência de uma etapa anterior à validação dos testes do inversor. A etapa de verificação
permite aos desenvolvedor de software do inversor se antecederem a problemas que podem
ser verificados no estágio de validação antes mesmo de lançarem uma nova versão de
firmware.
A partir de uma metodologia de integração, e de uma rica gama de ferramentas e téc-
nicas, foi possível conceber um sistema qualificado para a realização de diversas operações
sobre o inversor. Com o uso de um computador ou microcomputador como o Raspberry
Pi contendo o interpretador da linguagem Python, foi possível estabelecer comunicação
através do protocolo ModBus com o inversor, o que permitiu a execução sequencial e
automática dos seus parâmetros. Baseado nisso, testes envolvendo suas diversas funcio-
nalidades puderam ser concebidos e executados sem a presença humana.
A implementação de comunicação por meio de requisitos HTTP com o ALM possibili-
tou o acompanhamento da evolução do desenvolvimento do firmware a partir de históricos
gerados após a execução dos testes. Para corroborar os objetivos propostos pelo projeto
o Capítulo 5, sobre testes e resultados, apresentou dois testes realizados sobre diferentes
versões do firmware.
Capítulo 6. Considerações finais 82
Com base nos testes abordados neste documento foi possível verificar graficamente e
matematicamente a presença de uma falha no parâmetro de rampa de parada com sentido
inverso, o qual gerou um erro percentual de aproximadamente 12,2% em relação ao valor
esperado, aspecto inadmissível para tal funcionalidade. Por conseguinte, uma nova versão
do software foi lançada atentando-se a esse problema. O resultado obtido, então, foi
satisfatório, já que o erro não persistiu. Todavia, este fato não pode garantir que novos
erros ao executar a mesma funcionalidade ocorram futuramente em novas versões.
Por fim, os históricos gerados e trazidos no mesmo capítulo, comprovam a ideia de
promover o acesso dos desenvolvedores à um conjunto completo de informações sobre
os resultados dos testes executados no inversor durante o desenvolvimento do firmware
do inversor. Além disso, os históricos contribuem para a esquipe de desenvolvimento
obter referências das melhorias ou pioras do projeto ocorridas durante o ciclo de vida do
firmware.
6.1 Trabalhos futuros

Diante de todo o desenvolvimento do projeto e dos seus resultados obtidos é possível
ainda estabelecer que algumas ideias contribuiriam para agregar mais valor ao estado
atual do sistema. Algumas das possibilidades são identificadas abaixo:
• Empregar o projeto em um maior número de inversores: diversificar o uso

da verificação de testes aplicando-o em mais linhas de produto em desenvolvimento,
promovendo melhorias para uma gama maior de projetos;
• Adicionar periféricos para estabelecer leitura de uma gama maior de

informações: conectar o projeto à um maior número de dispositivos para enriquecer
a quantidade de dados tratadas. São exemplos: CLP’s, transdutores para obter
informações de torque do motor acoplado e encoders para obter valores de posição
e velocidade do eixo do motor;
• Realizar testes integrando o projeto ao Jenkins: a utilização do Jenkins na

realização de testes enriqueceria a gama de resultados fornecidos através do projeto;
• Realizar a verificação de um quantidade maior de testes: aplicar o pro-

jeto de maneira contínua no desenvolvimento do firmware buscando criar e realizar
quantidades maiores e tipos diferentes de testes;
• Embarcar o projeto em um sistema operacional customizado no Rasp-

berry Pi: utilizar o conceito de customização de sistemas operacionais, como o
Linux, através de ferramentas como o Buildroot ou Yocto Project a fim de promo-
ver ao projeto maior velocidade de processamento e menor consumo de recursos
computacionais do Raspberry Pi.
83
Referências Bibliográficas
1 CFW500. [S.l.]: WEG S.A. <https://static.weg.net/medias/images/h9d/h6d/WDC_

InversorFrequencia_CFW500_mec_A_1200Wx1200H.jpg>. Acessado em 12 Out. 2019.
8, 19
2 FRANCHI, C. M. Inversores de Frequência: Teorias e Aplicações. [S.l.]: Editora
Érica, 2009. ISBN 9788536502106. 8, 19, 20, 21
3 CFW500: Manual de Programação. [S.l.]. Acessado em 12 Out. 2019. 8, 23
4 TAMBOLI, S. et al. Implementation of modbus rtu and modbus tcp communication
using siemens s7-1200 plc for batch process. 2015 International Conference on Smart
Technologies and Management for Computing, Communication, Controls, Energy and
Materials (ICSTM), 2015. 8, 31, 32
5 RASPBERRY. <https://www.raspberrypi.org/
homepage-9df4b/static/eef5d5d91acb34be0d7443b02cece1d1/bc3a8/
8c67a3e02f41441dae98f8b91c792c1e1b4afef1_770a5842.jpg>. Acessado em 12
Out. 2019. 8, 38
6 FRANCHI, C. M. Acionamentos Elétricos. [S.l.]: Editora Érica, 2009. ISBN
8536501499. 14, 18, 22
7 GURGEL, F. M. Aplicações de Inversores Eletrônicos na Indústria Nacional: A
Contribuição Brasileira. 2009. Monografia (Engenharia Elétrica), Universidade Federal
do Rio de Janeiro. 14
8 TüZüN, E. et al. Adopting integrated application lifecycle management within a
large-scale software company: An action research approach. The Journal of Systems and
Software, 2018. 15, 30
9 INSTITUCIONAL WEG. [S.l.]. Acessado em 12 Out. 2019. 16
10 ISTO É WEG. <https://static.weg.net/medias/downloadcenter/hc8/h05/
50020771_portuguese_web.pdf>. Acessado em 12 Out. 2019. 16
11 STEMMER, M. R. Redes Locais Industriais. [S.l.]: UFSC, 2010. 24, 25
12 DEVICENET. <https://www.odva.org/Portals/0/Library/Publications_
Numbered/PUB00026R4_Tech-Adv-Series-DeviceNet.pdf>. Acessado em 12 Out. 2019.
25
13 PERES, R. de P. Redes de Comunicação Profibus. 2012. Monografia (Engenharia
Elétrica), Universidade São Francisco. 26
14 SAUTER, M. F. T. Standardization of industrial ethernet – the next battlefield? 6th
IEEE International Workshop on Factory Communication Systems, p. 413–421, 2004. 26
15 MODBUS. <http://modbus.org/>. Acessado em 12 Out. 2019. 26, 31
16 LUGLI, A. B. Uma visão do protocolo industrial profinet e suas acplicações. 26
Referências Bibliográficas 84
17 NEWMAN, H. M. Bacnet
R explained. A Suplement to ASHRAE Journal, 2013. 26
18 LAGE, F. Comunicação industrial. 2009. Monografia (Engenharia de Controle e

Automação), Universidade Federal de Ouro Preto. 26
19 GAJJAR, M. Sensor validation and hardware–software codesign. In: . [S.l.:

s.n.], 2017. p. 191–212. ISBN 9780128016602. 26
20 MENEGHEL, L. F. Desenvolvimento de Firmware para Nova Linha de Inversores.

2013. Monografia (Engenharia de Controle e Automação), Universidade Federal de Santa
Catarina. 27
21 BERNERS-LEE, T. et al. Hypertext Transfer Protocol — HTTP/1.0. [S.l.], 1996. 27
22 KORDIC, G.; HUSNJAK, S.; GURGUREVIC, I. Analysis of the application lifecycle

management. ISEP 2017, 2017. 30
23 DOWNEY, A. Think Python: How to Think Like a Computer Scientist. [S.l.]: Green
Tea Press, 2012. 33
24 KUHLMAN, D. A Python Book: Beginning Python, Advanced Python, and Python

Exercises. [S.l.]: Green Tea Press, 2013. 33
25 GITHUB. <https://octoverse.github.com/2017/>. Acessado em 12 Out. 2019. 33
26 JANSEN, B. J. The graphical user interface: An introduction. SIGCHI Bulletin,

1998. 34
27 JR., D. R. O. Evaluating User Interface Systems Research. 2007. 34
28 BUXTON, W. et al. Towards a comprehensive user interface management system.

SIGGRAPH ’83 Proceedings of the 10th annual conference on Computer graphics and
interactive techniques, 1996. 34
29 NOERGAARD, T. Embedded System Architecture: A Comprehensive Guide for

Engineers and Programmers. [S.l.]: Elsevier Inc., 2013. 35, 36
30 HEATH, S. Embedded Systems Design, 2nd Edition. [S.l.]: Elsevier Inc, 2002. 36
31 KIRBY, J.; CHAPMAN, L.; CHAPMAN, V. Assessing the raspberry pi as a low-cost

alternative for acquisition of near infrared hemispherical digital imagery. Agricultural
and Fores Meteorology, p. 232–239, 2018. 37
32 WHAT IS LINUX. <https://www.linux.com/what-is-linux/>. Acessado em 12 Out.

2019. 38
33 SETH, N.; KHARE, R. Aci (automated continuous integration ) using jenkins:

Key for successful embedded software development. Proceedings of 2015 RAECS UIET
Panjab University Chandigarh 21-22nd December 2015, 2015. 39
34 JENKINS. <https://jenkins.io/>. Acessado em 12 Out. 2019. 39
35 RAIKWAR, S. et al. Hardware-in-the-loop test automation of embedded systems for

farm tractors. The Journal of Systems and Software, 2018. 40
Referências Bibliográficas 85
36 KUMAR, D.; MISHRA, K. K. The impacts of test automation on software’s cost,

quality and time to market. 7th International Conference on Communication, Computing
and Virtualization 2016, 2016. 41

TCC Martin 2020

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

TCC Martin 2020

Enviado por

Direitos autorais:

Formatos disponíveis

Universidade Federal de Santa Catarina

Martin Hermes Anschau

Sistema de Verificação Automática de Testes no

Sistema de Verificação Automática de Testes no

Trabalho de Conclusão de Curso apresentado à Universidade Fede-

Universidade Federal de Santa Catarina

Primeiramente agradeço à família da minha mãe, por sempre ter me proporcionado,

Com a constante evolução em termos de computação e eletrônica os inversores de

Figura 1 – Inversor de frequência CFW500 da WEG S.A. [1] . . . . . . . . . . . . 19

Tabela 1 – Exemplos de parâmetros do motor e inversor . . . . . . . . . . . . . . . 24

UFSC Universidade Federal de Santa Catarina

2 REVISÃO DAS TECNOLOGIAS UTILIZADAS . . . . . . . . 18

4 METODOLOGIA E IMPLEMENTAÇÃO DO PROJETO . . 48

O acionamento de máquinas e equipamentos mecânicos por motores elétricos é um as-

1.1 Objetivos do projeto

1. Estruturar detalhadamente os testes a serem verificados;

2. Tomar ciência do estado atual do firmware do inversor;

3. Desenvolver um software embarcado para a realização dos testes;

4. Realizar testes integrados, que envolvem todas as partes do inversor;

5. Centralizar as informações de cada teste em um banco de dados;

6. Verificar erros e falhas inesperdas no firmware;

7. Integrar o projeto com interface gráfica de usuário.

1.2 A empresa WEG Equipamentos Elétricos

Produzindo inicialmente motores elétricos, a WEG ampliou suas atividades a partir da

• Missão: Crescimento contínuo e sustentável, mantendo a simplicidade;

• Valores: Companhia Humana, Trabalho em Equipe, Eficiência, Flexibilidade, Ino-

• Motores elétricos: possui uma completa linha de motores e caixas redutoras,

• Automação: Variedade completa de dispositivos elétricos eletrônicos para o apri-

• Transmissão e distribuição: fornecimento de soluções envolvendo transformado-

• Energia: manufatura de máquinas grandes, como tubo e hidrogeradores, geradores

• Tintas e vernizes: produz uma linha extensa de tintas industriais, tintas em pó e

Diante do exposto, pode-se salientar que o projeto ocorreu no interior da área de

1.3 Estrutura do documento

• No Capítulo 2 são delineadas revisões, explicações e os fundamentos das tecnologias

• No Capítulo 3 é discutida a arquitetura generalizada do projeto, capítulo em que as

• O Capítulo 4, sobre metodologia e implementação do projeto, apresenta de forma

• O Capítulo 5 se refere aos testes e resultados obtidos segundo a arquitetura ela-

• O Capítulo 6 se refere às considerações finais do projeto diante dos resultados ob-

2 Revisão das tecnologias utilizadas

2.1 Inversores de frequência

Figura 1 – Inversor de frequência CFW500 da WEG S.A. [1]

O inversor trata-se de um produto em que o usuário pode configurar e visualizar

Figura 2 – Estimativa de uso de máquinas elétricas na indústria [Fonte: Franchi [2]].

Dando continuidade ao estudo sobre os inversores, dispositivo de fundamental impor-

2.1.1 Princípios básicos

1. Retificador: por normas nacionais, a tensão fornecida na rede oscila em 60Hz

Figura 3 – Retificador do inversor [Fonte: Franchi [2]].

2. Controle: a tensão contínua gerada na saída do retificador é conectada a saída

Figura 4 – Saída de controle do inversor [Fonte: Franchi [2]].

3. Saída: com a parte de controle consolidada é possível estabelecer a tensão de saída

Por intermédio da união das três etapas do drive, é estabelecido um conversor de

Figura 5 – Inversor aplicado a um motor de indução trifásico [Fonte: Franchi [2]].

Figura 6 – Blocos de componentes do inversor [Fonte: Franchi [2]].

2.1.2 Unidade central de processamento

2.1.3 Interface homem-máquina

Figura 7 – IHM do CFW500 da WEG S.A. [3]

• Parâmetros de regulação: são valores ajustáveis a serem utilizados pelas funções

• Parâmetros configuração: parâmetros que definem as características do inversor,

• Parâmetros do motor: valores que indicam as características nominais do motor a

Dependendo do fabricante, cada tipo de configuração pode possuir diversos tipos de

Tabela 1 – Exemplos de parâmetros do motor e inversor

Nome Identificador Parâmetro

2.1.5 Protocolos de comunicação em inversores

• Uma interface (serial ou paralela);