Monitoramento NH3 Aviários

UNIVERSIDADE DO OESTE DE SANTA CATARINA
CAMPUS JOAÇABA
ÁREA DAS CIÊNCIAS EXATAS E DA TERRA
CURSO DE ENGENHARIA DE COMPUTAÇÃO
JEAN LUIZ ZANATTA
J. SISMAAG - SISTEMA PARA MONITORAMENTO DO GÁS AMÔNIA EM
AVIÁRIOS
Joaçaba - SC
2014

JEAN LUIZ ZANATTA
AVIÁRIOS
Trabalho de Conclusão de Curso apresentado ao
Curso de Engenharia de Computação, Área das
Ciências Exatas e da Terra, da Universidade do
Oeste de Santa Catarina, como requisito parcial à
obtenção do grau de Bacharel em Engenharia de
Computação.
Orientador: Prof. MSc. Daniel Calixto Fagonde Moraes
.
Joaçaba - SC
2014

Z27j Zanatta, Jean Luiz
J. Sismaag – Sistema para monitoramento do gás amônia em aviários. / Jean
Luiz Zanatta. UNOESC, 2014.
114 f.; 30 cm.
Trabalho de Conclusão de Curso (Graduação em Engenharia de Computação)
— Universidade do Oeste de Santa Catarina, 2014.
Bibliografia: f. 104 - 108.
1. Engenharia de Computação – Automação Industrial. 2. Telemetria I. Título.
CDD – 621.382
Ficha catalográfica elaborada pelo bibliotecário Alvarito Baratieri – CRB-14º/273

JEAN LUIZ ZANATTA
AVIÁRIOS
Trabalho de Conclusão de Curso apresentado ao
Curso de Engenharia de Computação, Área das
Ciências Exatas e da Terra, da Universidade do
Oeste de Santa Catarina, como requisito parcial à
obtenção do grau de Bacharel em Engenharia de
Computação.
Aprovado em: 10/12/2014
BANCA EXAMINADORA

AGRADECIMENTOS
 Primeiramente agradeço a Deus por estar sempre presente e ter me dado
oportunidade, saúde e força para cumprir mais uma etapa em minha vida.
 Aos meus pais, Eliseu Luiz Zanatta e Arlete Balestrin Zanatta, que sempre
deram apoio incondicional e incentivo em todas as atividades de minha vida.
 À minha namorada Mileide Sofia Batista por toda paciência, compreensão, amor
e carinho, e por sempre estar ao meu lado apoiando e incentivando a realização
deste trabalho.
 Ao meu orientador professor Daniel Calixto Fagonde Moraes por transmitir seu
conhecimento e fazer de meu trabalho de conclusão de curso uma experiência
positiva e por ter confiado em mim, sempre me orientando e dedicando parte do
seu tempo.
 A todos os professores em especial à professora Rogeria Ramos pelo resultado
de um esforço mútuo em prol do desenvolvimento deste trabalho.
 Ao Sr. Paulo Rogério Ortiz Batista e sua equipe da Altem Tecnologia pela
oportunidade, incentivo, apoio e infra-estrutura para o desenvolvimento e
conclusão deste trabalho.
 Aos amigos pela ótima convivência.
 A todas as pessoas que fazem parte de minha vida e que de alguma maneira
contribuíram.

RESUMO
A aquisição de dados, nos últimos anos, tem evoluído de forma significativa e se torna
indispensável nas mais variadas aplicações, como nas áreas de agricultura, saúde e
engenharias. O estado da arte nessa área envolve o uso de uma série de tecnologias para
aquisição, processamento, transmissão e visualização dos dados coletados do ambiente,
bem como o uso da Internet, um dos meios de comunicação mais avançados e utilizados
mundialmente, que se consolidou como uma fonte completa de informações devido à
alta tecnologia que envolve à sua capacidade de comunicação a longas distâncias. O
objetivo deste trabalho é a elaboração do protótipo de um sistema web que integre
software e hardware, para o monitoramento da concentração do gás amônia em
aviários. O protótipo conta com um moderno sistema de telemetria, baseado em
aquisição de dados, comunicação sem fio via rede GSM, com conexão via Internet
através de um sistema de telefonia celular GPRS e interface dos Módulos de hardware
baseada em microcontroladores da família ARM. O software para monitoramento dos
dados é uma aplicação Web. No decorrer do trabalho serão apresentadas as várias fases
empregadas na criação do sistema, desde a análise, planejamento, implementação, testes
e ferramentas utilizadas. Pode-se concluir que, depois de desenvolvido, este sistema
pode também servir de base para aplicações em diferentes áreas onde existe a presença
do gás amônia e a telemetria seja indispensável.
Palavras-chave: Gás Amônia. Telemetria. Microcontrolador. Sistema Embarcado.

ABSTRACT
Data acquisition in recent years, has evolved significantly and becomes indispensable
in various applications, such as in the areas of agriculture, health and engineering. The
state of the art in this area involves using a number of technologies for acquiring,
processing, transmission and visualization of data collected from the environment as
well as using the Internet, one of the most advanced means of communication and used
worldwide, which has become a complete source of information due to the high
technology that involves the ability to communicate over long distances. The objective
of this work is the development of a prototype web-based system that integrates
software and hardware for monitoring the concentration of ammonia gas in aviaries.
The prototype has a modern telemetry system, based on data acquisition, wireless
communications via GSM network with Internet connection through a GPRS cellular
system and interface modules of hardware based on ARM microcontroller family. The
software for data monitoring is a Web application In the course of work will be
presented the various phases used in the creation of the system, from planning, analysis,
implementation, testing and tools used. It can be concluded that, once developed, this
system can serve as a basis for application in different areas where there is the
presence of ammonia gas and telemetry is indispensable.
Keywords: Ammonia Gas. Telemetry. Microcontroller. Embedded System.

LISTA DE ILUSTRAÇÕES
Diagrama 1 - Padrão modelo MVC..........................................................................................27
Diagrama 2 - Casos de Uso do Sistema de Monitoramento do Gás Amônia em Aviários. .....54
Diagrama 3 - Diagrama de Sequencia Registrar Concentração de NH³...................................55
Diagrama 4 - Modelo Conceitual. ............................................................................................56
Diagrama 5 - Diagrama de Comunicação Inserir Dispositivo..................................................59
Diagrama 6 - Diagrama de Comunicação Alterar Dispositivo.................................................59
Diagrama 7 - Diagrama de Comunicação Excluir Dispositivo. ...............................................60
Diagrama 8 - Diagrama de Comunicação Registrar Concentração de NH³. ............................60
Diagrama 9 - Diagrama de Classes do Projeto.........................................................................61
Diagrama 10 - Diagrama da Modelagem Conceitual do Banco de Dados...............................62
Diagrama 11 - Diagrama do Modelo Lógico do Banco de Dados. ..........................................62
Diagrama 12 - Diagrama de Estados de Navegação.................................................................64
Diagrama 13 - Contexto do Projeto do Dispositivo. ................................................................79
Diagrama 14 - Requisitos Funcionais do Projeto do Dispositivo.............................................80
Diagrama 15 - Requisitos Funcionais do Projeto do GSM. .....................................................81
Esquema 1 – Modelo Cliente / Servidor...................................................................................24
Esquema 2 - Esquema de blocos e periféricos LPC 1766. .......................................................41
Esquema 3 - Visão Geral do Sistema. ......................................................................................49
Esquema 4 - Esquema do Circuito de Condicionamento do Sinal...........................................76
Esquema 5 - Principais Conexões do Módulo Slave (Dispositivo)..........................................77
Figura 1 - Projeto Gráfico da Tela de Login. ...........................................................................64
Figura 2 - Projeto Gráfico da Tela Principal Admin. ...............................................................65
Figura 3 - Projeto Gráfico da Tela Listar Usuários. .................................................................66
Figura 4 - Projeto Gráfico do Formulário dialogUsuario. .......................................................67
Figura 5 - Projeto Gráfico da Tela de Listar Módulos GSM....................................................68
Figura 6 - Projeto Gráfico do Formulário dialogModuloGSM.................................................68
Figura 7 - Projeto Gráfico da Tela de Listar Dispositivos........................................................69
Figura 8 - Projeto Gráfico do Formulário dialogDispositivo. ..................................................70
Figura 9 - Projeto Gráfico da Tela de Registros de NH³ Para Administrador..........................70
Figura 10 - Projeto Gráfico da Tela Principal Cliente..............................................................71
Figura 11 - Dados de Concentração de NH³ Medidos no Aviário. ........................................101

Fluxograma 1 - Processo Gerenciamento de Hardware e Interfaceamento.............................82
Fluxograma 2 - Subprocesso Gerenciamento do Dispositivo. .................................................82
Fluxograma 3 - Subprocesso Configurar Pinos do Sensor.......................................................83
Fluxograma 4 - Subprocesso Configurar Pinos de Comunicação com GSM...........................83
Fluxograma 5 - Subprocesso Solicitar Leitura do Sensor. .......................................................84
Fluxograma 6 - Subprocesso Tratar Pacotes. ...........................................................................84
Fluxograma 7 - Subprocesso Gerenciamento do GSM. ...........................................................85
Fluxograma 8 - Subprocesso Configurar Pinos de Comunicação com SIM900. .....................85
Fluxograma 9 - Subprocesso Buscar Dispositivos no Barramento RS-485.............................86
Fluxograma 10 - Subprocesso Solicitar Créditos. ....................................................................86
Fluxograma 11 - Subprocesso Abrir Conexão com Servidor...................................................87
Fluxograma 12 - Subprocesso Enviar Dados p/ Servidor. .......................................................87
Fluxograma 13 - Subprocesso Atualizar Data e Hora..............................................................87
Fluxograma 14 - Subprocesso Solicitar CSQ...........................................................................88
Fluxograma 15 - Subprocesso Solicitar Concentração de NH³ via RS-485.............................88
Fluxograma 16 - Subprocesso Envia SMS de Aviso p/ Celular do Cliente. ............................89
Fotografia 1 - Ambiente Interno de um Aviário.......................................................................21
Fotografia 2 - Sensor de gás amônia TGS 2444.......................................................................34
Fotografia 3 - Módulo Slave.....................................................................................................40
Fotografia 4 - Módulo Master Frente / Verso. .........................................................................43
Fotografia 5 - Módulo GSM / GPRS SIM900..........................................................................44
Fotografia 6 - Testes Gás Alert NH3 e Dispositivo. ................................................................96
Fotografia 7 - Caixa com os Módulos Dispositivo e GSM. ...................................................100
Fotografia 8 - Módulos Instalados no Aviário. ......................................................................100
Fotografia 9 - SMS de Aviso..................................................................................................101
Gráfico 1 - Sensibilidade do Sensor TGS 2444........................................................................78
Gráfico 2 - Sensor Response Pattern........................................................................................97

LISTA DE QUADROS
Quadro 1 – Arquitetura do Protocolo TCP / IP. .......................................................................25
Quadro 2 - Diagrama do Ciclo de Funcionamento do Sensor..................................................35
Quadro 3 - Protocolo de Comunicação Padrão RS-485. ..........................................................37
Quadro 4 - Requisito Funcional Manter Informações de Usuário............................................50
Quadro 5 - Requisito Funcional Manter Informações de Módulo GSM..................................51
Quadro 6 - Requisito Funcional Manter Informações de Dispositivo......................................52
Quadro 7 - Requisito Funcional Gerenciar Registros de Concentração do Gás Amônia.........53
Quadro 8 - Atores do Sistema...................................................................................................54
Quadro 9 - Contrato Operação Indicar Dispositivo..................................................................56
Quadro 10 - Contrato Operação Registrar Nova Concentração NH³. ......................................57
Quadro 11 - Contrato Operação Inserir Dispositivo.................................................................57
Quadro 12 - Contrato Operação Alterar Dispositivo................................................................58
Quadro 13 - Contrato Operação Excluir Dispositivo. ..............................................................58
Quadro 14 - Classe Java ServidorTCP. ....................................................................................74
Quadro 15 – NH³ (ppm) em Função da Resistência (ohm) do Sensor. ....................................78
Quadro 16 - Configuração Inicial dos Pinos Responsáveis por Controlar a Corrente Elétrica
no sensor...................................................................................................................................90
Quadro 17 - Função Responsável pela Aquisição do Sinal......................................................90
Quadro 18 - Função Responsável por Realizar a Conversão em ppm. ....................................91
Quadro 19 - Rotina Principal do Sistema Embarcado Dispositivo e Método Trata_pacotes().91
Quadro 20 - Função Responsável por Buscar Dispositivos no Barramento RS-485. ..............92
Quadro 21 - Funções de Comunicação com SIM900...............................................................93
Quadro 22 - Rotina Principal do Sistema Embarcado GSM. ...................................................94
Quadro 23 - Operações de Deslocamento e Lógica de Bits na Variável NH³..........................98

LISTA DE SIGLAS E ABREVIATURAS
ADC Conversor Analógico/Digital
Ah Corrente Camada de Aquecimento do Sensor
API Application Programming Interface
As Corrente Camada de Leitura do Sensor
ARM Advanced RISC Machine
ASCII American Standard Code for Information Interchange
BPMN Business Process Model and Notation
CDMA Code Division Multiple Access
CEPT Conference of European Posts and Telegraphs
CPU Central Processing Unit
CRC Cálculo de Redundância Cíclica
CSQ Qualidade do Sinal GSM
CSS Cascading Style Sheets
DAO Data Access Object
dBm Decibel Miliwatt
DCD Pino de Verificação POWER SIM900
DCE Data-communication equipment
DECT Digital Enhanced Cordless Telecommunications
DTE Data-terminal equipment
EE Enterprise Edition
EIA Electronic Industries Alliance
ETSI European Telecomunication Standards Institute
FTP File Transfer Protocol
GND Graduated Neutral Density Filter
GPL General Public License
GPIO General Purpose Input/Output
GPRS General Packet Radio Service
GSM Global System for Mobile Communication
GUI Graphical User Interface
H Hidrogênio
HTML HyperText Markup Language
HTTP Hypertext Transfer Protocol

IMAP Internet Message Access Protocol
ID Endereço Identificador
IDE Integrated Development Environment
I/O Input/Output
IP Internet Protocol
JPA Java Persistence API
JSF Java Server Faces
JTAG Joint Test Action Group
LCD Liquid Crystal Display
LPC Família de Microcontroladores da NXP Semiconductors
LTDA Limitada
MCO2 Hospedagem de Sites
MySQL Sistema de Gerenciamento de Bancos de Dados
MVC Model View Controller
N Nitrogênio
NCSA National Center for Supercomputing Applications
NH³ Gás Amônia
NEC Numerical Electromagnetics Code
NTP Network Time Protocol
NXP Empresa de Semicondutores
OSI Open Systems Interconnection
PDP Packet Data Protocol
PNP Transistor de Lógica Positiva
POJO Plain Old Java Object
POO Programação Orientada a Objetos
POP³ Post Office Protocol
PPM Partícula Por Milhão
PORT Porto do Microcontrolador
RDSI Rede Digital de Serviços Integrados
RISC Reduced Instruction Set Computer
RIT Repetitive Interrupt Timer
Rs Resistência
RS Recommended Standard.
RTU Remote Terminal Unit

RTX Real-Time Operating System
RX Receiver Mode
SGBD Sistema Gerenciador de Banco de Dados
SGML Standard Generalized Markup Language
SMS Short Message Service
SMTP Simple Mail Transfer Protocol
SQL Structured Query Language
SysML Systems Modeling Language
TCC Trabalho de Conclusão de Curso
TCP Transmission Control Protocol
TCX Training Center XML
TDMA Time Division Multiple Access
TGS Modelo do sensor utilizado no projeto
TX Transmitter Mode
UART Universal Asynchronous Receiver Transmitter
uC Microcontrolador
UML Unified Modeling Language
URI Uniform Resource Identifier
URL Uniform Resource Locator
USB Universal Serial Bus
Vc Tensão na Camada de Aquecimento do Sensor
VCC Volts Corrente Contínua
Vh Tensão na Camada de Leitura do Sensor
XHTML Extensible HyperText Markup Language
WLAN Wireless LAN
WWW World Wide Web

SUMÁRIO
1 INTRODUÇÃO ...................................................................................................16
1.1 PROBLEMATIZAÇÃO........................................................................................17
1.2 JUSTIFICATIVA ..................................................................................................17
1.3 OBJETIVOS..........................................................................................................18
1.3.1 Objetivo Geral......................................................................................................18
1.3.2 Objetivos Específicos...........................................................................................18
1.4 HIPÓTESE ............................................................................................................18
1.5 CRONOGRAMA ..................................................................................................19
2 FUNDAMENTAÇÃO TEÓRICA......................................................................20
2.1 CARACTERIZAÇÃO DO SETOR AVÍCOLA NO BRASIL ..............................20
2.2 AVIÁRIOS ............................................................................................................21
2.3 GÁS AMÔNIA NA PRODUÇÃO DE FRANGOS DE CORTE...........................22
2.4 APLICAÇÃO WEB ...............................................................................................23
2.4.1 Arquitetura Cliente/Servidor .............................................................................23
2.4.2 Protocolos TCP/IP e HTTP.................................................................................24
2.4.3 Servidor Web Apache Tomcat .............................................................................25
2.4.4 Java Persistence API e framework Hibernate.....................................................26
2.4.5 Framework Java Server Faces e Primefaces.......................................................26
2.4.6 Padrão Modelo MVC ..........................................................................................27
2.4.7 Linguagem de marcação HTML e o arquivo XHTML....................................28
2.4.8 Banco de Dados MySQL .....................................................................................28
2.5 ENGENHARIA DE SOFTWARE..........................................................................29
2.5.1 Levantamento de Requisitos...............................................................................30
2.5.2 UML......................................................................................................................30
2.5.3 SysML ...................................................................................................................31
2.5.4 BPMN....................................................................................................................31
2.6 MÓDULOS DE HARDWARE E INTERFACEAMENTO ....................................32
2.6.1 Aquisição de Sinais ..............................................................................................32
2.6.2 Sensores ................................................................................................................33
2.6.2.1 Sensor de Gás Amônia Fígaro TGS 2444..............................................................34
2.6.3 Comunicação Serial.............................................................................................35
2.6.3.1 Padrão Serial RS-485.............................................................................................35

2.6.3.1.1 Protocolo de Comunicação ...................................................................................36
2.6.4 Tecnologias de Comunicação Sem Fio...............................................................37
2.6.4.1 Sistema GSM – Global System for Mobile............................................................38
2.6.4.2 GPRS – General Packet Radio Service.................................................................39
2.6.5 Módulo Slave: Dispositivo...................................................................................39
2.6.5.1 Microcontrolador ARM NXP LPC 1766...............................................................40
2.6.5.1.1 Circuito ADC - Analog to Digital Converter ........................................................42
2.6.6 Módulo Master: GSM..........................................................................................43
2.6.6.1 Módulo GSM/GPRS SIM900................................................................................44
2.6.6.1.1 Comandos AT ........................................................................................................44
3 METODOLOGIA................................................................................................46
3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA.................................................46
3.2 MATERIAIS..........................................................................................................47
3.2.1 Software De Modelagem Lógica e Conceitual ...................................................47
3.2.2 Software de Programação....................................................................................47
3.2.3 Materiais de Hardware ........................................................................................47
3.3 MÉTODOS............................................................................................................48
4 DESENVOLVIMENTO......................................................................................49
4.1 DOCUMENTO DE ESPECIFICAÇÃO DE REQUISITOS PARA A
APLICAÇÃO WEB DE MONITORAMENTO.....................................................49
4.1.1 Levantamento de Requisitos...............................................................................49
4.1.2 Modelo de Casos de Uso......................................................................................54
4.1.3 Análise...................................................................................................................55
4.1.3.1 Diagrama de Sequência .........................................................................................55
4.1.3.2 Modelo Conceitual.................................................................................................56
4.1.3.3 Contratos................................................................................................................56
4.1.4 Projeto da Camada Model...................................................................................58
4.1.4.1 Diagrama de Comunicação....................................................................................59
4.1.4.2 Diagrama de Classes do Projeto ............................................................................60
4.1.4.3 Modelagem do Bando de Dados............................................................................61
4.1.5 Projeto da Camada View.....................................................................................63
4.1.5.1 Diagrama de Estados de Navegação......................................................................63
4.1.5.2 Projeto Gráfico das Telas do Sistema....................................................................64
4.1.6 Projeto da Camada Controller............................................................................72

4.1.7 Servidor: Comunicação e Armazenamento dos Dados....................................74
4.2 DESENVOLVIMENTO DOS MÓDULOS DE HARDWARE E
INTERFACEAMENTO ........................................................................................75
4.2.1 Circuito de Condicionamento do Sinal do Dispositivo.....................................75
4.2.1.1 Processamento dos Dados......................................................................................77
4.2.2 Contexto do Projeto.............................................................................................79
4.2.3 Requisitos Funcionais..........................................................................................80
4.2.4 Modelagem dos Processos...................................................................................82
4.2.5 Sistema Embarcado do Dispositivo....................................................................89
4.2.6 Sistema Embarcado do GSM..............................................................................92
5 RESULTADOS ....................................................................................................96
5.1 AQUISIÇÃO E PROCESSAMENTO DOS DADOS ...........................................96
5.2 COMUNICAÇÃO ENTRE DISPOSITIVO E GSM .............................................97
5.3 COMUNICAÇÃO ENTRE GSM E APLICAÇÃO WEB DE
MONITORAMENTO............................................................................................98
5.4 ANÁLISE DO MONITORAMENTO DOS DADOS MEDIDOS EM CAMPO...99
6 CONCLUSÃO....................................................................................................102
6.1 SUGESTÕES DE TRABALHOS FUTUROS.....................................................102
REFERÊNCIAS.................................................................................................104
APÊNDICES ......................................................................................................109
APÊNDICE A – SCRIPT DO MODELO FÍSICO DO BANCO DE DADOS...110
APÊNDICE B – CONFIGURAÇÃO DO SERVIDOR VIRTUAL NO
ROTEADOR D-LINK DIR-600..........................................................................111
ANEXOS.............................................................................................................113
ANEXO A - QUADRO COM OS CÓDIGOS “AT” DE ACESSO E
CONFIGURAÇÃO UTILIZADOS PARA GERENCIAMENTO DO SIM 900.114

16
1 INTRODUÇÃO
A presença do gás amônia em aviários vem sendo discutida em todo mundo,
principalmente por duas razões: existem evidências epidemiológicas de que a saúde dos
trabalhadores possa ser afetada pela exposição diária aos diversos poluentes aéreos
(MIRAGLIOTTA, 2000). Segundo Curtis (1983), o efeito do gás amônia sobre a saúde
animal ocorre, em primeira instância, como irritante de mucosas dos olhos e das vias
respiratórias. Posteriormente, ao cair na corrente sanguínea, tem efeito tóxico sobre o
metabolismo fisiológico, podendo levar a óbito.
A maioria dos criadores desconhece as perdas ocasionadas pela concentração do gás
amônia em seus aviários. Além disso, os humanos perdem a sua sensibilidade olfativa depois
de longos ou repetidos períodos de exposições ao mesmo odor, também dessa forma, as aves
são afetadas muito antes que o problema seja percebido ou identificado por seus criadores.
Com base nestas afirmações, este trabalho de conclusão de curso propõe um sistema,
utilizando software1
e hardware2
, que visa detectar e monitorar a concentração do gás amônia
em aviários, possibilitando ao integrado a visualização dos dados em tempo real, podendo
assim adotar as melhores medidas para controlar a concentração deste gás no ambiente,
preservando a qualidade do ar e evitando perdas na produtividade e no negócio.
As tarefas realizadas envolvem a elaboração dos documentos de especificação de
requisitos e desenvolvimento do software web, firmwares e banco de dados do sistema. O
trabalho está estruturado em sessões e subsessões que mantém uma sequência lógica e
coerente, a saber. Na primeira sessão a introdução, além de uma visão geral do escopo do
trabalho, também apresenta a problematização, objetivos, hipótese e cronograma. Em seguida
encontra-se a fundamentação teórica que apresenta um estudo referente, ao setor avícola no
Brasil, aviários e gás amônia, e às tecnologias utilizadas para solucionar o problema. Na
sessão três, apresenta-se a metodologia geral para execução das atividades estabelecidas. Em
seguida é apresentado o desenvolvimento do projeto e resultados. Por fim encontra-se a
conclusão sobre a pesquisa e o trabalho realizado, enfatizando a viabilidade prática da
aplicação e também as ações potenciais.
1
Software é a parte lógica de um computador, ou seja, é a manipulação, instrução de execução, redirecionamento
e execução das atividades lógicas das máquinas (DANTAS, 2008).
2
Hardware é a parte física do computador, ou seja, o conjunto de aparatos eletrônicos, peças e equipamentos que
fazem o computador funcionar (DANTAS, 2008).

17
1.1 PROBLEMATIZAÇÃO
No Estado de Santa Catarina, a atividade avícola de corte é realizada por meio de
modelos de integração com produtores. Produção integrada é um sistema de produção de
frangos de corte, realizado em parceria, de forma contratual, entre uma indústria ou
cooperativa, chamada de integradora, e o produtor de frangos, chamado de integrado, que
atuam nos chamados aviários. (ZANATTA, 2007).
Contudo, o ambiente de trabalho em aviários, segundo Fernandes e Furlaneto (2004),
tem sido motivo de discussões no que se refere à ocorrência de riscos biológicos relacionado à
saúde do homem e animal. O gás amônia é liberado a partir da decomposição anaeróbica dos
dejetos das aves. Sua monitoração é muito importante para garantir o bem-estar dos
trabalhadores do aviário e das aves. Estudos sugerem que o estresse causado por más
condições ambientais resultam em deformação e em má qualidade da carne. Além disso, altas
concentrações do gás amônia também são responsáveis pelo baixo nível e desenvolvimento
das aves, resultando numa queda direta dos ganhos com a produtividade e também dos
negócios.
Neste contexto, o problema de pesquisa que norteia o presente estudo refere-se a
elaborar e implantar um sistema de monitoramento do gás amônia dos aviários da região do
município de Joaçaba, para que o integrado tenha acesso aos dados coletados em tempo real,
podendo observar a sua concentração, e então adotar a melhor medida possível para controlar
esse gás tóxico.
1.2 JUSTIFICATIVA
A relevância do estudo assenta-se no fato de que o monitoramento de gases tóxicos de
aviários, com ênfase no gás amônia, poderá ampliar a discussão sobre as formas de
prevenção, controle desse risco biológico específico do trabalho em aviários, portanto, de
interesse para a área da economia agrícola e saúde humana e animal. Além disso, o estudo
justifica-se pela acentuada presença de integrados de aves na região do meio oeste
catarinense.
O desenvolvimento da tecnologia web está relacionado à necessidade de simplificar a
atualização e manutenção, mantendo o código fonte em um mesmo local. O usuário também
poderá realizar o acesso ao sistema de qualquer lugar, desde que haja um dispositivo
(computador, celular, tablet, entre outros) que possua acesso à internet.

18
O projeto é resultado de um desenvolvimento em parceria com a empresa Altem
Tecnologia LTDA ME, a qual demonstrou interesse no projeto proposto, sugeriu métodos e
tecnologias a serem utilizadas e disponibilizou todo o material de hardware utilizado no
mesmo.
1.3 OBJETIVOS
1.3.1 Objetivo Geral
O objetivo geral deste trabalho é o desenvolvimento de um sistema computacional web
para o monitoramento do gás amônia em aviários, utilizando uma aplicação que envolve
hardware e software.
1.3.2 Objetivos Específicos
 Realizar a aquisição do sinal emitido pelo sensor TGS 2444;
 Realizar o processamento deste sinal, convertendo-o em dados reais de NH³;
 Realizar a comunicação entre o Módulo Slave (Dispositivo de aquisição e
processamento dos dados), Módulo Master (GSM) e Servidor;
 Empregar técnicas/métodos de segurança e consistência dos dados;
 Concluir o desenvolvimento do banco de dados;
 Concluir o desenvolvimento dos firmwares em linguagem C;
 Concluir o desenvolvimento do software web em linguagem Java;
 Realizar testes de integração software e hardware;
 Aplicar testes de uso do sistema.
1.4 HIPÓTESE
A concentração do gás amônia em aviários é relevante, e deve ser monitorada. Com o
sistema computacional proposto atuando diretamente sobre o sistema de manejo de frangos de
corte, será possível a realização de dados estatísticos sobre a concentração do gás amônia em
aviários em tempo real, informação significativa ao processo de produção de frangos de corte,
sendo que a qualidade do ar é de grande importância para um bom desenvolvimento das aves.

19
1.5 CRONOGRAMA
2013 2014
ATIVIDADES/MÊS 7 8 9 10 11 2 3 4 5 6 7 8 9 10 11
Pesquisa Bibliográfica. X X X X X X X X X X X X X X X
Definição do Tema. X
Definição de Objetivos. X
Definição de Metodologia. X
Fundamentação Teórica. X X X X X X X X X X X
Desenvolvimento do relatório
de TCC I.
X X X
Entrega do relatório de TCC I. X
Estudo do Sensor Fígaro TGS
2444.
X
Estudo do Microcontrolador
ARM NXP LPC 17xx e
Driver RS-485.
X X X
Desenvolvimento do Banco
de Dados.
X X
Desenvolvimento dos
firmwares, bem como
comunicação entre sensor,
módulo Dispositivo, módulo
GSM e Banco de Dados.
X X X X X X
Desenvolvimento da Análise
de Requisitos.
X X X X X
Desenvolvimento do layout,
persistência e funcionalidades
do software Web.
X X X
de TCC II.
X X X
Entrega do relatório de TCC
II.
X
Protótipo do hardware. X X
Versão do software Web X X
Testes de hardware e
software em laboratório.
X X X
Testes de hardware e
software em campo.
X X X
de TCC III.
X X X
Entrega do relatório de TCC
III.
X

20
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo será apresentado o estudo das partes do projeto. Primeiramente uma
abordagem do tema com caracterização do setor avícola, aviários e gás amônia na produção
de frangos de corte. Em seguida será compreendido o estudo de técnicas e tecnologias a serem
utilizadas para solucionar a problematização.
2.1 CARACTERIZAÇÃO DO SETOR AVÍCOLA NO BRASIL
Durante toda sua história, no Brasil sempre existiu uma avicultura tradicional e
familiar, conhecida popularmente como produção de frango "caipira". Em geral, as
propriedades produziam carne e ovos para consumo próprio, comercializando os excedentes
quando possível. (LANA, 2000).
Segundo o mesmo autor, as primeiras tentativas visando melhorar tecnologicamente a
atividade no país, sugiram no início do século XX, em São Paulo, Rio de Janeiro e Minas
Gerais. O desenvolvimento da avicultura aperfeiçoando as raças parar criar linhagens de
penas bonitas destinadas aos concursos promovidos em todo o país teve a iniciativa de
profissionais liberais. Estes avicultores tentavam acompanhar as inovações introduzidas,
sobretudo nos Estados Unidos e na Inglaterra.
Em São Paulo a atividade avícola era desenvolvida de forma independente, na qual os
granjeiros adquiriam os insumos no mercado, engordavam as aves e vendiam-nas para um
frigorífico abatê-las. Somente a partir da década de 60 é que a integração, um modelo
largamente utilizado em todo o país, surgiu em Santa Catarina. (CENTRAL DE
INTELIGÊNCIA DE AVES E SUÍNOS, 2010).
A atividade de produção de carne de frango foi se consolidando. Impulsionadas pela
oferta de créditos para investimentos de longo prazo associado, inicialmente, à utilização de
tecnologias importadas, no que se refere à genética, ambiente e nutrição, técnicas de abate e
processamento, empresas que já tinham negócios em outras áreas do agronegócio apostaram
também na comercialização de carnes de frango.
De acordo com a Central de Inteligência de Aves e Suínos (2010), o setor avícola
brasileiro, a partir dos anos 80, regressou por conta da diminuição das vendas para outros
países causadas pelos subsídios das exportações nos Estados Unidos da América e na União
Europeia. Nesta década, principalmente na primeira metade da década de 1980, a recessão

21
econômica ocorrida no Brasil também afetou o desempenho do mercado interno, uma vez que
o consumo permaneceu estagnado.
A partir de meados dos anos 80 a produção avícola voltou a crescer novamente.
Mudanças no estilo de vida da sociedade fizeram com que a indústria se adaptasse às novas
necessidades e preferências dos consumidores em termos de preços e qualidade.
Deste modo, novos mercados foram conquistados com a colocação de produtos mais
elaborados. Daí pra diante a atividade de avicultura de corte se consolidou.
2.2 AVIÁRIOS
O aviário é uma construção simples e funcional com finalidade de alojamento das aves
e que propicie conforto e bem-estar. Segundo Zanatta (2007), geralmente, os aviários
apresentam uma grande porta de entrada em uma extremidade e, lateralmente, existe uma
meia parede de tijolos, que é complementada até o teto por um aramado. Esse aramado
possui, na face externa, uma cortina de plástico removível, conforme a necessidade dos
animais por mais ou menos calor. Os equipamentos básicos existentes nos aviários são os
bebedouros e comedouros, ventiladores, nebulizadores, aquecedores e termômetros.
Segundo o mesmo autor, os aviários estão sob a responsabilidade do proprietário,
chamado de integrado, que se responsabiliza, através de contrato firmado com a empresa, a
construir o aviário e fazer a instalação dos equipamentos necessários, quase sempre
financiados. Além disso, o integrado é responsável pela manutenção e conservação dos
galpões, das instalações dos equipamentos, devendo os mesmos estarem adequados às
exigências técnicas. Também precisam custear as despesas com água, luz, gás, com a
maravalha (cama de frango), além das despesas com mão-de-obra, dos encargos
previdenciários e trabalhistas.
Fotografia 1 - Ambiente Interno de um Aviário.
Fonte: CENTRAL DE INTELIGÊNCIA DE AVES E SUÍNOS (2010).

22
A área construída dos aviários depende da quantidade de frangos a ser alojado.
Geralmente, segundo Fernandes (2004), os aviários utilizados pelas agroindústrias são
estruturas retangulares que possuem uma área construída de aproximadamente 1.200 m² a
2.400 m². A concentração considerada como ideal é 14 e 12 aves por m², que são abatidas ao
redor de 36 a 45 dias de idade, com peso aproximado de 2,30 kg.
2.3 GÁS AMÔNIA NA PRODUÇÃO DE FRANGOS DE CORTE
A amônia é um gás incolor, composto químico cuja molécula é constituída por um
átomo de Nitrogênio (N) e três átomos de Hidrogénio (H) de formula molecular NH³. De
acordo com Oliveira (2004), o gás amônia é produzido pela degradação microbiana do ácido
úrico na cama de frango, ou seja, combinação de material com fezes e água (urina do animal).
Sob a ótica de Fernandes e Furlaneto (2004), a umidade da cama é um fator
determinante para o aumento da proliferação microbiana, bem como o da temperatura, o que
envolve potenciais consequências como a fermentação e liberação de gases. O equilíbrio
dinâmico dos micro-organismos depende da intensidade e taxa de eliminação dos mesmos,
determinado pela idade e pela saúde dos animais. Da mesma forma agrega outros fatores
como o tipo de disposição do esterco, a viabilidade e infectividade dos micro-organismos, a
diluição, ventilação e efeito da sedimentação.
No ambiente do aviário quando a concentração de NH³ for superior a 60 ppm
(partícula por milhão), a ave fica predisposta a doenças respiratórias, aumentando os riscos de
infecções secundárias. Se a concentração de NH³ no ambiente atinge 100 ppm, há redução da
taxa de respiração, prejudicando os processos fisiológicos de trocas gasosas. (GONZÁLES &
SALDANHA, 2001 apud OLIVEIRA & MONTEIRO, 2013).
Segundo Wathes et al. (1998) e Reece et al. (1980) apud OLIVEIRA & MONTEIRO,
os limites aceitáveis de concentração de NH³, nos ambientes produtivos de frangos de corte,
devem ser inferior a 25 ppm até a quarta semana de criação, sendo que à partir da quarta
semana não podem exceder 50 ppm, com cama de frango nova. Se a cama for reutilizada, os
valor devem ser inferior a 50 ppm desde o início da criação. Segundo Hernandes et al. (2002),
é necessário controle rigoroso de NH³ no ar dos galpões avícolas, principalmente em
densidades elevadas e no período final de criação.
O emprego de práticas adequadas de manejo dos dejetos avícolas (processamento
visando à redução de sua carga poluente e dos micro-organismos patogênicos) e o
estabelecimento de critérios de utilização eficientes e seguros são essenciais para a

23
manutenção e crescimento da avicultura como atividade econômica. Desse modo, essa
atividade requer o controle eficaz do gás amônia. (ZANATTA, 2007).
2.4 APLICAÇÃO WEB
Aplicação web é o termo utilizado para designar sistemas de computação projetados
para utilização através de um navegador na internet ou em redes privadas. Trata-se de um
conjunto de programas que é executado em um servidor de protocolo HTTP. Pode-se definir
uma aplicação web como uma aplicação de software que utiliza a web, através de um browser
como ambiente de execução. (MORAES, 2008). No desenvolvimento deste projeto é
essencial à apresentação da arquitetura do processamento da informação, dos protocolos,
métodos e ferramentas a serem utilizadas.
2.4.1 Arquitetura Cliente/Servidor
Cliente/Servidor é uma arquitetura de rede onde o processamento da informação é
dividido em módulos ou processos distintos. Um processo é responsável pela manutenção da
informação, os servidores, fornecendo informações e serviços, enquanto que outro é
responsável pela obtenção dos dados, os clientes, requisitando informações e serviços.
(MCKIE, 1997).
Pode-se citar o uso da arquitetura Cliente/Servidor em processos distribuídos onde a
aplicação servidora aguarda por conexões, executa os serviços e então retorna os resultados.
Enquanto a aplicação Cliente é quem estabelece a conexão com o servidor, envia mensagens
para o mesmo e aguarda pelas mensagens de resposta.
Um grande benefício da arquitetura Cliente/Servidor é a diminuição de trafego na
rede, pois como o banco de dados reside no servidor à integridade dos dados é centralizada e
garantida. Logo, a aplicação não precisa se preocupar com isso e sua manutenção se torna
mais simples. (MCKIE, 1997).
Uma característica muito importante na arquitetura Cliente/Servidor que pode ser
observada no esquema 1 é o fato de que as máquinas não necessitam ter a mesma plataforma3
de hardware e software, mas simplesmente devem utilizar o mesmo tipo de protocolo de
comunicação.
3
É o padrão de um processo operacional ou de um computador. É uma expressão utilizada para denominar a
tecnologia empregada em determinada infraestrutura (O AUTOR).

24
Esquema 1 – Modelo Cliente / Servidor.
Fonte: PROJECTS WIKI (2011).
2.4.2 Protocolos TCP/IP e HTTP
O protocolo HTTP (Hypertext Transfer Protocol) é o protocolo da camada de
aplicação modelo OSI (Open Systems Interconnection Model), camada do TCP/IP, usado no
World Wide Web para a distribuição e recuperação de informação. Ele permite que clientes e
servidores interajam e troquem informações de maneira uniforme e confiável.
Para identificar dados na internet, o HTTP utiliza os URI’s (Uniform Resource
Identifiers), e os URI’s que especificam localizações de documentos são chamados URL’s
(Uniform Resource Locator). Os URL’s comuns referem-se a arquivos, diretórios ou objetos
que executam tarefas complexas, como pesquisas em banco de dados e na internet. Se você
conhece o URL de um recurso ou arquivo disponível em qualquer lugar na web, pode acessá-
lo por meio do HTTP. (DEITEL P. J., DEITEL H. M., 2008, p. 434).
Os clientes de uma conexão HTTP são os browsers. Os servidores de uma conexão
HTTP são os servidores web.
O protocolo4
TCP/IP (Transmission Control Protocol/Internet Protocol) é um
conjunto de protocolos que permite que dois ou mais dispositivos se comuniquem. O TCP/IP
define uma série de parâmetros necessários para estabelecimento e controle de conexões entre
dois pontos da grande rede. Cada equipamento em uma rede possui um endereço IP que o
identifica nessa rede. Toda a transmissão de pacotes nessa rede leva em consideração esse
endereço. O protocolo TCP garante que essa transmissão seja feita de forma confiável,
fazendo checksums5
e sequências para os dados transmitidos, para verificar se não há erros,
como perda de dados ou desordenação dos pacotes, e reenviar os dados quando necessário.
4
Convenção que controla e possibilita uma conexão, comunicação, transferência de dados entre dois sistemas
computacionais (O AUTOR).
5
Código usado para verificar a integridade de dados transmitidos através de um canal com ruídos ou
armazenados em algum meio por algum tempo (MCKIE, 2013).

25
Quadro 1 – Arquitetura do Protocolo TCP / IP.
Fonte: TORRES, Gabriel (2007).
2.4.3 Servidor Web Apache Tomcat
O servidor Web é o programa responsável pela publicação de documentos, imagens ou
qualquer outro objeto que venha a ser acessado por um cliente através de um navegador. Ele
pode ser acessado apenas em uma rede interna (intranet) ou também em uma rede externa
(internet), isso depende da configuração que pode ser levada em conta da necessidade de
publicação.
O servidor HTTP da Apache mantido pela Apache Software Foundation, utilizado no
desenvolvimento do Sistema, é atualmente o servidor Web mais popular devido a sua
estabilidade, eficiência, portabilidade, segurança e tamanho modesto. Foi criado em 1995 por
Rob McCool, então funcionário do NCSA (National Center for Supercomputing
Applications).
Em sintonia com o assunto, Balieiro (2008) afirma que o servidor é compatível com o
protocolo HTTP versão 1.1. É disponibilizado em versões para os sistemas Windows, Novell
Netware, OS/2, e sistemas no padrão POSIX (Unix, Linux, FreeBSD, etc.). Suas
funcionalidades são mantidas através de uma estrutura de módulos, o que proporciona ao
usuário escrever seus próprios módulos utilizando a API do software.
Segundo pesquisa realizada pela NETCRAFT (2013), o servidor web mais utilizado no
Mundo é o Apache com 46,86% de reconhecimento e utilização, ganhando de outras
empresas como Microsoft, Sun, Nginx, Google, NCSA, entre outras. O Apache vem se
destacando por ser robusto, configurável, de alta performance, de fácil instalação e seu
código-fonte ser distribuído gratuitamente pela equipe de desenvolvedores do Apache
Software Foundation.

26
2.4.4 Java Persistence API e Framework Hibernate
JPA (Java Persistence API) definida na JSR-220 (Enterprise JavaBeans – Version
3.0) é uma API padrão da linguagem Java utilizada na camada de persistência que padroniza
o mapeamento objeto relacional. JPA trata de entidades, mapeamentos, interface para
gerenciar a persistência e linguagem de consulta. Define caminhos para mapear classes Java
POJO (Plain Old Java Object) para a Base de Dados. POJO’s são nomeadas de Beans de
Entidade (Uma classe Java utilizando Java Persistence Metadata). (CORDEIRO, 2011).
O pacote javax.persistence contem as classes e interfaces da JPA, assim pode-se
fazer o mapeamento utilizando anotações para cada uma das entidades criadas. É necessário
rotular com @Entity para reconhecer uma classe Java comum, a tabela é representada pela
anotação @Table. As anotações em Java são tipos especiais definidos para simplificar a
anotação dos elementos da classe. Esses recursos fazem com que o desenvolvedor obtenha
maior produtividade, pois quando houver mudanças será necessário realizar mínimas
modificações no ORM. (CORDEIRO, 2011).
O Hibernate, segundo Cordeiro (2011), é um framework de persistência para
aplicações Java de código aberto distribuído com a licença Lesser GNU Public License
(LGPL), ele que implementa a JPA. Sua principal função é reduzir a complexidade nos
programas Java, baseado no modelo orientado a objeto, que trabalhem com banco de dados
relacionais. Permite facilidade para o mapeamento dos atributos com o uso de XML ou
anotações nas classes. Com o HQL (Hibernate Query Language) faz a recuperação das
consultas por meio de uma camada de cache eficiente.
2.4.5 Framework Java Server Faces e Primefaces
JSF (Java Server Faces) é uma tecnologia que nos permite criar aplicações Java para
Web utilizando componentes visuais pré-prontos, de forma que o desenvolvedor não se
preocupe com Javascript e HTML. Basta adicionarmos os componentes, como calendários,
tabelas e formulários, e eles serão renderizados e exibidos em formato HTML. O estado dos
componentes é sempre guardado automaticamente, criando a característica 6
Stateful. Isso nos
permite, por exemplo, criar formulários de várias páginas e navegar nos vários passos dele
com o estado das telas sendo mantidos. (CAELUM, 2006).
6
Guarda o estado de cada objeto. Solicitações subsequentes para os serviços stateful dependem do resultado de
pedidos anteriores. (O AUTOR).

27
Além disso, a arquitetura do JSF promove a separação entre as camadas de
apresentação e de aplicação. Pensando no modelo MVC (Model View Controller), seguido no
projeto, o JSF possui as camadas de visualização, controle e o conjunto de classes de modelo
separadas. O JSF ainda tem a vantagem de ser uma especificação do Java EE7
, isto é, todo
servidor de aplicações Java tem que vir com uma implementação dela e há diversas outras
disponíveis. As implementações mais famosas do JSF são a Oracle Mojarra e a MyFaces
da Apache Software Foundation. (CAELUM, 2006)
Não há componentes sofisticados dentro dessas especificações citadas anteriormente, e
para atender a demanda do desenvolvedor, existem várias extensões do JSF que seguem o
mesmo modelo e ciclo das especificações. Um exemplo é o Primefaces que define
componentes JSF bem além das especificações. Para definição da interface do projeto de TCC
usa-se a combinação do Mojarra com o Primefaces. (CAELUM, 2006).
2.4.6 Padrão Modelo MVC
O MVC é um padrão de arquitetura que determina que um sistema seja separado em
três camadas, chamadas de Model, View e Controller, mas o principal objetivo do MVC não é
definir como separar em camadas, mas sim definir como as camadas devem interagir. Em
outras palavras, a separação de responsabilidades é um conceito benéfico na implementação
do MVC. (LUCKOW e MELO, 2010).
Esse modelo prega que as três camadas citadas acima não podem conhecer uma a
outra. A camada Model representa a camada de acesso aos dados e regras de negócio. A
camada View representa tudo o que compõe a interface do sistema. E a camada Controller é a
responsável por conectar View e Model, é ela quem busca as informações da Model para
conectar na View e vice-versa. O diagrama 1 ilustra o padrão modelo MVC.
Diagrama 1 - Padrão modelo MVC.
Fonte: NetBeans E-Commerce Tutorial (2013).
7
Consiste de uma série de especificações bem detalhadas, dando uma receita de como deve ser implementado
um software que faz cada um desses serviços de infraestrutura (O AUTOR).

28
O MVC é oficialmente um padrão de projeto. Como motivação para a arquitetura do
projeto Web do TCC, segue-se os princípios do MVC com as classes DAO (Data Access
Object) e classes Entidades8
representando a camada Model, as classes Managed Bean9
representando a camada Controller e as páginas web, arquivos no formato XHTML,
representando a camada View.
2.4.7 Linguagem de marcação HTML e o arquivo XHTML
HTML (Hypertext Markup Language) é uma linguagem de marcação voltada para
estruturação e apresentação visual de documentos em um navegador. Ela foi criada por Tim
Berners Lee, o idealizador do WWW (World Wide Web), e é derivada da linguagem pioneira
de marcação SGML (Standard Generalized Markup Language).
Um documento estruturado é composto por conteúdo, o que compreende textos e
figuras, bem como a informação sobre o papel deste conteúdo no documento, ou seja, como
ele está organizado. Um artigo técnico é usualmente composto por um "título", "autores",
"resumo", diversas "seções" e uma "bibliografia", nesta ordem. Cada um dos componentes
(ou "elementos") indicados entre aspas no exemplo citado acima, representa uma parte
estrutural do documento. (GUIMARRÃES, 2005).
Um arquivo XHTML é um arquivo HTML, que pode ser lido por qualquer browser.
Não se fala de um novo HTML. Pelo contrário, o XHTML foi feito para funcionar mesmo em
navegadores antigos. Mas, ao mesmo tempo, um arquivo XHTML é também um arquivo
XML válido, que pode ser lido por qualquer interpretador de XML. Para que o arquivo possa
ser lido por máquinas além de humanos é muito importante escrever um XHTML válido, com
isso fazemos com que as informações da aplicação web fiquem mais acessíveis para as
buscas, contribuindo para o projeto e principalmente melhorando as visitas e acesso ao site.
2.4.8 Banco de Dados MySQL
Um banco de dados é uma coleção organizada de dados. Existem muitas estratégias
diferentes para organizar dados a fim de facilitar o acesso e a manipulação, e um SGBD
8
Classes que definem os objetos JPA com seus atributos, onde seus relacionamentos serão implementados nas
classes DAO (O AUTOR).
9
Responsável por intermediar a comunicação entre as páginas web, em View, e o acesso aos dados, em Model (O
AUTOR).

29
(Sistema de Gerenciamento de Banco de Dados) oferece mecanismos para armazená-los,
organizá-los, recuperá-los e modifica-los.
Em sintonia com o assunto, Rezende (2006) esclarece em seu estudo os objetivos de
um sistema de banco de dados. Tais objetivos compreendem isolar o usuário dos detalhes
internos do banco de dados (promover a abstração de dados), bem como impelir a
independência dos dados em relação às aplicações, ou seja, tornar independente da aplicação,
a estratégia de acesso e a forma de armazenamento.
Hoje em dia, os sistemas de banco de dados mais populares são os relacionais,
representação lógica dos dados que permite que eles sejam acessados sem considerar sua
estrutura física, armazenando-os em tabelas que são compostas por linhas, e estas compostas
por colunas nas quais são armazenados valores.
O MySQL foi desenvolvido pela TCX em 1996. Atualmente a MySQL AB desenvolve
o programa. MySQL AB é a companhia dos fundadores e principais desenvolvedores do
MySQL. Eles criaram-no porque precisavam de um banco de dados relacional que pudesse
tratar grandes quantidades de dados em máquinas de custo relativamente barato. É um dos
bancos de dados relacionais mais rápidos do mercado, apresenta quase todas as
funcionalidades dos grandes bancos de dados. MySQL é uma linguagem simples, em que você
facilmente pode gravar, alterar e recuperar informações num web site com segurança e
rapidez. O MySQL é executado, principalmente, em sistemas que participam da filosofia
UNIX, embora outros sistemas operacionais também fornecem suporte, como Windows, por
exemplo. (DE ALMEIDA, 2012).
Ainda segundo o mesmo autor, para poder utilizar o MySQL sob a licença GPL e não
precisar pagar, o produto desenvolvido precisa ser GPL também, senão, orientamos a compra
da licença comercial, com baixo custo, sendo comercializada por servidor, sem limites de
usuários e processadores e ainda com garantia perpétua de atualização de versão para o resto
da vida.
Dentre as características que mais se destacam no MySQL é a de que ele é multi-
plataforma, suporta até 16 índices por tabela, banco de dados de código aberto e gratuito,
suporte a API’s das linguagens PHP, C++, Java, etc.
2.5 ENGENHARIA DE SOFTWARE
O processo unificado de desenvolvimento de software é o conjunto de atividades neces
sárias para transformar os requisitos do usuário de um sistema de software. O UP (Processo

30
Unificado) de desenvolvimento de sistemas combina os ciclos iterativo e incremental para a
construção de softwares.
Segundo Leite e Girardi (2009), um processo de desenvolvimento de software é um
modelo que especifica o ciclo de vida do software, descrevendo as fases pelas quais transita o
produto de software ao longo de sua concepção e desenvolvimento e a metodologia que
estabelece as técnicas a serem aplicadas em cada uma das fases de acordo a um determinado
paradigma de desenvolvimento.
Esta etapa do projeto é de extrema importância, pois este trabalho trata do
desenvolvimento de um software web e softwares embarcados. Para Balieiro (2008, p. 15) o
trabalho de Engenharia de Software consiste na utilização sistemática, disciplinada e
quantificada de um conjunto de técnicas para o desenvolvimento, operação e manutenção de
um sistema.
2.5.1 Levantamento de Requisitos
Umas das partes mais essenciais importantes de um projeto qualquer, software ou
hardware, é o levantamento de requisitos, onde deve-se utilizar-se várias metodologias e
procedimentos adequados para cada situação capazes de ilustrar/descrever o que os usuários e
os clientes realmente querem. (Pfleeger, 2004).
Requisito é uma condição ou funcionalidade que deve ser atingida ou influenciada por
um componente de sistema para satisfazer um documento formal definido. Basicamente,
pode-se definir requisito como sendo uma condição ou funcionalidade necessária a um
usuário para resolver um problema.
A análise de requisitos é uma tarefa da engenharia de software que efetua a ligação
entre a alocação de software em nível de sistema e o projeto de software. A análise de
requisitos possibilita a especificação da função do software e de seu desempenho. Com a
Análise de Requisitos é possível que o responsável pela elaboração do projeto aprimore a
alocação de software e construa modelos de processos de dados que serão tratados pelo
software. (PRESSMAN, 1995).
2.5.2 UML
A UML (Uniﬁed Modeling Language) é utilizada para a realização da modelagem, que
compreende a especificação, documentação, visualização e desenvolvimento, de sistemas
computacionais orientados a objetos.

31
O objetivo da UML é ajudar a definir características do software, tais como seus
requisitos, seu comportamento, sua estrutura lógica, a dinâmica de seus processos e suas
necessidades físicas em relação ao equipamento sobre o qual o sistema deverá ser implantado.
Todas estas características são definidas por meio da UML antes do software começar a ser
realmente desenvolvido. (GUEDES, 2004).
No item 4.1, Documento de Especificação de Requisitos da Aplicação Web de
Monitoramento é que a UML é representada. Visando a diminuição da possibilidade de
ocorrência de erros futuros, a UML é composta por diferentes tipos de diagramas, cada um
representando o sistema sob uma determinada ótica.
2.5.3 SysML
A SysML (Systems Modeling Language) é uma linguagem gráfica para modelagem
visual que suporta a especificação, análise, design, verificação e validação de uma ampla
gama de sistemas complexos como hardware, software, informação, processos, pessoas e
infra estrutura. (OMG, 2012).
Ainda segundo a OMG (2012), os requisitos da SysML foram originalmente
especificados em 2003, porém somente em 2007 é que a primeira versão formal da
especificação foi liberada. A versão atual da especificação é a 1.3, que foi liberada em junho
de 2012. A SysML define diagramas que não estão incluídos na UML. Um destes diagramas é
o diagrama de contexto.
A SysML juntamente com o BPMN apresentado no tópico seguinte, é representada no
item 4.2, definido como Desenvolvimento de Hardware e Interfaceamento.
2.5.4 BPMN
O BPMN (Business Process Modeling Notation) é uma notação gráfica que tem por
objetivo prover instrumentos para mapear, de uma maneira padrão, todos os processos de
negócio da organização. Esta notação surgiu através do projeto chamado BPMI, que hoje é
mantida pelo OMG, uma organização internacional que mantém publicamente e apoiando o
desenvolvimento de diversos padrões. O diagrama BPMN pode servir como um novo contrato
entre as áreas técnicas e os usuários, ajudando a diminuir a distância entre o mapeamento de
processos da organização e a implementação técnica destes processos. (OMG, 2013).
A OMG (2013) ainda define que o objetivo da BPMN é ser um padrão de comunicação
entre todos os envolvidos com o processo de negócios.

32
 Padronização da modelagem de processos de negócio;
 Ampliação dos recursos de modelagem;
 Mapeamento formal entre a modelagem em alto nível e as linguagens de
execução.
Ela emprega apenas um modelo Diagrama de Processo de Negócio ou BPD (Business
Process Diagram). É utilizada nos sistema Business Process Management System (BPMS): é
um sistema que automatiza a gestão por processos (execução, controle e monitoração). É uma
poderosa ferramenta de gestão, para garantir que os processos estão sendo efetivamente
executados como modelados, contribuindo para os objetivos da organização. (OMG, 2013).
2.6 MÓDULOS DE HARDWARE E INTERFACEAMENTO
Em Engenharia de Computação, uma interface é o ponto de interação com o software,
hardware ou periféricos10
dispositivos. Algumas interfaces podem enviar e receber dados,
enquanto outras podem ou só enviar ou só receber dados. Um equipamento eletrônico de
processamento de dados é capaz de sistematicamente coletar, manipular e fornecer os
resultados da manipulação de informações para um ou mais objetivos. A programação para a
interface reduz a dependência em detalhes de execução e torna o código mais reutilizável. Dá
ao desenvolvedor a capacidade de alterar posteriormente o comportamento do sistema,
simplesmente trocando o objeto utilizado com outra execução da mesma interface.
2.6.1 Aquisição de Sinais
Pode-se definir aquisição de sinais como processo pelo qual um fenômeno físico real é
transformado em um sinal elétrico proporcional e convertido em um formato digital para
posterior visualização, armazenamento, processamento e análise. As quantidades físicas de
interesse podem ser várias, como por exemplo, luz, temperatura, força, pressão e, como no
caso do projeto, gás. (BAPTISTA, 2005).
Todas essas grandezas possuem energia. Deste modo, torna-se necessário para sua
medição a utilização de dispositivos capazes de receber esta energia, relativa a uma
determinada quantidade física da grandeza desejada, e converte-la numa forma de energia
manipulável pelos circuitos elétricos. Estes dispositivos são os sensores. Os sensores recebem
10
Aparelhos ou placas que enviam ou recebem informações do computador (O AUTOR).

33
as quantidades físicas de grandezas analógicas e convertem-nas em quantidades elétricas, tais
como tensão, corrente ou impedância. (BAPTISTA, 2005).
Para a recepção do sinal emitido pelos sensores ocorrer perfeitamente, deve existir um
circuito de condicionamento de sinal, que é responsável por adequar os níveis de
tensão/corrente para serem lidos pelo conversor analógico/digital do microcontrolador, como
apresentado mais adiante na sessão Desenvolvimento, tópico 4.2.1, esquema 4.
2.6.2 Sensores
Sensor é um termo empregado para designar dispositivos sensíveis a alguma forma de
energia do ambiente que pode ser luminosa, térmica, cinética, relacionando informações sobre
uma grandeza física que precisa ser mensurada (medida), como temperatura, pressão,
velocidade, corrente, aceleração, posição, etc. (WENDLING, 2010).
A instrumentação desempenha um papel vital no nosso mundo tecnológico atual. A
tecnologia de sensores diz respeito a duas atividades, medição e processamento de
informação. Para determinar as condições de um dado sistema é necessário obter valores das
variáveis físicas do ambiente a ser monitorado, e este é o trabalho dos sensores. Sensores
servem para informar um circuito eletrônico a respeito de um evento que ocorra
externamente, sobre o qual ele deve atuar. Estes dispositivos fazem aquisição de dados
analógicos e digitais interpretando-os e tendo como saída um valor correspondente analógico
ou digital ao obtido.
Os sensores podem fornecer diretamente ou indiretamente um sinal que indica esta
grandeza. Quando operam diretamente, convertendo uma forma de energia em outra, são
chamados transdutores. Os de operação indireta alteram suas propriedades, como resistência,
capacitância ou indutância, sob a ação de uma grandeza, de uma forma proporcional.
Para a utilização do sensor, realizou-se uma pesquisa, junto à empresa Altem
Tecnologia, referente aos possíveis sensores disponíveis no mercado, que são eficazes na
medição da concentração do gás amônia, para se utilizar no projeto. São poucas as opções de
sensores. Foram encontrados sensores da empresa fabricante Hanwei (chinesa) e Fígaro
(japonesa), e chegou-se a conclusão de que o sensor mais adequado para se utilizar no projeto
é o TGS 2444 da Figaro, por motivos descritos no item 2.6.2.1 a seguir. Ele opera
indiretamente, sendo alterada sua resistência de medição sob a ação do NH³ no ambiente. Este
sinal do sensor é usado para efetuar a medição no sistema de monitoramento da concentração
de NH³ em aviários.

34
2.6.2.1 Sensor de Gás Amônia Fígaro TGS 2444
O sensor TGS 2444 exibe boa seletividade à amônia, sendo considerado ideal para
aplicações com o objetivo de detecção de vazamentos de NH³ em sistemas de refrigeração,
como frigoríficos, e detecção do mesmo no campo agrícola, como em aviários. Opera
indiretamente, sendo alterada sua resistência (impedância) de medição sob a ação de NH³ no
ambiente. Este sinal do sensor é usado para efetuar a medição no sistema de monitoramento
da concentração de NH³ em aviários. A fotografia 2 ilustra o sensor.
Fotografia 2 - Sensor de gás amônia TGS 2444.
Fonte: Figaro Engineering Inc., 2010.
Para compreender o funcionamento do sensor, deve-se primeiro compreender a sua
estrutura. O sensor utiliza de uma estrutura multicamadas, ou seja, possuí uma camada de
aquecimento e outra de medição/leitura. Em cada camada contem um par de eletrodos de ouro
(Au). Para isolamento térmico é impresso uma camada de vidro entre o óxido de rutênio
(RuO2) e um substrato de alumina, e o par de eletrodos é formado por um isolante térmico.
(Figaro Engineering Inc., 2010).
Na presença de NH³, a condutividade do sensor aumenta em função da concentração
do gás no ar, e para que o sinal de saída seja correspondente à concentração do gás, o sensor
deve operar recebendo dois ciclos de tensão de 250 milissegundos em suas duas camadas.
Segundo dados disponibilizados pelo fabricante, cada ciclo de tensão para a camada de
medição do sensor consiste em 0 V aplicado para 2 milissegundos, seguido de 5 V aplicado
para 5 milissegundos e 0 V para 243 milissegundos. E para cada ciclo de tensão aplicado na
camada de aquecimento aplica-se 4.8 V para os primeiros 14 milissegundos seguido de 0 V
para os 236 milissegundos restantes. Para alcançar características ótimas de sensoriamento, a
propriedade do sensor (resistência) deve ser lida após o ponto médio do pulso de 5
milissegundos do ciclo de tensão aplicado na camada de medição do sensor, como ilustra a
quadro 2. (Figaro Engineering Inc., 2010).

35
Quadro 2 - Diagrama do Ciclo de Funcionamento do Sensor.
Fonte: Figaro Engineering Inc., 2010.
2.6.3 Comunicação Serial
Segundo Buchmann (2013), a comunicação entre dois dispositivos eletrônicos digitais
pode ser feita de forma serial ou paralela. Para uniformizar estas conexões, são criados
padrões a serem seguidos pela indústria. Responsável pelo desenvolvimento e criação dos
principais padrões de comunicação serial, a EIA (Electronic Industries Alliance) desenvolveu
os três grandes protocolos de comunicação serial: RS-232, RS-422 e RS-485, este último
padrão citado está contido neste trabalho. O prefixo RS vem de Recommended Standard.
A comunicação serial define-se em dois modos de transmissão. O primeiro modelo, o
Single-Ended é caracterizado pela comunicação de uma ponta a outra, ou seja, em uma rede
com um mestre e n escravos. Deve sair do dispositivo mestre um cabo para cada escravo.
Outro detalhe do modo Single-Ended, é que os dados são representados em níveis de tensão
em relação ao terra comum. Esse sistema torna a rede serial lenta, aproximadamente 20
Kbits/s (kilobits por segundo) de transmissão e a curtas distâncias de aproximadamente 15
metros sem repetidores. O modo Single-Ended é encontrado nos padrões RS-232C e RS-423
(ARC, 2000).
O Segundo modelo, o Differential Data Transmission, oferece uma alta taxa de
transmissão, aproximadamente 100 Kbits/s e longas distâncias, chegando até 1200 metros.
Usa-se uma linha diferenciada, o que implica que o dado é representado pela corrente e não
pela tensão como no modelo Single-Ended. O Differential possibilita, pela sua estrutura, uma
conexão multi-ponto, onde pode-se ter uma conexão de um mestre e vários escravos
compartilhando mesmo meio. Essas implementações podem ser encontradas nos padrões RS-
422 e RS-485. (ARC, 2000).
2.6.3.1 Padrão Serial RS-485
O padrão RS-485 é capaz de prover uma forma bastante robusta de comunicação
multiponto, com até 32 terminais remotos de comunicação, bastante comum na indústria, em

36
controle de sistemas, com taxas que podem chegar a 10 Mbps, e até 1200 metros, utilizando-
se de um meio de comunicação diferencial denominado par trançado, ou seja, os circuitos
transmissores e receptores adotados nesta interface utilizam como informação a diferença
entre os níveis de tensão em cada condutor do par trançado. (CUNHA J. M., 2000).
Vantagens do padrão RS-485:
 Redes locais baratas quando comparadas a outras como: FieldBus, Ethernet,
entre outros;
 Flexibilidade de configuração;
 O usuário define, projeta e testa seu próprio protocolo de comunicação ou pode
usar protocolos abertos, bem definidos e testados;
 Migração de um padrão para outro sem perder suas características de pulso;
 Opera corretamente na presença de tensões diferenciais no GND;
 Suporta situações de contenções de drivers;
 Possui comunicação confiável em ambientes eletricamente ruidosos.
Ainda segundo Cunha (2000), quando se deseja realizar a conexão entre dispositivos, é
comum utilizar a classificação DCE (Data-communication equipment) / DTE (Data-terminal
equipment), o primeiro responsável pela comunicação e tratamento dos dados, definido no
trabalho como sendo o Módulo Master (GSM) e o segundo responsável pela geração e
recebimento dos dados, o Módulo Slave (Dispositivo). Assim um Módulo GSM pode se
comunicar com vários dispositivos ao mesmo tempo no barramento (até 32 dispositivos).
2.6.3.1.1 Protocolo de Comunicação
Protocolo é um conjunto de regras e convenções para conversação que definem a
comunicação entre dois equipamentos, sejam eles computadores ou máquinas. Nos protocolos
são definidas as sintaxes, como os equipamentos irão ordenar os dados de forma que fiquem
entendidos por ambos os lados que fazem parte da comunicação. (TANENBAUM, 2004).
Nesse trabalho, o protocolo de comunicação utilizado pelo autor é embasado no
Modbus. Este protocolo define uma estrutura de mensagem que os controladores (Módulo
Master e Módulo Slave) reconhecerão, independente do tipo de rede acima deles. Deve-se
ressaltar que existem várias implementações deste protocolo, e no trabalho tem-se como
padrão o formato simples de mensagens que o Modbus utiliza.
A rede segue o modelo mestre-escravo multiponto, onde o mestre pergunta e o escravo
responde através de um formato de mensagem padrão como ilustra o quadro 3.

37
Quadro 3 - Protocolo de Comunicação Padrão RS-485.
Fonte: o autor.
Um mestre dirige-se ao seu escravo colocando seu número (ID) no campo de endereço
e vice-versa. O escravo verifica o campo comando para saber qual ação tomar e assim que
executou retorna neste campo o mesmo valor. Para o cálculo e verificação de erro são criadas
funções de CRC (Cálculo de Redundância Cíclica) iguais no mestre e no escravo. Então, para
comunicar um mestre e escravo primeiramente o mestre gera o CRC envia os dados. O
escravo verifica o CRC e então realiza as ações solicitadas pelo mestre e responde-o, e vice-
versa. Se o código de CRC for igual tanto no Master como no Slave a mensagem foi enviada
e recebida com sucesso, somente assim um dispositivo responde ao outro, assegurando a
integridade dos dados.
Utiliza-se o modo de transmissão RTU (Remote Terminal Unit), onde cada byte
representa dois números, pois representa valores dento do padrão BCD Packet. O primeiro
número é representado pelos quatro bits mais significativos e segundo pelos quatro bits menos
significativos. Resumindo, tem-se os números 1 e 9 representados por 00011001 que é o
hexadecimal 19. A vantagem principal desse modo, é que sua maior densidade de caracteres,
permite um melhor processamento dos dados que em uma mesma taxa de transmissão.
(CUNHA J. M., 2000).
2.6.4 Tecnologias de Comunicação Sem Fio
Tecnologias sem fio estão se tornando cada vez mais populares. Com diferentes
propósitos, vantagens e desvantagens dominam a área de comunicação seja para serviços de
dados ou voz. Com relação à banda11
, à área de cobertura (área onde é possível realizar a
comunicação) e aos custos, às tecnologias atuais disponíveis impõe limites, pois
proporcionam conectividade em ambientes específicos. O resultado disto é que, embora vários
sistemas possam ser utilizados de forma complementar, os usuários estão limitados à
tecnologia sem fio utilizada.
11
Quantidade em bits/s que a rede suporta (O AUTOR).

38
As tecnologias sem fio classificadas de acordo com sua área e cobertura estão
divididas em dois grupos: as coberturas dentro de ambientes (internas) como Wireless LAN
(WLAN), High Performance Radio Local Área Network (HiperLan) e Digital Enhanced
Cordless Telecommunications (DECT). Wide Área (externas) onde predomina as tecnologias
Global System for Mobile Communications (GSM), Code Division Multiple Access (CDMA)
e o Time Division Multiple Access (TDMA). (TATEOKI, 2007).
A tecnologia de comunicação sem fio utilizada no projeto é a do sistema GSM, por ser
de área externa se tornando a única possível para esse tipo de comunicação, onde o
dispositivo deve estar localizado dentro de um aviário e deve realizar o envio das informações
para a Aplicação Web de Monitoramento. Lembrando que onde o dispositivo for instalado, na
localização do aviário, deve haver cobertura GSM, independente da operadora. Porém deve-se
ressaltar que no desenvolvimento deste projeto foi utilizado um chip da operadora CLARO.
2.6.4.1 Sistema GSM – Global System for Mobile
Segundo Tateoki (2007), no ano de 1982 foi realizada a CEPT (Conference of
European Posts and Telegraphs) onde se formou um grupo denominado GSM (Group Special
Mobile), com o objetivo de estudar e desenvolver um sistema móvel baseado nas seguintes
diretrizes básicas:
 Boa qualidade de voz;
 Eficiência espectral;
 Terminais pequenos e baixos custos;
 Suporte para "roaming" internacional;
 Capacidade para suportar "handheld" terminais;
 Suportar uma larga área de novos serviços e utilidades;
 Compatibilidade RDSI – Rede Digital de Serviços Integrados.
Isso devido aos diversos sistemas que foram desenvolvidos anteriormente, com
diferentes formas de envio de dados, protocolos e frequências de comunicação.
Em 1989 a responsabilidade passou para o European Telecomunication Standards
Institute (ETSI) e em 1990 foram publicadas as especificações do GSM. Tal padrão
generalizou-se então pelo resto do mundo. A sigla GSM passou a denominar então Global
System for Mobile Communication e atualmente é considerado um padrão digital de segunda
geração do celular adotado na maior parte do mundo. Desenvolvido inicialmente para a faixa

39
de 900 MHz, o GSM teve posteriormente uma versão adaptada para as faixas de 1800 e 1900
MHz. (TATEOKI, 2007).
2.6.4.2 GPRS – General Packet Radio Service
Segundo Tateoki (2007), em meados dos anos 90 o uso da internet combinado de
outros serviços de dados popularizou-se, as redes GSM acabaram que sendo incapazes de
comportar grandes quantidades de dados em seus diferentes estágios. Assim o ETSI
desenvolveu um novo modo de funcionamento, o GPRS (General Packet Radio Service), que
veio a ser uma especificação do GSM para garantir os serviços futuros.
As redes GPRS foram desenvolvidas para aceitar serviços de dados, pois
diferentemente do GSM, foram criadas com base em transmissão por comutação de pacotes,
que utiliza a fonte de rádio para tráfego em rajadas, sendo mais eficiente, que é uma
característica da maioria dos serviços de dados.
Para que as operadoras possam utilizar seus serviços GSM e os serviços de dados
GPRS a partir de uma única base dinâmica e flexível, os dois sistemas compartilham várias
características entre si, como bandas de frequência, estrutura de frames e técnicas de
modulação. No entanto, a cobrança pelo uso do GPRS é feita por quantidade de dados
transmitidos, enquanto que no GSM é feita por tempo de conexão. (TATEOKI, 2007).
A rede GPRS pode ser considerada como um revestimento à rede GSM, acrescentando
tráfego orientado a pacotes mediante leves modificações da arquitetura. A rede GPRS pode
ser analisada como sendo “GSM + dados”. Sua integração com a rede internet permite o
envio e o recebimento de dados de uma forma bem simples por qualquer aparelho que utiliza
esta tecnologia. (TATEOKI, 2007).
2.6.5 Módulo Slave: Dispositivo
Placas denominadas de Módulos são ambientes de desenvolvimento completo para
microcontroladores12
(uC) de diferentes famílias, PIC, AVR, ARM, entre outros. Composta
por vários componentes, como Flash Serial, EEPROM Serial, conector USB, entre outros.
Ajuda na criação de sistemas com facilidade, pois fornece meios necessários para o
desenvolvimento de projetos para as mais variadas finalidades. Os componentes principais do
12
Computador dentro de um chip, contendo um processador, memória e periféricos de entrada/saída (O
AUTOR).

40
Módulo Slave do projeto são o uC ARM LPC1766, sensor TGS 2444 e driver RS-485
SN65LBC184 da Texas Instruments.
É de extrema importância para o desenvolvimento deste projeto, funciona como o
cérebro do sistema de aquisição de dados. É ele o responsável por realizar a aquisição do
sinal, processar e responder ao pedido do Módulo Master quando ele solicitar concentração de
NH³. Esta plataforma de desenvolvimento é integrada ao produto final realizando a
comunicação com o Módulo Master, pois é nele que está acoplado o módulo GSM/GPRS
SIM900 que é o responsável por enviar as informações ao servidor.
A placa disponibilizada pela empresa Altem Tecnologia contem os componentes
essenciais para o correto funcionamento do sistema de aquisição e processamento do sinal,
como, reguladores de tensão, transistores, e cristal, conexões para o LCD e gravador. Para
atender aos requisitos do projeto, foram adicionados na placa de prototipagem: resistores
(utilizados no circuito de condicionamento do sinal) e o sensor Fígaro TGS 2444. A fotografia
abaixo ilustra a placa denominada de Módulo Slave utilizada no projeto com seus
componentes.
Fotografia 3 - Módulo Slave.
Fonte: o autor.
O LPC 1766 é de ótima velocidade, possui muitos periféricos embarcados, muitos
pinos para comunicação, boa memória e, um dos fatores principais, é o de apesar de
disponibilizar de toda essa tecnologia, ser de um tamanho pequeno, ocupando pouco espaço
em placa pela quantidade de pinos existentes, no caso 100 pinos.
2.6.5.1 Microcontrolador NXP LPC 1766
O LPC1766 é um microcontrolador da família LPC17xx manufaturado pela NXP
Semiconductors N. V., uma antiga divisão da Phillips®. A versão utilizada é da família de

41
núcleo de processador ARM Cortex-M3, RISC (Reduced Instruction Set Computer) de 32-bit
operando em até 100 MHz de clock13
. Como é de arquitetura RISC possui barramentos
distintos para instruções, dados e um barramento especial para periféricos. A CPU (Central
Processing Unity) também possui uma unidade de prefetching14
, onde lê a instrução e
decodifica previamente, para instruções que são utilizadas para fazer desvio especulativo. O
esquema 2 ilustra o diagrama de blocos do microcontrolador LPC1766 e seus periféricos.
Esquema 2 - Esquema de blocos e periféricos LPC 1766.
Fonte: NXP Semiconductors N. V.
13
Em Eletrônica, é um sinal usado para coordenar as ações de um circuito eletrônico. Um sinal de
clock oscila entre os estados alto e baixo (O AUTOR).
14
Pré-carregamento de código de máquina a partir da memória (O AUTOR).

42
Apesar do grande número de periféricos existentes no microcontrolador, neste projeto
utilizou-se de apenas alguns deles, como, pinos de I/O configurados como saída para correta
alimentação do sensor, dois conversores A/D para realizar a leitura das tensões do circuito de
condicionamento de sinal e poder efetuar a leitura do sensor, Whatchdog Timer15
, UART para
realizar comunicação com o módulo GSM e interrupção usando RIT (Repetitive Interrupt
Timer) para contar o ciclo necessário para a lógica de funcionamento do sensor. Para
programação e debugger16
utilizou-se a interface USB do notebook interligada a interface
JTAG do uC, com o kit de desenvolvimento da Keil composto por compilador17
ARM C/C++,
uVision Project Maneger, Editor e Debugger, RTX Operating System e GUI Library
disponível no site da Keil Tools By ARM.
2.6.5.1.1 Circuito ADC - Analog to Digital Converter
Sinais do mundo real como de luz, som, pressão, temperatura são analógicos. Por essa
razão é que estes sinais devem ser convertidos para digital através de um circuito chamado
conversor A/D antes que possam ser manipulados por um equipamento digital. No projeto
isso é feito pegando a informação analógica fornecida pelo sensoriamento, ou circuito de
condicionamento de sinal, e convertendo-a em sinal digital pelo circuito conversor A/D do
próprio microcontrolador.
Abaixo seguem as especificações do circuito conversor A/D do microcontrolador LPC
1766 utilizado no trabalho.
 12 bits de aproximação sucessiva do conversor analógico para digital;
 Multiplexação de entrada entre 8 pinos;
 Modo Power-Down18
;
 Faixa de medição VREFN para VREFP (normalmente 3v para não exceder o
nível de tensão VDDA);
 Taxa de conversão de 12 bits de 200KHZ;
15
Dispositivo temporizador que tem a finalidade de fiscalizar o processamento e quando necessário aplicar
correções e até mesmo um reset no hardware (O AUTOR).
16
Depurador. Permite que se execute o programa linha por linha examinando os valores de variáveis,
comportamento do próprio hardware e de funções (O AUTOR).
17
Programa de computador que a partir do código fonte escrito cria um programa semanticamente equivalente
em linguagem de máquina (O AUTOR).
18
Modo de operação de baixo consumo de energia (O AUTOR).

43
 Estouro no modo de conversão para simples ou múltiplas entradas;
 Conversão opcional em transição no pino de entrada ou sinal Timer Match.
2.6.6 Módulo Master: GSM
Também desenvolvido pela empresa Altem Tecnologia LTDA, a placa definida como
Módulo Master é responsável por enviar requisições ao dispositivo, solicitando os valores de
concentração de NH³ medidos no ambiente e então através do GSM/GPRS SIM900 enviar
informações como número (ID) do dispositivo, data, hora, e concentração de NH³ ao servidor
(software web de monitoramento). É um ambiente de desenvolvimento completo para ser
utilizado em projetos de telemetria. Nele contém um módulo GSM/GPRS SIM900, um driver
SN65LBC184 necessário para realização da comunicação com o Dispositivo, um
microcontrolador ARM NXP LPC 1751, entre outros componentes necessários para seu
funcionamento. A fotografia 4 ilustra a placa denominada de Módulo Master utilizada no
projeto com seus componentes.
Fotografia 4 - Módulo Master Frente / Verso.
Fonte: o autor.
No uC está toda a lógica para o correto funcionamento do processo de telemetria.
Através de configurações e funções definidas o Módulo Master realiza a comunicação com o
SIM900 presente nele mesmo, e com o Módulo Slave via barramento RS-485. A UART 1 é
utilizada para comunicar com o SIM900 e a UART 0 para comunicar com o Módulo Slave via
RS-485. O LPC 1751 é da mesma família do LPC 1766 que está presente do Módulo Slave. A
diferença é que o LPC 1751 possui um menor número de periféricos.

44
2.6.6.1 Módulo GSM/GPRS SIM900
O SIM900 é um módulo GSM/GPRS quadband com pilha TCP/IP fabricado pela
SIMCOM e distribuído no Brasil pela ME Componentes. É do tipo board-to-board (fácil
soldagem e integração, até mesmo para prototipagem) e pode ser usado em aplicações onde a
comunicação sem fio via tecnologia GSM/GPRS se faça necessária, seja, transmissão de voz
ou SMS, consome pouca energia, seu reduzido tamanho o torna ideal para os mais exigentes
requisitos das aplicações industriais, como telemetria ou qualquer outra forma de
comunicação móvel. (SILVA, 2012). A fotografia 5 ilustra o SIM900.
Fotografia 5 - Módulo GSM / GPRS SIM900.
Fonte: Silva, 2012.
O SIM900 possui como principais características:
 Quad-Band 850/ 900/ 1800/ 1900 MHz;
 GPRS multi-slot class 10/8;
 GPRS mobile station class B;
 Compliant to GSM phase 2/2+Class 4 (2 W @850/ 900 MHz);
 Class1 (1 W @ 1800/1900MHz);
 Controle via commandos AT 19resence19 (GSM 07.07 ,07.05 and SIMCOM
enhanced AT Commands);
 Baixo Consumo de Energia: 1.5mA(sleep mode);
 Temperatura de Operação: -40°C to +85 °C;
 Suporta para se ativado via Software.
2.6.6.1.1 Comandos AT
Os serviços executados pelo módulo SIM900 no projeto são dois, envio de SMS e
conexão com a internet para envio dos dados ao servidor. Estes serviços são controlados por
meio de instruções formadas por comandos “AT”.

45
Uma linha de comando “AT” pode conter um ou mais comandos, utilizando
delimitadores para separar cada comando. A linha possuirá o prefixo “AT” e o sufixo, ASCII
de Carriage Return, e o delimitador poderá ser um ponto e virgula ou um espaço, dependendo
da função do modem a se utilizar. O modem emitirá uma mensagem, Result Code, no
momento em que o comando é emitido, avisando assim ao terminal o resultado do comando
requisitado. (SILVA, 2012).
Todo o processo de envio dos comandos “AT” e recebimento do resultado do
comando requisitado é realizado pela lógica implementada no sistema embarcado do Módulo
Master.

46
3 METODOLOGIA
Este capítulo tem por objetivo relacionar os métodos lógicos e científicos bem como
os materiais utilizados para o desenvolvimento e realização deste trabalho.
3.1 CARACTERIZAÇÃO DO TIPO DE PESQUISA
Quanto à abordagem do problema, a pesquisa é classificada como qualitativa. Os
pesquisadores que utilizam os métodos qualitativos buscam explicar o porquê das coisas,
exprimindo o que convém ser feito, mas não quantificam os valores e as trocas simbólicas
nem se submetem à prova de fatos, pois os dados analisados são não métricos (suscitados e de
interação) e se valem de diferentes abordagens. Segundo Deslauriers, na pesquisa qualitativa,
o cientista é ao mesmo tempo o sujeito e o objeto de suas pesquisas. O desenvolvimento da
pesquisa é imprevisível. O conhecimento do pesquisador é parcial e limitado. O objetivo da
amostra é de produzir informações aprofundadas e ilustrativas: seja ela pequena ou grande, o
que importa é que ela seja capaz de produzir novas informações. (DESLAURIERS, 1991, p.
58 apud GERHARDT e SILVEIRA, 2008, p.32).
No ponto de vista do tipo, esta pesquisa está classificada quanto a sua natureza como
aplicada, pois, objetiva gerar conhecimentos para aplicação prática, dirigidos à solução de
problemas específicos. Envolve verdades e interesses locais.
Com relação aos procedimentos técnicos e as fontes de informação, a pesquisa
classifica-se como bibliográfica. A pesquisa bibliográfica é feita a partir do levantamento de
referências teóricas já analisadas, e publicadas por meios escritos e eletrônicos, como livros,
artigos científicos, páginas de web sites. Qualquer trabalho científico inicia-se com uma
pesquisa bibliográfica, que permite ao pesquisador conhecer o que já se estudou sobre o
assunto. Porém existem pesquisas científicas que se baseiam unicamente na pesquisa
bibliográfica, procurando referências teóricas publicadas com o objetivo de recolher
informações ou conhecimentos prévios sobre o problema a respeito do qual se procura a
resposta (FONSECA, 2002, p. 32).
Segundo os objetivos e resultados, a pesquisa é classificada como experimental, pois,
Triviños (1987) afirma que o estudo experimental segue um planejamento rigoroso. As etapas
de pesquisa iniciam pela formulação exata do problema e das hipóteses, que delimitam as
variáveis precisas e controladas que atuam no fenômeno estudado.

47
Quanto a coleta de dados a técnica utilizada é a Documental Direta, pois é feito
pesquisa em campo e em laboratório, sendo que a coleta de dados abordado no tema do
projeto é realizada por meio de sensor e sistemas computacionais.
3.2 MATERIAIS
3.2.1 Software De Modelagem Lógica e Conceitual
 Astah Community: utilizado para o desenvolvimento da Modelagem de
Processos de Negócio da Aplicação Web de Monitoramento;
 Astah SysML: utilizado para o desenvolvimento da Modelagem dos Diagramas
de Contexto e Requisitos (SysML) dos Sistemas Embarcados;
 Bizagi Process Modeler: utilizado para o desenvolvimento da Modelagem de
Processos de Negócio (BPMN) dos Sistemas Embarcados.
 BRModelo: utilizado para o desenvolvimento da Modelagem Conceitual do
Banco de Dados;
 MySQL Workbench 5.2 CE: utilizado para o desenvolvimento da Modelagem
Física e Lógica do Banco de Dados.
3.2.2 Software de Programação
 NetBeans IDE 7.1: utilizado para o desenvolvimento do software web em
linguagem de programação Java, utilizando os frameworks JSF, Hibernate e
Primefaces;
 Keil uVision 4: utilizado para o desenvolvimento dos firmwares (sistemas
embarcados) em linguagem de programação C salvos nos microcontroladores
dos Módulos Master e Slave.
3.2.3 Materiais de Hardware
Foram utilizados no ambiente de desenvolvimento do projeto:
 01 Notebook;
 01 Placa de prototipação denominada Módulo Slave (Dispositivo)
desenvolvida pela empresa Altem Tecnologia Ltda, contendo 01
microcontrolador ARM NXP LPC 1766, 01 sensor Fígaro TGS 2444, 01 driver

48
RS-485 modelo SN65LBC184 da Texas Instruments, resistores, capacitores,
transistores, reguladores de tensão, entre outros;
 01 Placa denominada Módulo Master (GSM) desenvolvida pela empresa Altem
Tecnologia Ltda, contendo 01 microcontrolador ARM NXP LPC 1751, 01
driver RS-485 modelo SN65LBC184 da Texas Instruments, 01 Módulo
GSM/GPRS SIM900, 01 slot para chip de operadora de telefonia celular,
capacitores, resistores, reguladores de tensão, cristal, entre outros;
 01 chicote com 4 fios utilizado para comunicação via RS-485 entre GSM e
Dispositivo;
 01 fonte 12 volts;
 01 gravador Keil Linker-ME;
 01 display LCD;
 01 medidor portátil Gas Alert NH3.
3.3 MÉTODOS
Para o desenvolvimento do software de monitoramento web, hardware e seus sistemas
embarcados, foram empregados os métodos de desenvolvimento descritos abaixo.
Documento de Especificação de Requisitos para a Aplicação Web de Monitoramento.
Apresenta toda a engenharia de requisitos, a modelagem é separada em camadas (MVC)
utilizando a linguagem UML e o desenvolvimento do software em linguagem Java;
Desenvolvimento de Hardware e Interfaceamento. Apresenta o desenvolvimento do
circuito de condicionamento do sinal do Dispositivo, contexto do projeto (apresentado em
Diagrama de Blocos), análise de requisitos dos sistemas embarcados (apresentado em
Diagramas de Requisitos Funcionais utilizando a linguagem SysML), modelagem dos
processos BPMN (apresentado em Diagramas de Processos, a serem implementados no
sistema embarcado do Dispositivo e do GSM) e o desenvolvimento dos firmwares em
linguagem C.

49
4 DESENVOLVIMENTO
O capítulo de desenvolvimento tem por objetivo apresentar o desenvolvimento
propriamente dito do J. SISMAAG - Sistema de Monitoramento do Gás Amônia em Aviários.
No item 4.1 encontra-se o desenvolvimento da Aplicação Web de Monitoramento e no item
4.2 é apresentado o desenvolvimento de Hardware e Interfaceamento.
4.1 DOCUMENTO DE ESPECIFICAÇÃO DE REQUISITOS PARA A APLICAÇÃO
WEB DE MONITORAMENTO
Apresenta as especificações dos requisitos do Sistema Web de Monitoramento do Gás
Amônia em um aviário de frangos de corte. A atividade de análise de requisitos foi conduzida
aplicando-se técnicas de detalhamento dos requisitos, modelagem de casos de uso,
modelagem de classes e modelagem das camadas Model, View e Controller do sistema.
Basicamente a Aplicação Web é composta de quatro classes, sendo elas: Usuario,
ModuloGSM, Dispositivo e RegistrosConcentracaoAmonia. No esquema 3 pode-se ter
uma visão geral do sistema.
Esquema 3 - Visão Geral do Sistema.
Fonte: o autor.
4.1.1 Levantamento de Requisitos
Neste tópico são identificados e detalhados os requisitos funcionais e requisitos
suplementares do sistema desenvolvido.

50
Requisitos funcionais:
 Manter Informações de Usuário;
 Manter Informações de Módulo GSM;
 Manter Informações de Dispositivo;
 Gerenciar Registros de Concentração do Gás Amônia.
Requisitos suplementares:
 Interface baseada em formulários;
 Controle de acesso realizado através de dois níveis definidos por usuário e
senha, sendo eles administrador e cliente.
Para o detalhamento dos requisitos funcionais, que tem como função proporcionar ao
desenvolvedor uma visão detalhada das funções que o software desempenhar, foi seguido o
modelo proposto por Wazlawick (2011) composto pelos itens em negrito detalhados nos
quadros a seguir. Nos Quadros 4, 5 e 6 segue o detalhamento dos requisitos Manter
Informações de Usuário, Modulo GSM e Dispositivo respectivamente no sistema, para as
quatro operações básicas utilizadas para os mesmos (Create, Read, Update, Delete).
Quadro 4 - Requisito Funcional Manter Informações de Usuário.
Fonte: o autor.
Para o requisito Manter Informações de Usuário citado acima, as informações de
F01. MANTER INFORMAÇÕES DE USUÁRIO
Descrição:
Manter os registros de usuário no sistema com as opções de inserir, alterar, excluir e consultar os
dados dos mesmos. Estas informações são necessárias para definir o controle de acesso do usuário
ao sistema;
Fonte de informação:
Administrador;
Usuários:
Administrador;
Informações de entrada:
Nome do usuário, usuário, senha, e-mail, telefone, celular, endereço, CPF, nível, ativo;
Informações de saída:
- Gerar uma listagem contendo todos os dados de todos os usuários do sistema;
- Gerar uma listagem contendo todos os dados de apenas um usuário do sistema, consultando-o pelo
seu nome;
Restrições lógicas:
- O usuário administrador pode excluir um usuário do tipo cliente já cadastrado no sistema apenas
quando não existir uma associação do mesmo com algum dispositivo já cadastrado no sistema;
- O atributo usuário refere-se ao valor que o usuário irá utilizar para realizar o “login” no sistema;
- O atributo nível é do tipo inteiro, de uma posição e refere-se ao controle de acesso, se definido
com o valor 1o usuário é do tipo administrador, se definido com o valor 2 é do tipo cliente;
- O atributo ativo é do tipo booleano e define se o usuário está ativo ou não no sistema;
Restrições tecnológicas:
Possuir acesso à internet.

Monitoramento NH3 Aviários

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Monitoramento NH3 Aviários

Semelhante a Monitoramento NH3 Aviários (20)

Monitoramento NH3 Aviários