SlideShare uma empresa Scribd logo

TCC - SISTEMA PARA MONITORAMENTO DO GÁS AMÔNIA EM AVIÁRIOS

•
J
Jean Luiz Zanatta

O trabalho apresenta o desenvolvimento de um protótipo de sistema web para monitoramento da concentração de gás amônia em aviários, integrando software e hardware. O sistema utiliza telemetria com comunicação sem fio via GSM e conexão à internet, sendo baseado em microcontroladores ARM. Conclui-se que o sistema pode ser aplicado em diversas áreas onde a monitorização do gás amônia e a telemetria são essenciais.

Tecnologia
1 de 115
Baixar para ler offline
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
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 J. SISMAAG - SISTEMA PARA MONITORAMENTO DO GÁS AMÔNIA EM 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 J. SISMAAG - SISTEMA PARA MONITORAMENTO DO GÁS AMÔNIA EM 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 Desenvolvimento do relatório 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 Desenvolvimento do relatório 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 (Unified 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.
51 entrada foram definidas pelo administrador de forma a atender as necessidades do sistema proposto, sendo que o software para monitoramento estará exposto na web, para manter um controle de acesso necessita de um eficiente controle de segurança. Dados como usuário, senha e nível devem estar registrados ao cadastrar um usuário de forma que o sistema, quando o usuário efetuar o acesso, define sua prioridade. Quadro 5 - Requisito Funcional Manter Informações de Módulo GSM. Fonte: o autor. O requisito Manter Informações de Módulo GSM tem acesso apenas pelo usuário administrador, sendo que o atributo identificador deve ser definido quando ele tiver em mãos os dados do módulo GSM implantado, pois através deste identificador o sistema reconhece que o módulo GSM “x” está associado ao dispositivo “y”. Os atributos “csq” e “crédito” da entidade móduloGSM, mencionados no modelo conceitual, são atualizados na Aplicação Web de Monitoramento pelo próprio sistema, quando o módulo GSM envia as informações. São considerados importantes, pois é através destes dados que o administrador tem conhecimento da qualidade do sinal, número que pode variar de 0 a 31, e conhecimento do valor do crédito do chip utilizado no módulo GSM, valor este que sempre deve estar positivo, pois só assim as informações podem ser repassadas para a Aplicação Web de Monitoramento. F02. MANTER INFORMAÇÕES DE MÓDULO GSM Descrição: Manter os registros de módulo GSM no sistema com as opções de inserir, alterar, excluir e consultar os dados dos mesmos. São informações do módulo GSM, esse responsável por enviar as informações dos registros de gás amônia efetuados pelo sensor para a aplicação web de monitoramento; Fontes: Administrador; Usuários: Administrador; Informações de entrada: Identificador, nome GSM, CSQ e credito. Informações de saída: - Gerar uma listagem contendo todos os dados de todos os módulos GSM do sistema; - Gerar uma listagem contendo todos os dados de apenas um módulo GSM do sistema, podendo realizar a consulta pelo seu nome ou pelo usuário associado a ele; Restrições lógicas: - O usuário administrador pode excluir um Modulo GSM já cadastrado no sistema somente quando não existir um dispositivo já cadastrado associado ao mesmo. - O atributo identificador é do tipo inteiro, de três posições, e refere-se a sua identificação para reconhecimento na entidade Dispositivo, pois o módulo GSM é quem envia as informações coletados pelo dispositivo para a aplicação web de monitoramento; Restrições tecnológicas: Possuir acesso à internet.
52 Quadro 6 - Requisito Funcional Manter Informações de Dispositivo. Fonte: o autor. O requisito funcional Gerenciar Registros de Concentração do Gás Amônia é considerado de um nível mais complexo, passa pelos mesmos processos dos requisitos anteriores que são: inserir, alterar, excluir e consultar os dados, porém com restrições, onde somente o sistema pode inserir ou alterar os dados, cabendo ao administrador poder excluir e consultar os dados, e restando ao cliente apenas poder consultar os dados. Segue no quadro 7 o detalhamento deste requisito. F03. MANTER INFORMAÇÕES DE DISPOSITIVO Descrição: Manter os registros de dispositivo no sistema com as opções de inserir, alterar, excluir e consultar os dados do mesmo. O dispositivo é quem realiza a aquisição de sinal, através do sensor, e os dados são armazenados na aplicação web através de seu identificador. Fontes: Administrador; Usuários: Administrador; Informações de entrada: Identificador, nome do dispositivo, usuário do tipo cliente e módulo GSM; Informações de saída: - Gerar uma listagem contendo todos os dados de todos os dispositivos do sistema; - Gerar uma listagem contendo todos os dados de apenas um dispositivo do sistema, consultando-o pelo seu nome ou pelo usuário associado a ele ou pelo módulo GSM associado a ele; Restrições lógicas: - O usuário administrador pode inserir um dispositivo no sistema, somente após associar ao mesmo, um usuário cliente e um módulo GSM já cadastrados no sistema; - O usuário administrador pode excluir um dispositivo do sistema somente após não haver nenhuma associação de registros de concentração de amônia do mesmo; - O atributo identificador é do tipo inteiro, de três posições, e refere-se a sua identificação para reconhecimento do dispositivo na aplicação web de monitoramento, pois ao enviar as informações para a aplicação mencionada, um dos dados informados pelo módulo GSM é o identificador do dispositivo, e é através deste identificador que o sistema insere ou atualizado os dados na aplicação; - Os atributos usuário do tipo cliente e módulo GSM são os respectivos: * usuário, este é quem adquiriu o próprio dispositivo; * módulo GSM, este é o responsável por mandar as informações deste dispositivo para a aplicação web de monitoramento; Restrições tecnológicas: Possuir acesso á internet.
53 Quadro 7 - Requisito Funcional Gerenciar Registros de Concentração do Gás Amônia. Fonte: o autor. O requisito funcional Gerenciar Registros de Concentração do Gás Amônia diz respeito apenas as operações das informações que estarão armazenadas na tabela RegistroAmonia pelos usuários definidos. Quando o módudo GSM for requisitado pelo firmware para enviar as informações coletadas pelo sensor do dispositivo para a Aplicação Web de Monitoramento, cabe ao software realizar o tratamento destes dados, pois no pacote de dados enviado pelo módulo GSM existem valores que devem ser armazenados em tabelas diferentes no banco de dados. O pacote enviado para a Aplicação Web de Monitoramento pelo módulo GSM contem os seguintes dados:  Identificador do dispositivo;  Concentração de gás amônia medida pelo sensor;  Dia, mês, ano, hora, minutos e segundos;  CSQ e crédito; F04. GERENCIAR REGISTROS DE CONCENTRAÇÃO DO GÁS AMÔNIA Descrição: Obter os dados registrados pelo sensor do dispositivo e registrá-los na aplicação web de monitoramento para o usuário cliente e administrador poderem efetuar a consulta de informações em tempo real; Fontes: Administrador; Usuários: Sistema GSM, Administrador e Cliente; Informações de entrada: Data, hora, concentração do gás amônia e identificador do dispositivo; Informações de saída: - Gerar uma listagem contendo todos os dados dos registros de concentração de amônia do aviário do respectivo cliente, consultando-o pelo nome do cliente; Restrições lógicas: - Estes dados podem ser inseridos ou alterados somente pelo usuário Sistema GSM; - Antes de o Sistema GSM inserir os dados na aplicação web de monitoramento, o software deve verificar através do identificador do dispositivo enviado pelo módulo GSM, se o próprio dispositivo está cadastrado no sistema. Caso não exista, o software deve ignorar as informações enviadas pelo módulo GSM; - O sistema GSM deve inserir os dados somente quando não houver outro registro de concentração do gás amônia para a data especificada; - O sistema GSM deve atualizar os dados somente quando houver outro registro de concentração de gás amônia para a data especificada; - Os dados de registros de concentração de gás amônia podem ser excluídos da aplicação web de monitoramento pelo usuário administrador, informando o dispositivo; Restrições tecnológicas: - Possuir acesso à internet; - Possuir acesso à rede de telefonia celular onde o aviário está localizado;
54 Os únicos dados que não devem ser armazenados na tabela RegistroAmonia são os de CSQ e crédito. Estes devem ser atualizados em módulo GSM. 4.1.2 Modelo de Casos de Uso O modelo de casos de uso visa capturar e descrever as funcionalidades que o sistema deve prover para os atores que interagem com o mesmo. Os atores identificados no contexto deste projeto estão descritos no quadro 8. Quadro 8 - Atores do Sistema. ATOR DESCRIÇÃO Administrador Representa os usuários funcionários responsáveis pela manutenção da aplicação da empresa que vendeu o sistema. Cliente Representa os usuários clientes da empresa que vendeu o sistema. Sistema GSM Representa o sistema de telefonia rede GSM/GPRS responsável por fazer a comunicação com o servidor e inserir no banco de dados os dados coletados pelo dispositivo de hardware. Fonte: o autor. A seguir é apresentado o diagrama de casos de uso e descrições associadas do sistema de monitoramento do gás amônia em aviários. Diagrama 2 - Casos de Uso do Sistema de Monitoramento do Gás Amônia em Aviários. Fonte: o autor.
55 4.1.3 Análise O tópico de análise definido no trabalho tem por objetivo detalhar as operações “CRUD” para usuário, módulo GSM e dispositivo, também o requisito Manter Informação de Registros de Concentração de Amônia, contendo as respectivas operações e consultas do sistema. Dividido em três atividades sendo elas diagrama de sequencia, modelo conceitual e contratos, a fase de análise se concentra na fase de análise dos casos de uso Manter Informações de Registros de Concentração de Amônia e Manter Informações de Dispositivo, pois os requisitos Manter Informações de Usuário e Módulo GSM segue o mesmo padrão do Manter Informações de Dispositivo. 4.1.3.1 Diagrama de Sequência O Diagrama de Sequência elaborado no projeto tem como objetivo mostrar como as mensagens entre os objetos são trocadas no decorrer do tempo apenas para a realização da operação Registrar Concentração de Amônia, pois para os casos de uso manter Informações de usuário, Modulo GSM e Dispositivo as operações são menos complexas, sendo elas de salvar, alterar, consultar e excluir. As interações entre os objetos para estas operações onde não são ilustradas no diagrama de sequência estão no diagrama de comunicação no item 4.1.4.1. Para registrar a concentração do gás amônia o ator Sistema GSM deve repassar informações para a interface que a partir dos dados recebidos do Módulo GSM deve indicar para qual dispositivo as informações serão registradas, e então armazenar os dados. Diagrama 3 - Diagrama de Sequencia Registrar Concentração de NH³. Fonte: o autor.
56 4.1.3.2 Modelo Conceitual Para o desenvolvimento, o diagrama de classes da UML é utilizado, com algumas restrições. Informalmente, podemos dizer que o modelo conceitual é um diagrama de classes sem métodos. Apenas conceitos, atributos e associações são representados. Com o auxílio da ferramenta Astah Community, usando o diagrama de classes da UML, foi desenvolvido o modelo conceitual a seguir: Diagrama 4 - Modelo Conceitual. Fonte: o autor. 4.1.3.3 Contratos Na elaboração do Diagrama de Sequencia, foram identificadas as operações e consultas para registros de concentração de amônia. A operação de “registrar concentração do gás amônia” implica a existência de uma intenção por parte do usuário Sistema GSM, que é capturada pelo contrato de operação. No Quadro 9 encontra-se o contrato para a operação indicar dispositivo efetuada pelo sistema no requisito funcional Manter Informações de Dispositivo. Quadro 9 - Contrato Operação Indicar Dispositivo. Fonte: o autor. Operação:  indicarDisp(id); Pré-condições:  Deve existir um dispositivo cadastrado com o atributo idDisp igual ao parâmetro id; Pós-condições:  O controlador retorna o dispositivo encontrado para então poder efetuar o registro uma nova concentração;
57 A pré-condição e pós-condição da operação indicar dispositivo são bem básicas. Na pré-condição simplesmente deve existir um dispositivo já cadastrado no sistema, pois para registrar a concentração do gás amônia o sistema deve informar de qual dispositivo foi registrado estes dados. O quadro 10, diz respeito ao contrato da operação “registrar concentração do gás amônia”, esta que é requisitada pelo sistema GSM ao enviar os dados de telemetria. Quadro 10 - Contrato Operação Registrar Nova Concentração NH³. Fonte: o autor. Para as operações CRUD do sistema foram elaborados apenas os contratos das operações do caso de uso Manter Informações de Dispositivo, pois, como mencionado anteriormente no item 4.1.1, os três casos de uso seguem o mesmo padrão. No quadro 11 segue o contrato para a operação de inserção de dispositivo. Quadro 11 - Contrato Operação Inserir Dispositivo. Fonte: o autor. Para o contrato acima mencionado as duas pré-condições foram estabelecidas devido ao fato de que para o administrador poder inserir um novo dispositivo no sistema, deve-se associar ele a um usuário do tipo cliente e um módulo GSM, pois o dispositivo pertence a um cliente e cada dispositivo deve ter um módulo GSM para enviar seus dados coletados para a aplicação web de monitoramento. Operação:  registrarNovaConcentração(data, hora, conc_medida); Pré-condições:  Deve existir um dispositivoCorrente; Pós-condições:  Foi criada uma instancia de registroAmonia chamada rA;  Foi criada uma associação entre dispositivoCorrente e rA;  Foram alterados os atributos de rA conforme os parâmetros; Operação:  salvarDisp(id, nome, usuário, moduloGSM); Pré-condições:  Existir um usuário já cadastrados no sistema com o atributo idUsu igual ao parâmetro usuário;  Existir um modulo GSM já cadastrado no sistema com o atributo idGSM igual ao parâmetro moduloGSM; Pós-condições:  Foi criada uma instancia de Dispositivo chamada disp;  Foi criada uma associação entre Controlador e disp;  Foram alterados os atributos de disp conforme os parâmetros;
58 Quadro 12 - Contrato Operação Alterar Dispositivo. Fonte: o autor. O contrato de operação alterar dispositivo acima é bem simples, sendo que para alterar os dados de qualquer dispositivo já cadastrado a aplicação deve indicar um dispositivo, o controlador deve buscar este dispositivo e depois de verificado sua existência alterar os dados. O contrato do quadro 13 segue o mesmo principio do anterior, onde a aplicação deve indicar um dispositivo, o controlador deve buscar este dispositivo e depois de verificado sua existência, porém somente irá destruí-lo se não haver nenhum registro de concentração de gás amônia relacionado a ele. Quadro 13 - Contrato Operação Excluir Dispositivo. Fonte: o autor. 4.1.4 Projeto da Camada Model A camada Model representa a parte que implementa a lógica de negócios da aplicação. O modelo encapsula o estado e comportamento da aplicação, sendo responsável por obter os dados convertendo-os em conceitos significativos, assim como, processar, validar, associar e qualquer outra tarefa relativa ao tratamento dos dados. É o único componente do MVC que faz a interface da aplicação frente á fonte de dados, que é representada pelo banco de dados. A tecnologia utilizada para a criação da camada Model na aplicação é o Hibernate. O Projeto da Camada Model está dividido em três tópicos. Primeiramente é elaborado o diagrama de comunicação (colaboração), seguido do diagrama de classes do projeto e por último a modelagem do banco de dados a se utilizar com a elaboração do modelo conceitual e lógico do mesmo. Operação:  alterarDisp(); Pré-condições:  Existir um dispositivoCorrente denominado disp; Pós-condições:  Foram alterados os atributos de disp conforme os parâmetros; Operação:  excluirDisp(); Pré-condições:  Existir um dispositivoCorrente denominado disp;  Não existir nenhum registro de concentração do gás amônia com o atributo idDisp igual ao parâmetro id; Pós-condições:  Foi excluído o dispositivo indicado pela aplicação;
59 4.1.4.1 Diagrama de Comunicação O diagrama de comunicação, também conhecido como diagrama de colaboração, permite realizar a modelagem dinâmica do sistema, diferentemente dos artefatos já concluídos, que são estáticos. Nessa fase, veremos como os objetos que fazem parte da arquitetura do sistema trocam mensagens para realizar suas responsabilidades. As mensagens, enumeradas sequencialmente, mostram a implementação das operações, descrevendo parâmetros e variáveis locais. O Diagrama de Comunicação elaborado visa mostrar a comunicação dinâmica entre os objetos da operação “inserir dispositivo” no sistema. Diagrama 5 - Diagrama de Comunicação Inserir Dispositivo. Fonte: o autor. Na operação “alterar dispositivo”, primeiramente o usuário administrador indica o dispositivo no qual deseja realizar as alterações e então insere os novos dados no formulário e salva. O diagrama 6 visa mostrar a troca de mensagens entre os objetos para a operação “alterar dispositivo”. Diagrama 6 - Diagrama de Comunicação Alterar Dispositivo. Fonte: o autor. O diagrama 7 visa mostrar a comunicação dinâmica entre os objetos para a operação
60 “excluir dispositivo”. Diagrama 7 - Diagrama de Comunicação Excluir Dispositivo. Fonte: o autor. Para o caso de uso Manter Informações de Registros de Concentração de Amônia, a operação principal é a de registrar a concentração de amônia na aplicação web de monitoramento. O diagrama 8 ilustra o diagrama de comunicação desta operação. Diagrama 8 - Diagrama de Comunicação Registrar Concentração de NH³. Fonte: o autor. 4.1.4.2 Diagrama de Classes do Projeto O diagrama de classes demostra em seu conteúdo as quatro classes definidas no projeto com os relacionamentos entre elas, seus atributos, métodos e como os dados do sistema estão dispostos entre si. Os métodos contidos no Controlador são responsáveis pela execução de eventos emitidos da Aplicação para as quatro classes do sistema: Usuario, ModuloGSM, Dispositivo e RegistroAmonia. Estes eventos estão relacionados a indicar, associar, criar, alterar, excluir, alterar ou registrar concentração de amônia para qualquer objeto que venha represente a classe definida. Já os métodos contidos nas Classes propriamente ditas são responsáveis por executar decisões referentes aos eventos emitidos pelo Controlador, a exemplo, para registrar dados de
61 concentração de amônia o Controlador chama o método indicarDisp(id), o Dispositivo retorna com o método getDis(id), registrarNovaConcentracao(data, hora, concentracao), criarRegistroAmonia(), associarRA(registroAmonia) e então a classe RegistroAmonia chama o método setDados(data, hora, conc_medida) armazenando os dados na tabela no banco de dados. O diagrama 9 ilustra o diagrama de classes do projeto. Para fins de visualização dos atributos e métodos das classes, nos métodos da classe Usuário foi removida a visibilidade dos atributos. Diagrama 9 - Diagrama de Classes do Projeto. Fonte: o autor. 4.1.4.3 Modelagem do Bando de Dados Embasado no modelo conceitual e diagrama de classes foi realizada a modelagem do banco de dados. Para a modelagem do banco elaborou-se dois diagramas. Primeiramente, foi desenvolvido o diagrama de modelagem conceitual seguido da modelagem lógica. O diagrama 10 ilustra o diagrama de modelagem conceitual do banco de dados que é utilizado para realizar a identificação das entidades e seus atributos a serem implementados e
62 os relacionamentos entre as mesmas. Diagrama 10 - Diagrama da Modelagem Conceitual do Banco de Dados. Fonte: o autor. A modelagem lógica, responsável pela visualização das tabelas com seus respectivos atributos, chaves primárias e chaves estrangeiras do banco de dados do sistema e apresentada no diagrama 11 através do diagrama modelo lógico do banco de dados. Diagrama 11 - Diagrama do Modelo Lógico do Banco de Dados. Fonte: o autor.
63 4.1.5 Projeto da Camada View Uma View exibe uma representação dos dados modelados. Esta camada é responsável pela apresentação, trata-se da fronteira entre usuário e o sistema em si. A tecnologia utilizada para a criação das telas (visões) da aplicação é o framework Primefaces em conjunto com o JSF. No modelo tradicional do MVC, a View é composta por GUI’s (Graphical Users Interface), enquanto que no MVC web, caso do projeto, a visualização das informações acontece através das páginas XHTML, onde as informações tratadas e visualizadas são dinâmicas. As diferenças estão no fato de que para a aplicação web é papel da camada Controller definir a View apropriada para a exibição da resposta obtida pela requisição feita, além de medir as notificações de Model, principalmente pela necessidade do reuso, é na View que ocorrem todas as interações do usuário que serão tratadas pelo controle para chamar os métodos apropriados no modelo. Os tópicos a seguir demonstram primeiramente o diagrama de Estados de Navegação, indicando quais janelas e eventos compõe o sistema. Após encontra-se o tópico do Projeto Gráfico das Telas do Sistema. 4.1.5.1 Diagrama de Estados de Navegação O diagrama de Estados de Navegação indica quais são as janelas que compõe o sistema e quais eventos permitem ao usuário navegar de uma para outra, permitindo poder visualizar o fluxo principal da Aplicação Web de Monitoramento proposta. Muitas vezes não é possível, antes da implementação do projeto, traçar exatamente todas as funcionalidade que a aplicação terá, mas pode-se ter uma clara visão de como se dará a navegação dentro da aplicação. Cada evento que rotula as transições do diagrama posteriormente será associado a um controle (botão) da janela na origem da transição. O diagrama 12 apresenta o Diagrama de Estados de Navegação da Aplicação Web de Monitoramento. O usuário ao acessar a página na internet é direcionado automaticamente para uma tela de login, onde após inserir seus dados corretamente o sistema o direciona para uma tela principal. Se o usuário for do tipo cliente poderá apenas consultar os registros da concentração do gás amônia efetuados pelo seu dispositivo. Se do tipo administrador, terá acesso às páginas para manter registros de usuário, dispositivo, módulo GSM e registros da concentração de gás amônia de todos os clientes que tem um dispositivo ativo.
64 Diagrama 12 - Diagrama de Estados de Navegação. Fonte: o autor. 4.1.5.2 Projeto Gráfico das Telas do Sistema Segundo Wazlawick 2011, para fazer o projeto gráfico de cada janela, o projetista deverá saber quais são os objetivos da janela e qual caso de uso ela realiza. É possível também que algumas janelas realizem apenas alguns fluxos alternativos de um caso de uso. As janelas da aplicação são baseadas nos componentes do framework Primefaces, e estão no formato XHTML. Para cada componente definido deve-se criar uma janela para o usuário interagir com o sistema. A figura 1 ilustra a tela de Login do sistema. Figura 1 - Projeto Gráfico da Tela de Login. Fonte: o autor. A primeira interação que o usuário realizará com o sistema, é na tela de Login, onde ele estará "entrando" no sistema. Ao validar seu acesso, o sistema o redireciona dependendo de seu tipo (status), se estiver definido como 1 (administrador) ele será redirecionado para a tela “Principal Admin”, e se seu status estiver definido como 2 (cliente) será redirecionado
65 para a tela “Principal Cliente”. Se administrador, feito isso o usuário terá as seguintes opções a sua disposição: Cadastros de Usuário, Cadastros de Módulo GSM, Cadastros de Dispositivo ou então Registros de NH³. Se cliente, terá acesso apenas à tela de Registros de NH³ tendo a opção de selecionar de qual dispositivo deseja visualizar os registros caso tenha mais de um dispositivo cadastrado em seu nome. Os dois tipos de usuários também tem a opção de encerrar o sistema no momento em que desejar. Relação entre o componente gráfico da tela de Login e a operação realizada pelo sistema:  Botão “Log in”: através do componente <p:commandButton action=””> ativa a função Login() do Managed Bean LoginMB onde o sistema acessa a base de dados e verifica se o acesso é válido. Após isso, armazena os dados na sessão e então faz a verificação do status e redireciona o usuário para a página permitida. Foi incorporado o projeto Facelets ao sistema. É um método para desenho de layout que possuí tags para criação de templates (layouts de páginas que podem ser reaproveitadas). Então, para administradores foi criado um template com cabeçalho, menu e conteúdo. E para clientes foi criado um template apenas com cabeçalho e conteúdo, pois ao “entrar” no sistema ele terá acesso a apenas uma tela. Assim, após efetuar seu login, o administrador navegará por telas padronizadas mantendo o cabeçalho e menu estáticos sendo alterado apenas o conteúdo dependendo do que o usuário deseja visualizar. A figura 2 ilustra a tela “Principal Admin”, ela contém o cabeçalho e menu principal. A partir daí o usuário administrador poderá navegar para a tela que desejar. Ao clicar no botão desejado no menu, o que será alterado é apenas o espaço do conteúdo. Figura 2 - Projeto Gráfico da Tela Principal Admin. Fonte: o autor.
66 Relação entre os componentes gráficos da tela “Principal Admin” e as operações realizadas pelo sistema:  Botão “Cadastros” de Usuário: através do componente <p:menuitem action=””> ativa a navegação para “Listar Usuários”.  Botão “Cadastros” de Módulo GSM: através do componente <p:menuitem action=””> ativa a navegação para “Listar Módulos GSM”.  Botão “Cadastros” de Dispositivo: através do componente <p:menuitem action=””> ativa a navegação para “Listar Dispositivos”.  Botão “Registros” de NH³: através do componente <p:menuitem action=””> ativa a navegação para “Listar Registros de NH³” para administrador.  Botão “Log out”: através do componente <p:commandButton action=””> ativa a função Logout() do Managed Bean UsuarioMB onde o sistema torna a sessão inválida e ativa a navegação para a tela de Login. A figura 3 ilustra o conteúdo da tela “Listar Usuários”, onde o administrador tem acesso aos dados de todos os usuários cadastrados no sistema e também tem a opção de adicionar, alterar ou excluir um usuário cadastrado. Figura 3 - Projeto Gráfico da Tela Listar Usuários. Fonte: o autor. Relação entre os componentes gráficos da tela “Listar Usuários” e as operações realizados pelo sistema:  Botão “Novo”: através do componente <p:commandButton oncomplete=””> ativa a navegação para o formulário “dialogUsuario”, atribuí o valor true para novo usuário e null para o objeto do tipo Usuario, indicando para o sistema que um novo usuário será criado.  Botão “Alterar”: através do componente <p:commandButton oncomplete=””> ativa a navegação para o formulário “dialogUsuario”, atribui o valor false para novo usuário e o usuário selecionado para o objeto do tipo Usuario, trazendo assim
67 todas as informações do usuário no formulário e indicando para o sistema que o usuário selecionado poderá ter seus dados alterados.  Botão “Excluir”: através do componente <p:commandButton onclick=””> ativa a navegação para uma caixa de dialogo de confirmação. Após confirmado, ativa a função Excluir() do Managed Bean UsuarioMB onde o sistema realiza a verificação se é possível excluir o usuário selecionado, se sim o exclui da base de dados. A figura 4 ilustra a tela do formulário cadastro/alteração “dialogUsuario”, utilizada para cadastrar/alterar um usuário. Este formulário está editado dentro do arquivo da tela “Listar Usuários”. Figura 4 - Projeto Gráfico do Formulário dialogUsuario. Fonte: o autor. Neste formulário o administrador deve então inserir todos os dados do usuário a ser criado ou alterado. Relação entre os componentes gráficos do formulário de criação/alteração de usuário e as operações realizados pelo sistema:  Botão “Salvar”: através do componente <p:commandButton actionListener=””> ativa a função Salvar() do Managed Bean UsuarioMB onde o sistema salva os dados do usuário no Banco de Dados.  Botão “Cancelar”: através do componente <p:commandButton oncomplete=””> torna o formulário “dialogUsuario” invisível, cancelando a operação de criação ou alteração de usuário. A figura 5 ilustra o conteúdo da tela “Listar Módulos GSM”.
68 Figura 5 - Projeto Gráfico da Tela de Listar Módulos GSM. Fonte: o autor. Relação entre os componentes gráficos da tela “Listar Módulos GSM” e as operações realizados pelo sistema:  Botão “Novo”: através do componente <p:commandButton oncomplete=””> ativa a navegação para o formulário “dialogModuloGSM”, atribuí o valor true para novo módulo GSM e null para o objeto do tipo ModuloGSM, indicando para o sistema que um novo módulo GSM será criado.  Botão “Alterar”: através do componente <p:commandButton oncomplete=””> ativa a navegação para o formulário “dialogModuloGSM”, atribui o valor false para novo módulo GSM e o módulo GSM selecionado para o objeto do tipo ModuloGSM, trazendo assim todas as informações do módulo GSM no formulário e indicando para o sistema que o módulo GSM selecionado poderá ter seus dados alterados.  Botão “Excluir”: através do componente <p:commandButton onclick=””> ativa a navegação para uma caixa de dialogo de confirmação. Após confirmado, ativa a função Excluir() do Managed Bean ModuloGSMMB onde o sistema realiza a verificação se é possível excluir o módulo GSM selecionado, se sim o exclui da base de dados. A figura 6 ilustra a tela do formulário cadastro/alteração “dialogModuloGSM”, utilizada para cadastrar/alterar um módulo GSM. Este formulário está editado dentro do arquivo da tela “Listar Módulos GSM”. Figura 6 - Projeto Gráfico do Formulário dialogModuloGSM. Fonte: o autor. Neste formulário o administrador deve então inserir o código e nome do módulo GSM
69 a ser criado ou alterado. Relação entre os componentes gráficos do formulário de criação/alteração de módulo GSM e as operações realizados pelo sistema:  Botão “Salvar”: através do componente <p:commandButton actionListener=””> ativa a função Salvar() do Managed Bean ModuloGSMMB onde o sistema salva os dados do módulo GSM no Banco de Dados.  Botão “Cancelar”: através do componente <p:commandButton oncomplete=””> torna o formulário “dialogModuloGSM” invisível, cancelando a operação de criação ou alteração de módulo GSM. A figura 7 ilustra o conteúdo da tela “Listar Dispositivos”. Figura 7 - Projeto Gráfico da Tela de Listar Dispositivos. Fonte: o autor. Relação entre os componentes gráficos da tela “Listar Dispositivos” e as operações realizados pelo sistema:  Botão “Novo”: através do componente <p:commandButton oncomplete=””> ativa a navegação para o formulário “dialogDispositivo”, atribuí o valor true para novo dispositivo e null para o objeto do tipo Dispositivo, indicando para o sistema que um novo dispositivo será criado.  Botão “Alterar”: através do componente <p:commandButton oncomplete=””> ativa a navegação para o formulário “dialogDispositivo”, atribui o valor false para novo dispositivo e o dispositivo selecionado para o objeto do tipo Dispositivo, trazendo assim todas as informações do dispositivo no formulário e indicando para o sistema que o dispositivo selecionado poderá ter seus dados alterados.  Botão “Excluir”: através do componente <p:commandButton onclick=””> ativa a navegação para uma caixa de dialogo de confirmação. Após confirmado, ativa a função Excluir() do Managed Bean DispositivoMB onde o sistema realiza a verificação se é possível excluir o módulo GSM selecionado, se sim o exclui da base de dados. A figura 8 ilustra a tela do formulário cadastro/alteração “dialogDispositivo”, utilizada
70 para cadastrar/alterar um dispositivo. Este formulário está editado dentro do arquivo da tela “Listar Dispositivos”. Figura 8 - Projeto Gráfico do Formulário dialogDispositivo. Fonte: o autor. Neste formulário o administrador deve então inserir o código e nome do dispositivo a ser criado/alterado e informar através das caixas de seleção a qual usuário ele irá pertencer e a qual módulo GSM ele estará associado. Relação entre os componentes gráficos do formulário de criação/alteração de dispositivo e as operações realizados pelo sistema:  Botão “Salvar”: através do componente <p:commandButton actionListener=””> ativa a função Salvar() do Managed Bean DispositivoMB onde o sistema salva os dados do dispositivo no Banco de Dados.  Botão “Cancelar”: através do componente <p:commandButton oncomplete=””> torna o formulário “dialogDispositivo” invisível, cancelando a operação de criação ou alteração de dispositivo. A última tela que o administrador terá acesso e a tela “Listar Registros de NH³”. Nessa tela o administrador poderá visualizar os registros efetuados pelos dispositivos de todos os seus clientes. Primeiramente deve-se selecionar um cliente, em seguida deve-se selecionar um dispositivo do cliente selecionado anteriormente. A figura 9 ilustra o conteúdo da tela “Listar Registros de NH³” para o administrador. Figura 9 - Projeto Gráfico da Tela de Registros de NH³ Para Administrador. Fonte: o autor.
71 Relação entre os componentes gráficos da tela “Listra Registros de NH³” e as operações realizados pelo sistema:  Caixa de Seleção “Cliente”: através do componente <p:selectOneMenu> ativa a função getUsuariosClientes() do Managed Bean RegistroConcentracaoAmoniaMB que lista todos os usuários do tipo Cliente existentes no sistema. Selecionado o usuário cliente, o sistema o atribui para uma variável o objeto do tipo Usuario.  Caixa de Seleção “Dispositivo”: através do componente <p:selectOneMenu> ativa a função getDispositivosDoCliente() do Managed Bean RegistroConcentracaoAmoniaMB que lista todos os dispositivos do usuário cliente selecionado na caixa de seleção “Cliente”. Selecionado o dispositivo, o sistema “popula” o componente <p:dataTable> com os registros do dispositivo selecionado.  Botão “Excluir”: através do componente <p:commandButton onclick=””> ativa a navegação para uma caixa de dialogo de confirmação. Após confirmado, ativa a função Excluir() do Managed Bean RegistroConcentracaoAmoniaMB onde o sistema exclui o registro selecionado da base de dados. A figura 10 ilustra a tela “Principal Cliente”, ela contém apenas o cabeçalho e conteúdo. Nela o usuário cliente poderá selecionar o dispositivo desejado e visualizar os seus registros. Deve-se lembrar que estarão disponíveis para seleção apenas os dispositivos cadastrados em seu nome. Figura 10 - Projeto Gráfico da Tela Principal Cliente. Fonte: o autor. Relação entre os componentes gráficos da tela “Principal Cliente” e as operações realizados pelo sistema:
72  Caixa de Seleção “Dispositivo”: através do componente <p:selectOneMenu> ativa a função getDispositivosDoCliente() do Managed Bean RegistroConcentracaoAmoniaMB que lista todos os dispositivos do usuário cliente “logado” no sistema. Selecionado o dispositivo, o sistema “popula” o componente <p:dataTable> com os registros do dispositivo selecionado.  Botão “Log out”: através do componente <p:commandButton action=””> ativa a função Logout() do Managed Bean UsuarioMB onde o sistema torna a sessão inválida e ativa a navegação para a tela de Login. 4.1.6 Projeto da Camada Controller A camada Controller é responsável por realizar a comunicação entre o Model (modelo) e a View (visão). Sua finalidade é controlar interações que ocorram a partir do usuário (recebe entradas) e descobre o que essa entrada significa para o modelo, ou ainda, do modelo em resposta às ações anteriores. No projeto da aplicação web a solução encontrada para a criação do controlador central é a utilização da tecnologia da especificação Java JSF (Java Server Faces), e para os componentes da camada View realizar a interação com a camada Model o JSF interage com classes modelo denominadas Managed Beans, que ficam separadas da camada de visualização e nelas é que, por exemplo, parte do texto, fica guardada para interagir com um modelo, lógica de negócio ou outro componente visual. A seguir segue a definição das classes Managed Beans criadas no projeto e seus métodos que são utilizados para interação entre View e Model de cada requisito especificado no item 4.1.1.  Classe AbstratoMB: é responsável pela troca de mensagens entre o sistema e o usuário. Nela existem métodos que o sistema utiliza para mostrar mensagem de erro e mensagem de informação ao usuário quando necessário. Todas as classes seguintes herdam as características da classe AbstratoMB.  Classe UsuarioMB: toda vez que o administrador clicar no botão “Cadastros” de usuários irá navegar pela tela “Listar Usuarios” e as ações responsáveis pela lógica de negócios e interação com o modelo dessa página estão contidos nesta classe. Métodos como adicionar(), alterar() e excluir() são responsáveis por buscar os valores dos formulários e interagir com a DAO. O método salvar() é “chamado” toda vez que o administrador clica no botão “Salvar”. É ele quem verifica através da variável booleana addNewUsu se o
73 administrador deseja criar um novo usuário ou apenas alterar um usuário existente. Os métodos getAllUsuarios(), getUsuariosClientes() e getUsuariosAdmins() são responsáveis por listar os usuários existentes. E por fim o método Logout() fica com a responsabilidade de encerrar o sistema, tornando a sessão inválida e ativar a navegação para a tela de Login.  Classe LoginMB: a classe LoginMB é responsável apenas for fazer a verificação de login do usuário. Primeiramente é injetado a ela a classe UsuarioMB através da anotação @manegedProperty() e então o método Login() fica responsável por verificar, através dos dados “usuário” e “senha” digitados no formulário da tela “Login”, se o usuário existe na base de dados do sistema e em qual o status (tipo) ele se enquadra, para então o encaminhar para a tela permitida.  Classe ModuloGSMMB: segue o mesmo principio da classe UsuarioMB, porém as ações responsáveis pela lógica de negócios e interação com o modelo são referentes a tela “Listar Modulos GSM”. No método excluir() o sistema realiza uma verificação. Se na base de dados existir algum dispositivo relacionado ao módulo GSM que se pretende excluir, o sistema insere uma mensagem de erro na tela informando ao usuário que é impossível excluir o módulo GSM. Isso a fim de manter a integridade lógica dos dados.  Classe DispositivoMB: esta segue contém as ações responsáveis pela lógica de negócios, interação com o modelo e interação entre os próprios componentes da tela “Listar Dispositivos”. Segue o mesmo principio da classe UsuarioMB e ModuloGSMMB. Contém os métodos getUsuariosTipoClientes() e getModulosGSM() que são “chamados” nos selects do formulário de cadastro/alteração de dispositivo.  Classe RegistroConcentracaoAmoniaMB: Managed Bean responsável pela interação das telas de “Registros de NH³”, tanto do Administrador como do Cliente, com a camada Model. Nesta classe existem métodos para buscar registros de amônia tanto do cliente como do dispositivo. Os métodos getUsuSelecionado() e getDispSelecionado() armazenam o usuário e o dispositivo selecionado pelo administrador. Também existem os métodos usuarioChangeListener (ValueChangeEvent event) e dispositivoChangeListener(ValueChangeEvent event), o primeiro “popula” o select “Dispositivo” e o segundo “popula” a tabela com os registros efetuados pelo dispositivo selecionado. Por fim o método refresh() fica responsável por atualizar a tela “Registro de NH³” no momento em que há atualização efetuada pelo dispositivo corrente.
74 4.1.7 Servidor: Comunicação e Armazenamento dos Dados Após a modelagem dos processos de negócio e análise de requisitos, no projeto da Aplicação Web de Monitoramento, desenvolvido no Netbeans IDE 7.1, criou-se uma classe denominada ServidorTCP. Sua responsabilidade é a de realizar a comunicação com o sistema GSM por meio de um canal de comunicação designado por socket em protocolo TCP, que garante a entrega das mensagens pela mesma ordem a qual foram enviadas, processar os dados enviados pelo GSM e então armazená-los na base de dados da Aplicação. O quadro 14 ilustra o código desenvolvido para a realização das tarefas citadas acima. Quadro 14 - Classe Java ServidorTCP. Fonte: o autor.
75 Pode-se observar que a classe contém seu método de execução e uma classe interna denominada ThreadTrataCliente estendendo de thread, esta responsável por tratar as conexões recebidas pelo servidor, pois a comunicação se dá via socket multi thread, ou seja, pode-se ter vários clientes conectados no mesmo instante de tempo. Primeiramente define-se uma porta que deve estar liberada no servidor para comunicação TCP, em seguida dois objetos são criados (socket para conexão com servidor e socket privado para sessão com o cliente). Utilizando-se de um tratador de erros, em seguida é indicada a porta associada ao serviço para o servidor e então é executado um loop infinito onde inicia-se a thread responsável por realizar o tratamento das conexões efetuadas pelo cliente. Depois de estabelecida conexão, o tipo stream19 inputStreamReader oferecido pelo Java realiza a troca de mensagens. Em seguida, o sistema executa o método run(), responsável pelas tarefas de leitura da informação, quebra de pacotes, atualização da base de dados e finalização de transferências e conexões liberando recursos para o sistema. 4.2 DESENVOLVIMENTO DOS MÓDULOS DE HARDWARE E INTERFACEAMENTO Apresenta a modelagem e implementação dos módulos de hardware e interfaceamento. Desenvolveu-se primeiramente o circuito de condicionamento de sinal, e lógica de processamento dos dados presentes no Módulo Slave (Dispositivo). Com o objetivo de documentar e organizar o desenvolvimento de hardware, os sistemas embarcados (firmwares) e interfaceamento utilizou-se os métodos de modelagem da SysML e BPMN. 4.2.1 Circuito de Condicionamento do Sinal do Dispositivo O circuito de condicionamento do sinal desenvolvido pelo autor é um circuito divisor de tensão. Este segue o padrão para aquisição de sinal definido pelo fabricante do sensor utilizado no projeto, que determina a utilização de um resistor de 10 KOhm. Os divisores de tensão composto pelos resistores de 1 MOhm e 560 KOhm são utilizados para diminuir a tensão de leitura (no máximo 5 V) para uma tensão que o módulo ADC do uC aceite (no máximo 3.3 V). Além disso, os valores são bem altos, pois a impedância desse divisor de tensão deve ser muito maior que a impedância do circuito a ser lido (RI), para evitar distorção na leitura do sinal. A taxa de amostragem deste sinal é de 250 milissegundos. O Esquema 4 19 Em Java, stream é um objeto que permite obter dados de um fluxo de entrada ou enviar dados para algum fluxo de saída, usando um protocolo comum. (O AUTOR).
76 ilustra o circuito de condicionamento de sinal do projeto. Esquema 4 - Esquema do Circuito de Condicionamento do Sinal. Fonte: o autor. Os pinos As e Ah do microcontrolador são utilizados para completar corretamente o ciclo ilustrado no quadro 2 do tópico 2.6.2.1. Através deles e da lógica implementada no firmware, o sistema deve atribuir nível lógico alto ou baixo nos pinos 3 e 4 do sensor, como ilustrado acima. Para mostrar o funcionamento do dispositivo, pode-se dividir a explicação do circuito da seguinte maneira:  Circuitos para os ciclos de aquecimento e de leitura do sensor: visando explicar o funcionamento do circuito de condicionamento do sinal, para conseguir completar os ciclos de aquecimento e leitura do sensor, o circuito utiliza de dois transistores BC 807 da NXP, responsáveis por drenar corrente para o sensor, resistores de pull-up, com o objetivo de obter um nível lógico (0, 0 V ou 1, 5 V) na base dos transistores, saídas As (para leitura) e Ah (para aquecimento) conectadas aos pinos de I/O do uC configurados como saída em modo open-drain. Saídas A/D_1 e A/D_2 conectadas aos pinos dos canais 1 e 2 do ADC do uC e estão configurados como entrada para leitura do sinal, como observado no esquema 4 acima. Os transistores são do tipo PNP (lógica positiva), e possuem seus terminais conectados da seguinte maneira:  Emissor: ligados a fonte de 5 V na placa;  Base: ligados aos pinos As e Ah do microcontrolador;  Coletor: com saída para os pinos positivo do sensor; Para o circuito desenhado a corrente entra no terminal Emissor, e sai no terminal Coletor e Base. O valor da corrente no terminal Base é quem controla o fluxo de corrente do
77 Emissor para o Coletor, ou seja, os pinos de I/O do microcontrolador é quem definem o valor da tensão nos “pólos” positivo do sensor. O esquema 5 abaixo tem por objetivo ilustrar as principais conexões e o circuito de condicionamento de sinal do Módulo Slave. O uC recebe os dados capturados pelo sensor (entrada de dados), processa, e os envia para o LCD (saída local). Também ilustra a conexão para o gravador (JTAG) e conexões para o driver 485, responsável por realizar a interface entre o uC e o barramento RS-485. O esquema é apenas ilustrativo, alguns dos componentes desenhados não são os reais utilizados. Esquema 5 - Principais Conexões do Módulo Slave (Dispositivo). Fonte: o autor. 4.2.1.1 Processamento dos Dados Através dos valores da tensão lidos pelo módulo ADC do microcontrolador nos pinos AD_1 e AD_2, calcula-se o valor da resistência (impedância) do sensor, aplicando a Lei de Ohm e então este valor passa a ser convertido para um valor real de concentração de NH³, em ppm (Partícula Por Milhão), podendo variar de 0 a 100. Para esta conversão, utilizou-se os valores ilustrados no quadro 15, que são referentes à sensibilidade do sensor. Eles foram disponibilizados pelo fabricante do sensor utilizado e define a razão de concentração do gás amônia em função da resistência (impedância) do sensor. Os valores relacionados ao ar, etanol e H2S são utilizados no gráfico apenas para efeito de comparação.
78 Gráfico 1 - Sensibilidade do Sensor TGS 2444. Fonte: Figaro Engineering Inc., 2010. Os valores da resistência do sensor foram extraídos do gráfico acima e armazenados em um vetor de 102 posições, como ilustra o quadro abaixo. Na posição 0 do vetor é armazenada a resistência equivalente a concentração de 0 ppp e na posição 100 do vetor é armazenada a resistência equivalente a 100 ppm. A posição 101 indica saturação, é utilizada como delimitador para informar que a concentração do gás amônia está fora da faixa do sensor, pois este sensor, segundo o fabricante, deve ser utilizado para medir na faixa de 0 ppm a 100 ppm. Quadro 15 – NH³ (ppm) em Função da Resistência (ohm) do Sensor. NH3/Rs NH3/Rs NH3/Rs NH3/Rs NH3/Rs NH3/Rs 0/50400 1/47250 2/37800 3/31500 4/26250 5/23100 6/21000 7/18900 8/17850 9/16800 10/15750 11/14785 12/13897 13/13083 14/12341 15/11665 16/11053 17/10500 18/10002 19/9551 20/9135 21/8746 22/8382 23/8043 24/7727 25/7435 26/7165 27/6917 28/6691 29/6485 30/6300 31/6134 32/5986 33/5853 34/5733 35/5623 36/5521 37/5424 38/5331 39/5239 40/5145 41/5048 42/4949 43/4848 44/4746 45/4646 46/4548 47/4453 48/4363 49/4278 50/4200 51/4130 52/4066 53/4009 54/3956 55/3906 56/3860 57/3814 58/3769 59/3723 60/3675 61/3624 62/3571 63/3517 64/3461 65/3405 66/3350 67/3297 68/3245 69/3196 70/3150 71/3108 72/3070 73/3035 74/3003 75/2973 76/2944 77/2917 78/2890 79/2863 80/2835 81/2806 82/2777 83/2747 84/2716 85/2684 86/2652 87/2619 88/2586 89/2553 90/2520 91/2487 92/2454 93/2421 94/2388 95/2356 96/2324 97/2293 98/2263 99/2234 100/2205 101/2178 Fonte: o autor.
79 Para calcular o valor real de concentração de NH³, após efetuar a leitura das tensões do circuito de condicionamento de sinal e calcular a impedância do sensor através da lei de Ohm, o sistema então compara com este os valores armazenados no vetor, e a posição do vetor onde o valor mais próximo ao medido é encontrado, equivale ao valor real da concentração do gás no ambiente. 4.2.2 Contexto do Projeto A fim de documentar e organizar o desenvolvimento de hardware do J.SISMAAG, definiu-se o escopo do projeto através do diagrama de blocos da SysML. O diagrama 13 ilustra o contexto do projeto de hardware, envolvendo o Módulo Dispositivo e o Módulo GSM. Diagrama 13 - Contexto do Projeto do Dispositivo. Fonte: o autor. O diagrama de blocos foi desenvolvido com a ferramenta Astah SysML, na versão Trial, disponível para testes em até 30 dias após sua instalação. Esta etapa foi de extrema importância, pois assim pode-se saber o escopo e limites do projeto. Aos limites da cor vermelho está à representação do Módulo Slave (Dispositivo), o qual foi disponibilizado pela empresa Altem com autorização para realizar as alterações necessárias, como desenvolver o circuito de condicionamento de sinal, aquisição e processamento dos dados e atender aos requisitos do projeto. E aos limites da cor azul, está a representação do Módulo Master (GSM), o qual foi disponibilizado pela empresa como sendo um produto. A empresa também disponibilizou o manual de usuário, para então desenvolver o sistema embarcado do mesmo.
80 A seguir encontra-se a etapa de desenvolvimento dos requisitos funcionais do sistema embarcado do Módulo Slave (Dispositivo) e Módulo Master (GSM). 4.2.3 Requisitos Funcionais A etapa de levantamento de requisitos do projeto é representada na forma gráfica, através do diagrama de requisitos funcionais da SysML, sendo que cada requisito possui duas propriedades básicas, um identificador (id) e um texto (text) com a descrição do mesmo. Os requisitos funcionais são derivados de um requisito base, representando as funcionalidades do sistema. O elemento rationale é utilizado para anotação, descrevendo o nível do risco que o sistema estará exposto para cada requisito. Para melhor entendimento, elaborou-se o diagrama de requisitos funcionais de cada Módulo separadamente. No diagrama 14 são apresentados os requisitos funcionais do dispositivo de aquisição e processamento dos dados (Módulo Slave). O primeiro requisito desenhado é o sistema embarcado em si, em seguida encontram-se os requisitos derivados dele, como, inicialização dos componentes envolvidos, gerenciamento de leitura dos dados e comunicação com GSM e visualização dos dados local, através de um LCD. Diagrama 14 - Requisitos Funcionais do Projeto do Dispositivo. Fonte: o autor.
81 Para a elaboração dos requisitos do Módulo Master (GSM), foram seguidos os mesmos padrões utilizados para o Dispositivo. Diagrama 15 - Requisitos Funcionais do Projeto do GSM. Fonte: o autor. Do mesmo modo que no diagrama de contexto, o diagrama de requisitos funcionais também foi desenvolvido com a ferramenta Astah SysML. Com a elaboração dele, o entendimento funcional dos sistemas embarcados do projeto se tornam fácil, pois o diagrama possibilitou uma modelagem da estrutura e comportamentos dos softwares embarcados.
82 4.2.4 Modelagem dos Processos Com o objetivo de detalhar todos os processos executados pelo software embarcado de cada módulo é desenvolvida a modelagem dos processos utilizando a notação gráfica BPMN. O fluxograma 1 apresenta o processo de gerenciamento do projeto de hardware e interfaceamento. Ele está dividido em dois controladores, gerenciamento do Dispositivo e gerenciamento do GSM, representando separadamente os processos executados em cada módulo. Fluxograma 1 - Processo Gerenciamento de Hardware e Interfaceamento. Fonte: o autor. No processo ilustrado acima, pode-se visualizar que em cada controlador existe dois elementos, inicio (verde) e fim (vermelho), e um subprocesso onde existem diversas tarefas a serem cumpridas. O fluxograma 2 apresenta o subprocesso a ser executado no sistema embarcado do Módulo Slave (Dispositivo). Fluxograma 2 - Subprocesso Gerenciamento do Dispositivo. Fonte: o autor.
83 Visualizando o fluxograma 2, pode-se observar que primeiramente o sistema deverá executar as tarefas de inicialização e configuração de alguns componentes do microcontrolador utilizados no processo, como, watchdog, timers, GPIO’s, UART e ADC. Em seguida, o contador do ciclo de funcionamento do sensor deverá estar igual ou acima de 250 milissegundos para então poder realizar os processos de aquisição dos dados. Para melhor entendimento do processo de gerenciamento do Dispositivo, optou-se por dividi-lo em mais quatro subprocessos, são eles: configurar pinos do sensor, configurar pinos de comunicação com GSM, solicitar leitura do sensor e tratar pacotes. Os próximos quatro fluxogramas apresentam as tarefas dos subprocessos mencionados. Os pinos responsáveis por drenar ou cessar corrente ao circuito que “alimenta” o sensor são o 28 e 29 do PORT 1. Eles devem estar definidos como sendo saída em modo open-drain, para evitar queimar os pinos do uC, ver item 4.2.1, e inicialmente devem estar em nível lógico alto, ou seja, em modo cessar drenar corrente, como ilustra o fluxograma 3. Fluxograma 3 - Subprocesso Configurar Pinos do Sensor. Fonte: o autor. Para o processo de comunicação com o Módulo Master via RS-485 primeiramente os pinos do uC conectados ao RX e TX do transceiver 485 deverão estar definidos como sendo saída. O próximo passo é verificar o buffer da UART e esperar a transmissão de dados, em seguida habilitar TX e desabilitar RX, pois esta configuração deixa o Dispositivo em modo de recepção, aguardando o pedido do mestre, o Módulo Master (GSM). Fluxograma 4 - Subprocesso Configurar Pinos de Comunicação com GSM. Fonte: o autor. O fluxograma 5 apresenta as tarefas executadas no subprocesso de leitura das tensões no circuito de condicionamento de sinal. Atendendo ao requisito de funcionamento do sensor,
84 primeiramente o sistema zera o contador e drena corrente para Vh. Espera 2 milissegundos e drena corrente pra Vc. Espera 6 milissegundos e efetua a leitura das tensões, pois este é o ponto ideal de detecção. Por fim, no tempo estabelecido pelo fabricante no datasheet do sensor, cessa o drenar corrente pra Vh e Vc. O fluxograma 05 ilustra esse subprocesso. Fluxograma 5 - Subprocesso Solicitar Leitura do Sensor. Fonte: o autor. O último subprocesso a ser especificado no Dispositivo contém tarefas que devem ser realizadas para comunicar e enviar os dados necessários ao GSM. As execuções das tarefas levam em consideração um controle de fluxo de dados, controle de erros de transmissão e seguem o protocolo de comunicação definido no item 2.6.3.1.1. Fluxograma 6 - Subprocesso Tratar Pacotes. Fonte: o autor. A partir do fluxograma 7 é apresentado o subprocesso a ser executado no sistema embarcado do Módulo Master (GSM). As tarefas a serem executadas nele são mais complexas do que no Dispositivo, pois além das tarefas de inicialização dos componentes e de comunicação com o Dispositivo, o microcontrolador deve se comunicar via interface UART
85 controlando o motor20 GSM/GPRS SIM900. Desta maneira, o subprocesso de gerenciamento do Módulo Master (GSM) contém dez subprocessos que estão detalhados separadamente. Fluxograma 7 - Subprocesso Gerenciamento do GSM. Fonte: o autor. O subprocesso configurar pinos de comunicação com dispositivo é igual ao subprocesso ilustrado no fluxograma 3 apresentado anteriormente, porém deve-se dar atenção às configurações do uC na placa, pois os pinos do microcontrolador ligados ao TX e RX do transceiver 485 não são os mesmos do Dispositivo. O fluxograma 8 ilustrado a seguir define as tarefas de configuração dos pinos do uC conectados ao SIM900. São eles pinos de DCD, POWER e RESET. Da maneira estabelecida no fluxograma, inicialmente o SIM900 permanece desligado. Fluxograma 8 - Subprocesso Configurar Pinos de Comunicação com SIM900. Fonte: o autor. 20 Termo referido ao controle de serviços executados pelo modulo GSM/GPRS SIM900 abordado no projeto. (O AUTOR).
86 O fluxograma 9 ilustra as tarefas que o sistema embarcado do GSM deve executar para buscar um Dispositivo conectado ao barramento RS-485. O sistema deve definir um ID para o dispositivo iniciando em zero, e incrementando este valor até encontrá-lo. Também deve ser definido um valor para comando de HANDSHAKE, pois é verificando este comando que o Dispositivo retorna dados de confirmação (0x6F e 0x6B, correspondentes a “o” e “k” na tabela ASC II). Antes de armazenar o ID do Dispositivo encontrado, o sistema também realiza uma verificação desses valores no buffer da UART. Fluxograma 9 - Subprocesso Buscar Dispositivos no Barramento RS-485. Fonte: o autor. Um processo muito importante a ser executado é o de verificar o valor de créditos do chip, pois este fator é crucial ao correto funcionamento do J.SISMAAG, se estiver R$0,00 simplesmente o SIM900 não se comunica com a Aplicação Web de Monitoramento. As tarefas são básicas, o sistema envia um comando ao SIM900 solicitando este valor, verifica o retorno, se igual ao especificado, a solicitação foi registrada pelo SIM900, então armazena temporariamente o valor de créditos. O fluxograma 10 ilustra este subprocesso. Fluxograma 10 - Subprocesso Solicitar Créditos. Fonte: o autor. Os subprocessos dos fluxogramas 11 e 12 a seguir devem ser executados toda vez em que haver a necessidade de enviar alguma informação para a Aplicação Web de Monitoramento.
87 Fluxograma 11 - Subprocesso Abrir Conexão com Servidor. Fonte: o autor. Após executado o processo para abrir conexão com servidor, e o mesmo ter retornado sucesso, o sistema deve então enviar os dados desejados, dados estes, que podem ser de valor em créditos pré-pago do chip do SIM900 utilizado, ou de valor de concentração de NH³ medido pelo Dispositivo no momento. Tanto pra um como pra outro o processo é o mesmo, pois o que difere um de outro é o pacote de dados a ser enviado. Fluxograma 12 - Subprocesso Enviar Dados p/ Servidor. Fonte: o autor. Com o objetivo de obter o momento preciso em que o sistema registra o valor de concentração de NH³ do ambiente, o mesmo deve buscar a data e hora no servidor NTP do observatório nacional e armazenar os valores para então enviá-los junto ao valor concentração de NH³, a Aplicação Web de Monitoramento. O fluxograma 13 apresenta todas as tarefas a serem executadas para atender a este processo. Fluxograma 13 - Subprocesso Atualizar Data e Hora. Fonte: o autor. Outro requisito a ser atendido pelo GSM é o de verificar o valor de CSQ (nível do sinal) estabelecido no local em que os módulos estão implantados. O fluxograma 14 ilustra esse subprocesso. Primeiramente o sistema embarcado do GSM deve solicitar ao SIM900 o
88 serviço definido, verificar sua resposta. Se o buffer da UART for maior que sete bytes, o valor foi recebido com sucesso, então deve armazena o valor para enviá-lo a Aplicação Web de Monitoramento. Fluxograma 14 - Subprocesso Solicitar CSQ. Fonte: o autor. No fluxograma 15 é ilustrado o subprocesso em que o sistema embarcado do GSM solicita a concentração de NH³ ao Dispositivo de aquisição e processamento dos dados. Este, segue o mesmo padrão do subprocesso buscar dispositivo no barramento RS-485, com a diferença de que o ID do Dispositivo já deve estar armazenado, assim basta apenas repassar seu ID e o comando de LERNH3 e posteriormente verificar o retorno e, se todas as condições estabelecidas forem atendidas, armazenar a concentração de NH³ recebida para posteriormente enviá-la para a Aplicação Web de Monitoramento. Fluxograma 15 - Subprocesso Solicitar Concentração de NH³ via RS-485. Fonte: o autor. O último subprocesso a ser executado pelo sistema embarcado do GSM é o de enviar um SMS para o número especificado se a concentração de NH³ estiver igual ou acima de 50 ppm, avisando o usuário cliente que o valor está no limite. Essa decisão foi tomada pelo fato de no momento em que essa situação ocorrer, ele não esteja online. Partindo do mesmo princípio de comunicação com o SIM900, o sistema deve enviar um comando a ele solicitando o serviço de envio de dados via SMS. Se atendido a todas as condições estabelecidas retorna sucesso, caso contrário retorna erro.
89 Fluxograma 16 - Subprocesso Envia SMS de Aviso p/ Celular do Cliente. Fonte: o autor. Os tópicos 4.2.5 e 4.2.6 a seguir apresentam a implementação dos principais processos executados pelos firmwares do sistema embarcado do Dispositivo e GSM. Tanto pra um como pra outro, os projetos foram criados na IDE keil uVision 4 em linguagem de programação C. 4.2.5 Sistema Embarcado do Dispositivo Para o sistema embarcado do Dispositivo o projeto criado é denominado de “Amonia” e está estruturado em arquivos separados por três pastas, sendo elas: “Startup”, “Headers” e “Sources”. A pasta “Startup” é definida por defaut pela IDE de desenvolvimento ao criar o projeto. Nela contem dois arquivos com extensões:  .s: arquivo de inicialização do dispositivo de núcleo Cortex-M3 para série NXP LPC17xx utilizada no projeto. A ARM Limited fornece o software para o uso dos processadores baseados em Cortex-M. Ele é distribuído livremente dentro da ferramenta de desenvolvimento, a Keil uVision, que apoia o uso dos processadores baseados em ARM;  .c: arquivo fonte do sistema do dispositivo para a série NXP LPC17xx que contém definições do sistema, como configuração de clock e registradores. Também é um arquivo disponibilizado pela ARM Limited; A pasta “Headers” contem os arquivos com extensão .h, onde existe um arquivo para cada função a ser executada, como por exemplo, um arquivo para utilização do módulo ADC, outro para configuração de GPIO, entre outros. Nestes arquivos são definidas macros, protótipos de funções e variáveis globais. Para cada arquivo criado com extensão .h, existe outro arquivo com o mesmo nome, porém com extensão .c, estes estão localizados dentro da
90 pasta “Sources” e são responsáveis por utilizar as macros, variáveis e implementar as funções definidas nos “Headers”. Na pasta “Sources”, além dos arquivos com o mesmo nome dos de extensão .h, existe outro denominado de main.c, este responsável pela inicialização do sistema (utilizado as funções definidas em “Startup”) e execução da rotina principal do programa utilizando das funções definidas nos outros arquivos “Sources”. A seguir serão apresentados os códigos das principais funções executadas pelo sistema embarcado do Dispositivo. No quadro 16 pode-se visualizar o código do subprocesso configurar pinos do sensor do Dispositivo que está especificado no fluxograma 03. Quadro 16 - Configuração Inicial dos Pinos Responsáveis por Controlar a Corrente Elétrica no sensor. Fonte: o autor. O código apresentado no quadro 17 ilustra o processo executado para ler as tensões dos dois pinos utilizados do módulo ADC do microcontrolador presente no Módulo Slave (Dispositivo). Quadro 17 - Função Responsável pela Aquisição do Sinal. Fonte: o autor. Nota-se que a leitura é realizada duas vezes. Isso se dá pelo fato de se obter uma maior precisão na medição. O quadro 18 ilustra o código da função responsável por calcular o valor de real de concentração de NH³. Após calcular o valor medido pelo sensor (resistência), a função realiza
91 a conversão deste valor para o valor real da concentração com base nos valores ilustrados no quadro 15, valores estes, que no código fonte são armazenados em um vetor de 102 posições, onde cada posição do vetor armazena a respectiva resistência. Dessa forma, a função encontra a posição correspondente ao valor de leitura do sensor e a retorna. O valor retornado é então a concentração de NH³ em ppm (partícula por milhão). Quadro 18 - Função Responsável por Realizar a Conversão em ppm. Fonte: o autor. O quadro 19 representa o código da rotina principal do programa, onde a cada iteração, o sistema executa o processo de alimentar Whatchdog timer, ler tensões do circuito de condicionamento de sinal, calcular impedância (resistência do sensor), calcular o valor real de concentração de NH3, comunicar com GSM através da função trata_pacotes e então atualizar o LCD. Quadro 19 - Rotina Principal do Sistema Embarcado Dispositivo e Método Trata_pacotes(). Fonte: o autor.
92 O item 4.2.6 finaliza a etapa de desenvolvimento do J.SISMAAG. Nele é apresentado o código das principais funções executadas pelo GSM. 4.2.6 Sistema Embarcado do GSM Para o sistema embarcado do GSM o projeto criado no Keil uVision 4 é denominado de “Telemetria_GSMLPC1751” e, igual ao projeto do Dispositivo, está estruturado em arquivos separados por três pastas, sendo elas: “Startup”, “Headers” e “Sources”, seguindo o mesmo padrão de projeto. Após os processos de inicialização e configuração das UART’s e configuração dos pinos da interface RS-485 e pinos de comunicação com SIM900 é executado o processo para buscar dispositivos no barramento RS-485, ilustrado no fluxograma 9. O quadro 20 apresenta o código desenvolvido para a realização deste processo. Quadro 20 - Função Responsável por Buscar Dispositivos no Barramento RS-485. Fonte: o autor. Armazenado os endereços dos dispositivos encontrados, o sistema embarcado realiza então os processos de comunicação com o módulo SIM900. Para comunicar, foram desenvolvidos dois métodos: Sim900_send_cmd(cmd, timeout), onde deve-se repassar por parâmetro o comando “AT” para solicitar o serviço desejado e um tempo de retorno, e UART_receiving_wait(porta, timeout), onde deve-se repassar por parâmetro a porta da UART e um tempo de resposta, para então verificar o tamanho do buffer e saber qual a resposta do SIM900 ao serviço solicitado. Os códigos das duas funções descritas estão apresentados no quadro 21.
93 Quadro 21 - Funções de Comunicação com SIM900. Fonte: o autor. Os comandos “AT” utilizados para atender a todos os requisitos de comunicação com o SIM900 estão disponíveis em anexos. Primeiramente, através do método Sim900_warm_up, o sistema liga automaticamente o SIM900, verifica o nível do sinal e então define o tipo de acesso a rede. Em seguida, solicita os créditos do chip de telefonia celular utilizado e então inicializa a conexão PDP (Packet Data Protocol) a fim de obter um endereço para se conectar a rede IP. Conectado a rede, o próximo passo e conectar com o servidor onde está a Aplicação Web de Monitoramento e então enviar o valor de créditos para armazenamento. No quadro 22 é apresentado o código da rotina principal do sistema embarcado do GSM. Na rotina principal a lógica estabelecida é de que o sistema deve primeiramente atualizar a data e hora. Esse processo é executado solicitando o serviço de conexão do SIM900 ao servidor do Observatório Nacional através do domínio “a.ntp.br”, onde o mesmo retorna ao sistema embarcado os valores de data e hora atualizados. Em seguida, solicita o CSQ (nível do sinal) novamente e, dentro de um laço de repetição, executa os mesmos processos para todos os dispositivos encontrados no barramento RS-485 anteriormente. Para cada Dispositivo encontrado o sistema embarcado faz uma verificação ao solicitar a concentração de NH³ atual, se não haver erro na leitura armazena o valor, caso contrário armazena um erro e então envia os dados para a Aplicação Web de Monitoramento. O processo para “alimentar” o Whatchdog Timer só é executado caso o sistema envie os dados para o servidor, caso contrário o contador irá “estourar” seu tempo limite e o sistema embarcado irá reiniciar.
94 Quadro 22 - Rotina Principal do Sistema Embarcado GSM. Fonte: o autor.
95 O último processo executado pelo sistema embarcado do GSM é o de verificar qual é o valor da concentração de NH³ medido pelo Dispositivo. Neste caso, se este valor chegar a 25 ppm, o sistema imediatamente deve enviar uma mensagem ao número de celular cadastrado, avisando o usuário sobre a situação. Deve-se ressaltar que o valor limite atribuído para o sistema enviar aviso por SMS é diferente para cada situação, como, idade do lote e cama de frango. Todos os processos citados são executados a um intervalo de tempo de aproximadamente 30 segundos, dependendo do tempo de resposta do SIM900 a cada serviço solicitado, e o programa também realiza a verificação dos Dispositivos no barramento RS-485 a cada 10 minutos.
96 5 RESULTADOS O sistema desenvolvido foi implementado gerando resultados satisfatórios. Como já mencionado, a aplicação básica para testes foi o monitoramento do gás amônia, com aquisição de dados em intervalos de 250 milissegundos e envio dos dados para visualização na internet e, caso necessário no celular, em intervalos de 10 segundos. Este capítulo tem por objetivo apresentar os resultados obtidos nas fases de testes em laboratório e análise do monitoramento dos dados medidos em campo. Primeiramente realizou-se testes de aquisição e processamento dos dados e comunicação entre os Módulos GSM e Dispositivo e Aplicação Web de Monitoramento, em laboratório. Em seguida, o trabalho foi conduzido então ao processo de monitoramento dos dados com os módulos atuando diretamente no aviário. 5.1 AQUISIÇÃO E PROCESSAMENTO DOS DADOS Para a realização dos testes de aquisição e processamento do sinal, foi verificada a concentração de gás amônia através de um medidor portátil Gas Alert NH³, devidamente calibrado, em um ambiente fechado, especificamente uma caixa contendo uma solução de amoníaco 10% misturada em água, e o valor constatado no medidor, em paralelo, foi comparado com o valor obtido do dispositivo, como ilustra a fotografia 6. Fotografia 6 - Testes Gás Alert NH3 e Dispositivo. Fonte: o autor. Deve-se lembrar que o sistema permite uma visualização local dos dados obtidos através de um LCD. Foi verificado que o valor da concentração registrado no dispositivo aumentou gradativamente ao perceber a presença de NH³ no ambiente tendo um tempo de
97 resposta muito rápido, menos de 3 segundos, inicialmente, não correspondendo ao valor constatado no medidor que tem um tempo de resposta mais lento, em torno de 8 segundos. Logo após a estabilização dos valores, pode-se constatar então que eles estavam tendendo a se igualar, tendo uma pequena variação da referencia (medidor portátil) para o dispositivo desenvolvido, variando de 3 – 5 ppm. Segundo dados do fabricante do sensor, essa diferença deve ser considerada, pois, para determinado valor em ppm e temperatura ambiente, o sinal do sensor varia. O gráfico 2 ilustra esta situação, onde para 10 ppm, num intervalo de 3 a 9 minutos, o sensor assume valores diferentes. Gráfico 2 - Sensor Response Pattern. Fonte: Figaro Engineering Inc., 2010. O processo de aferição do Dispositivo foi executado por um período de 5 dias onde os valores foram comparados, visualizando o LCD e Medidor Portátil, constantemente. Chegou- se a conclusão de que o funcionamento do sensor no sistema embarcado do Dispositivo está correto, pois na mudança de ar limpo para concentração de gás amônia no ambiente e no processo contrário, o padrão de resposta obtido seguiu o padrão de resposta típico do sensor, definição esta dada pelo fabricante, sendo assim, pode-se dizer que a aferição foi bem sucedida. 5.2 COMUNICAÇÃO ENTRE DISPOSITIVO E GSM Os drivers RS-485, responsáveis por realizar a troca de informações entre os módulos, se comunicam com os microcontroladores através da interface UART. Na etapa de testes de comunicação entre os módulos foi utilizado o modo Debugger da keil uVision 4, que possibilita ao programador uma visualização detalhada dos processos executados pelo programa, para poder observar o fluxo de dados no buffer das UART’s. Foram dois os
98 problemas encontrados para serem resolvidos, obter sucesso nessa comunicação e transmitir os dados sem perda de informação. Como a troca de informações é constante, há a necessidade de zerar o buffer após cada envio de dados. Mas isso não foi o suficiente, pois nem sempre o Dispositivo irá responder a uma requisição do GSM e quando isso ocorre o buffer da UART do Dispositivo ainda permanece com dados, prejudicando assim a leitura na próxima requisição solicitada pelo GSM. A solução encontrada foi a de, dentro do método que gera a interrupção da UART, implementar uma lógica para verificar o primeiro byte e o tamanho do pacote recebido. Se os valores não forem iguais ao esperado o sistema deve limpar o buffer. A grosso modo, o sistema embarcado do Dispositivo deve ler o buffer, limpá-lo antes de verificar se há a necessidade de retornar dados e, se retornar, limpá-lo novamente. No segundo problema encontrado, a variável que armazena o valor da concentração de NH³ é do tipo short, ou seja, ocupa 2 bytes no buffer pois armazena números inteiros de 16 bits. Seria impossível enviar esse valor no Dispositivo e recuperá-lo depois no GSM sem erro, certamente o valor recebido seria diferente do enviado. Esse problema foi solucionado realizando operações de deslocamento e lógica de bits, assim, no Dispositivo o número inteiro de 16 bits se tornou dois de 8 bits para ser enviado, e no GSM os dois números de 8 bits se tornaram novamente um de 16 bits para ser armazenado sem diferença de valores. Quadro 23 - Operações de Deslocamento e Lógica de Bits na Variável NH³. Fonte: o autor. Também foi observado que o tipo da variável que armazena o valor de concentração NH³ deve ser igual tanto no Dispositivo como no GSM, caso contrário o erro permaneceria. 5.3 COMUNICAÇÃO ENTRE GSM E APLICAÇÃO WEB DE MONITORAMENTO Como visto anteriormente, o sistema embarcado do GSM solicita os serviços desejados ao SIM900 enviando comandos “AT” e ele responde a essa solicitação, isso através da interface UART. O procedimento adotado para verificar se o SIM900 estava atendendo aos serviços solicitados foi o mesmo utilizado no item 5.2, modo Debugger, procedimento este, que possibilitou observar o fluxo de dados no buffer da UART.
99 A conexão de dados entre o SIM900 e o servidor é realizada por meio de uma rede IP externo, necessário para o serviço utilizado, que é o de acesso à internet. Para isso utilizou-se do recurso Virtual Server (Servidor Virtual), disponível no roteador da empresa Altem, que permite aos usuários e tecnologias de comunicação, como GPRS, ter acesso a serviços da rede local do próprio usuário. No Servidor Virtual é que a Aplicação Web de Monitoramento ficou armazenada, para tal feito houve a necessidade de acessar a página de configuração do roteador da empresa Altem, ver apêndices, onde definiu-se uma porta pública do roteador para redirecionar para uma porta privada específica e um endereço IP da rede local (IP do computador onde o servidor TCP e Apache Tomcat são executados), para duas regras definidas. A primeira é definida para comunicação via protocolo TCP com o SIM900, onde a porta 4550 do equipamento é redirecionada para tal. E a segunda é definida para comunicação via protocolo HTTP com o usuário, onde a porta 80 do equipamento é redirecionada para tal. Com o Servidor Virtual pronto para uso, iniciou-se os testes de conexão com o SIM900. Nesta etapa tudo funcionou perfeitamente, pois antes, realizou-se a verificação de todas as respostas aos serviços solicitados para atender aos requisitos de gerenciamento de comunicação com o SIM900, apresentado no Diagrama 15. Deve-se ressaltar que ao solicitar qualquer serviço ao SIM900 um tempo de resposta deve ser respeitado, dependendo do serviço, e esse tempo foi determinado observando o fluxo de dados no buffer na UART. Concluído a fase de testes em laboratório, iniciou-se as atividades para a realização da análise do monitoramento dos dados em campo. 5.4 ANÁLISE DO MONITORAMENTO DOS DADOS MEDIDOS EM CAMPO Um dos requisitos básicos para operação do sistema desenvolvido é que o aviário onde os módulos serão instalados deve estar localizado em uma área de abrangência de uma operadora de telefonia celular. Para o projeto em questão, o serviço GSM/GPRS foi contratado sob o formato pré-pago da empresa CLARO. Para os módulos poderem atuar no aviário sem qualquer tipo de dano físico houve a necessidade de acomoda-los em uma caixa plástica com tampa, deixando-os livres de qualquer contato com o ambiente. Em virtude disso, o sensor passou a ser conectado ao módulo Dispositivo por meio de um cabo, ficando a 2 metros de distância da mesma, com quatro conexões, Vh, Vc, GND Vh e GND Vc e, uma conexão para blindagem, GND, a fim
100 de evitar interferências no processo de medição. A fotografia 7 ilustra os módulos acomodados dentro da caixa pronta para ser fechada e levada ao aviário. Fotografia 7 - Caixa com os Módulos Dispositivo e GSM. Fonte: o autor. O aviário, onde foram instalados os módulos para a realização desta etapa do trabalho, está localizado a aproximadamente 7500 metros de distância da cidade de Luzerna. A cama de frango atual dele é reutilizada (está no quarto lote de frangos). No aviário, a caixa com os módulos pôde ser fixada na parede e o sensor em um ponto estratégico, em torno de 60 centímetros de altura em relação à cama do frango. Na primeira tentativa de telemetria o processo falhou, pois no local o CSQ (nível do sinal) da operadora CLARO varia de 5-8 dBm e o valor mínimo para o processo de telemetria funcionar perfeitamente é 10 dBm. Com o objetivo de melhorar o sinal, a solução foi verificar a melhor posição e instalar uma antena externa. Ela ficou a aproximadamente 5 metros de altura em relação ao solo, ajustando o nível do sinal para 11 dBm. A fotografia 8 ilustra a parte interna do aviário com os módulos e sensor instalados e a parte externa onde foi posicionada e fixada a antena. Fotografia 8 - Módulos Instalados no Aviário. Fonte: o autor.
101 O sistema pôde ser testado com os módulos atuando no aviário por cinco dias. Nesse intervalo de dias apresentou desempenho que superou as expectativas, pois todos os critérios estabelecidos no desenvolvimento do mesmo foram atendidos. A figura 11 apresenta os registros de concentração de NH³ no aviário medidos de ‘31-10-2014’ a ’04-11-2014’. Figura 11 - Dados de Concentração de NH³ Medidos no Aviário. Fonte: o autor. Como mencionado no item 2.3, nos ambientes produtivos de frangos de corte os limites aceitáveis de concentração de NH³ a partir da quarta semana não podem exceder o valor de 50 ppm. Desta forma, o limite de concentração de NH³ estabelecido no sistema foi de 45 ppm, devido a margem de erro a ser considerada no processo de medição, que é de 5 %. Ao se igualar a este valor, o mesmo deve enviar um SMS ao responsável pela manutenção do aviário avisando-o da situação atual de gás amônia no ambiente, para então ele poder tomar as medidas de controle necessárias. Fotografia 9 - SMS de Aviso. Fonte: o autor. Como exemplo, pode-se visualizar na fotografia 9 que o sistema enviou automaticamente um SMS de aviso para o número de celular cadastrado ao medir 50 ppm para o valor da concentração de NH³ no ambiente.
102 6 CONCLUSÃO O presente trabalho tem como contribuições finais o monitoramento do gás amônia em aviários, de forma a observar sua concentração em tempo real e as variações com o passar do tempo, armazenando os dados digitais obtidos, possibilitando ao integrado adotar medidas de controle em tempo hábil. A fim de fornecer os dados que alimentarão o sistema de gerência, a realização da leitura e armazenamento dos dados se dá de forma automática com a integração software- hardware proposta. Essa integração, principal parte a ser estudada uma vez que a aplicação web a ser desenvolvida irá trabalhar em cima dos dados obtidos. Por motivos favoráveis ao projeto e ao usuário do sistema, como, ser um sistema de cobertura global, de conectividade instantânea, transmissão de dados segura e em alta velocidade, menor custo e compatibilidade, optou-se por utilizar a tecnologia GSM/GPRS que é um tipo de comunicação sem fio. Observando os documentos de especificação de requisitos elaborados neste trabalho, pode-se então dar inicio a implementação e testes do sistema. O que determinou a escolha dos componentes de hardware junto à empresa Altem Tecnologia foi o fator aplicabilidade aliado a qualidade, funcionalidade e eficiência. Este trabalho vem ao encontro dos objetivos do curso de Engenharia de Computação, que visa capacitar profissionais para atuar em processos de automação, integrando aspectos relacionados ao desenvolvimento e gerência de projetos de hardware e software, colaborando de forma decisiva em vários campos onde se aplicam esses processos. 6.1 SUGESTÕES DE TRABALHOS FUTUROS Como ações em potenciais, para trabalhos futuros pode-se apontar o aprimoramento deste trabalho com a adição de mais sensores ao processo de aquisição de dados, no mínimo três espalhados em pontos estratégicos dentro do aviário. Esse processo poderia ser feito utilizando o sistema 1-Wire, onde possibilita a comunicação digital entre um controlador e dispositivos da série 1-Wire, tais como os sensores, seguindo o padrão mestre escravo. Dessa maneira a informação se torna mais precisa, pois dentro dos aviários a concentração de NH³ varia de um ponto para outro em função da ventilação e variáveis ambientais como temperatura e umidade.
103 Outro fator importante a ser mencionado é referente ao sinal de telefonia celular no local onde o sistema desenvolvido possa ser implantado. Como mencionado, o processo de telemetria só funciona se existir um sinal acima ou igual a 10 dBm, e os aviários normalmente estão localizados fora do perímetro urbano onde muitas vezes o sinal é ruim (menos de 10 dBm) ou até nem existe (0 dBm) e nem sempre esse problema é solucionado com apenas a instalação de uma antena externa. A fim de obter uma boa qualidade no sinal de telefonia celular nesses locais, pode-se instalar um repetidor de sinal. Para isso, o melhor posicionamento da antena externa, de preferências no ponto mais alto do terreno, aumenta a captação do sinal que é amplificado e distribuído pela antena interna garantindo qualidade na comunicação via SMS e conexão com a internet. Atualmente existem, no mercado, repetidores que distribuem sinal para vários aparelhos ao mesmo tempo em uma área de até 2000 m² com um custo médio de instalação de R$1.000,00. A solução definida para no caso de ocorrer uma perda de comunicação do SIM900 com o servidor seria a de acoplar um slot para cartão micro SD no módulo Dispositivo e implementar uma lógica no sistema embarcado para quando esta situação ocorrer, o sistema armazenar os dados e envia-los para a Aplicação Web de Monitoramento quando o sinal se estabilizar. Este sistema de monitoramento também poderia ser integrado a um sistema de controle automatizado, facilitando ao integrado todo o processo de manutenção no aviário e uma base de dados mais detalhada, com armazenamento de, por exemplo, ganho de peso do frango em função da concentração de NH³ e temperatura ambiente.
104 REFERÊNCIAS ARC Eletronics. RS422 Balanced Differential Drivers 2000. Disponível em: <http://www. arcelect.com/rs422.htm>. Acesso em 28 ago. 2014. BALIEIRO, F. A. H. Loja Virtual Utilizando Interface WEB/SMS. 2008. Monografia – Universidade Federal do Rio de Janeiro - Escola Politécnica Departamento de Eletrônica e Computação, UFRJ, Rio de Janeiro, 2008. Disponível em: <http://monografias.poli.ufrj. br/monografias/monopoli10003133.pdf>. Acesso em 02 out. 2014. BAPTISTA, Manuel. Sistemas de Instrumentação. 2005. Trabalho científico apresentado ao Departamento de Informática, curso de Engenharia de Sistemas e Informática da Escola Superior de tecnologia de Viseu. Disponível em: <http://www.estgv.ipv.pt/paginaspessoais /maeb/im/Teorica_Bibliografia/Cap_E_Sistemas%20de%20Aquisi%C3%A7%C3%A3o%20d e%20Dados/1-Introdu%C3%A7%C3%A3o /Texto%20de%20Estudo%20%20Sistemas %20de%20Instrumenta%C3%A7%C3%A3o%20-%20Capitulo%204.pdf> Acesso em: 13 out. 2014. BUCHMANN, M. Rafael; DA SILVA S. Bruno; PEREIRA C. Maurício. Padrões de Comunicação Serial Clássicos: RS-232, RS-422 e RS-485. 2013. Trabalho Instrumentação e Técnicas de Medidas – Universidade Federal do Rio de Janeiro – Escola Politécnica. Disponível em: <http://www.peb.ufrj.br/cursos/eel710/ProtocoloRS.pdf> Acesso em: 25 abr. 2014. CAELUM. Introdução ao JSF e Primefaces. 2006. Apostila do Curso FJ-22 – Lab. Java com Testes, JSF e Design Patterns. Disponível em: < http://www.caelum.com.br/apostila- java-testes-jsf-web-services-design-patterns/introducao-ao-jsf-e-primefaces/>. Acesso em 13 out. 2014. CENTRAL DE INTELIGÊNCIA DE AVES E SUÍNOS (CIAS). A Avicultura no Brasil. Concórdia, 2010. Disponível em: <http://www.cnpsa.embrapa.br/cias/index.php?option=com _content&view=article&id=13&Itemid=15> Acesso em: 01 out. 2014. CERVO, Amado; BERVIAN, Pedro. A pesquisa. In: CERVO, Amado; BERVIAN, Pedro. Metodologia Científica. São Paulo: Mc Graw-Hill do Brasil, 1976. p. 65-70. CORDEIRO, Jader S. T. Estudo Comparativo Entre os Frameworks de Mapeamento Objeto-Relacional Hibernate e Toplink. 2011. Monografia Apresentada ao Programa de Pós-Graduação em Desenvolvimento de Sistemas Para Web da Universidade Estadual de Maringá. Disponível em: <http://www.espweb.uem.br/site/files/tcc/2010/Jader%20dos%20 Santos%20Teles%20Cordeiro%20%20Estudo%20comparativo%20entre%20frameworks%20 de%20mapeamento%20objeto-relacional%20Hibernate%20e%20TopLink.pdf>. Acesso em: 13 out. 2014. CUNHA, Jônata Noronha. CORECHA, Josias Farias. MORAES, Marcelo C. Lima. Protótipo de um Site com a Localização dos Radares de Trânsito na Cidade de Belém. 2008. Monografia – Instituto de Ensinos Superiores da Amazônia, Curso de Engenharia da Computação, Belém, 2008. Disponível em: < http://www3.iesam-pa.edu.br/ojs/index.php/ computacao/article/viewFile/220/211 >. Acesso em: 14 nov. 2014.
105 CUNHA, Judson M. Protótipo de Rede Industrial Utilizando o Padrão Serial RS485 e Protocolo Modbus. 2000. Trabalho de conclusão de curso submetido à Universidade Regional de Blumenau para obtenção dos créditos na disciplina com nome equivalente no curso de Ciênicas da Computação – bacharelado. Disponível em: < http://dsc.inf.furb.br/ arquivos/tccs/monografias/2000-2judsonmichelcunhavf.pdf> Acesso em: 13 out. 2014. CURTIS, S.E. Environmental management in animal agriculture. Iowa: Iowa State University Press, 1983. 650 p. DANTAS, Tiago. Hardware e Software. 2008. Disponível em: <http://www.mundoed ucacao.com/informatica/hardware-software.htm>. Acesso em: 14 nov. 2014. DE ALMEIDA, José H. M. PHP com MySQL. 2012. Disponível em: < http://www.inf.ufsc .br/~fristtram/2464_php_com_mysql.pdf> Acesso em: 18 abr. 2014. DEITEL P. J.; DEITEL H. M. Ajax, Rich Internet Aplications e Desenvolvimento Web para Programadores, Pearson, 2008. DERMANN, G. Tiago; DELGADO, L. Jader; GONSALES, D. Alex; OJEDA, M. Francisco. Integração de Sensores a um módulo de Aquisição de Dados. Porto Alegre, 2013. Trabalho aceito para apresentação da 14ª mostra de pesquisa, ensino e extensão. – Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Sul. Disponível em: <http://mostra.poa.ifrs.edu.br/2013/site/arquivos/trabalhos/ trab_118.pdf > Acesso em: 14 mai. 2014. FERNANDES, F. C.; FURLANETO, A. Riscos Biológicos em Aviários. In: Rev. Bras. Med. Trab., Belo Horizonte , Vol. 2 , n. 2 , abr-jun , 2004. p. 140-152. Figaro Engineering Inc. Tentative Product Information: TGS 2444 – for the detection ammonia. 2010. Disponível em: <http://www.figaro-gas-sensor.fr/pdf/TGS2444.pdf> Acesso em: 21 abr. 2014. FONSECA, J. J. S. Metodologia da pesquisa científica. Fortaleza: UEC, 2002. Apostila. GERHARDT, T. E; SILVEIRA, D. T. Métodos de Pesquisa. Porto Alegre: editora da UFRGS, 2009. Disponível em: <ftp://ftp.sead.ufrgs.br/Publicacoes/derad005.pdf>. Acesso em: 18 ago. 2014. GUEDES, G. T. A. UML - Uma abordagem prática. São Paulo: Novatec, 2004. p319. GUIMARRÃES, Célio. Introdução a Linguagens de Marcação: HTML, XHTML, SGML, XML. São Paulo, 2005. Disponível em: <http://www.ic.unicamp.br/~celio/inf533/ docs/markup.html>. Acesso em 05 out. 2014. HOSPEDAGEM INTELIGENTE (MCO2). Os 3 servidores Web mais populares no Mundo. Disponível em: <http://www.1hospedagemdesites.com.br/os-3-servidores-web- mais-populares-do-mundo/>. Acesso em 02 out. 2013. IMALL. Icomsat. 2012. Disponível em: < http://imall.iteadstudio.com/im120417009.html >
106 Acesso em: 14 nov. 2014. KIOSKEA BRASIL. O Protocolo HTTP. 2013. Disponível em: <http://pt.kioskea.net/con tents/266-o-protocolo-http>. Acesso em 28 out. 2014. KÖCHE, José Carlos. Tipos de pesquisa. In: KÖCHE, José Carlos. Fundamentos de Metodologia Científica. 14. ed. rev. e ampl. Petrópolis: Vozes, 1997. p. 122-126. LEITE, A. GIRARDI, R. A Process for Multi-Agent Domain and Application Engineering: the Domain Analysis and Application Requirements Engineering Phases, Proceedings of the 11th International Conference on Enterprise Information Systems, Ed. INSTIIC. Milan, Italy, p. 156-161, 2009. LOBO, Fábio. O que é front-end e back-end? 2011. Disponível em: <http://fabiolobo.com .br/o-que-e-front-end-e-back-end.html> Acesso em: 14 nov. 2014. LUCKOW, Décio H; MELO, Alexandre A. Programação Java para a Web. São Paulo: Novatec Editora, 2010. MCKIE, Stewart. “Everything you wanted to know about Client/Server computing but were afraid to ask”. 1997. Disponível em: <http://www.duke.com/controller/Issues/DecJan /Clientse.htm>. Acesso em: 04 out. 2014. MIRAGLIOTTA, M.Y. Avaliação dos níveis de amônia em dois sistemas de produção de frangos de corte com ventilação e densidade diferenciados. 2000. 122 f. Dissertação (Mestrado em Construções Rurais e Ambiência) - Faculdade de Engenharia Agrícola, UNICAMP, Campinas, 2000. Disponível em: <http://www.bibliotecadigital.unicamp.br/doc ument/?code=vtls000222783>. Acesso em 01 out. 2014. NetBeans E-Commerce Tutorial. Designing Application. 2013. Disponível em: < https://netbeans.org/kb/docs/javaee/ecommerce/design.html> Acesso em: 13 jul. 2014. NETCRAFT. October 2013 Web Server Survey. 2013. Disponóvel em: <http://news. netcraft.com/>. Acesso em 04 out. 2014. NXP Semiconductors N. V. LPC 17xx Series – Product Data Sheet. 2010. Disponível em: <http://www.nxp.com/products/microcontrollers/cortex_m3/series/LPC1700.html#overview> Acesso em: 21 abr. 2014. OLIVEIRA, M. C. Efeito de dietas contendo subprodutos de arroz formuladas com base nos conceitos de proteína bruta e ideal sobre a qualidade química da cama de frango. In: Arq. Inst. Biol., v. 71, Supl., 2004. OLIVEIRA, Paulo. A. V.; MONTEIRO, Alessandra N. T. R. Emissão de Amônia na Produção de Frangos de Corte. 2013. Artigo Embrapa Suínos e Aves. Disponível em: < http://ainfo.cnptia.embrapa.br/digital/bitstream/item/91032/1/final7197.pdf>. Acesso em: 02 nov. 2014. OMG. Systems Modeling Language. 2012. Disponível em: <http://www.omg.org/spec /SysML/1.3/PDF/> Acesso em: 22 out. 2014.
107 OMG. Business Process Model & Notation. [S.l.], 2013. Disponível em: < http://www.omg. org/spec/BPMN/2.0.2/PDF/>. Acesso em: 22 out. 2014. PFLEEGER, Shari Lawrence; Engenharia de Software: Teoria e Prática. Tradução Dino Franklin. 2. ed. São Paulo: Pretience Hall, 2004.537 p. Tradução de: Software Engineering. PEREIRA, Fábio. Tecnologia ARM: microcontroladores de 32 bits. São Paulo: Érica, 2007, p.447. PRESSMAN, Roger Simon; Engenharia de Software.Tradução José Carlos Barbosa dos Santos; Pearson Makron Books, 1995. 1056p. Tradução de: Software Engineering:A Practitioner’s Approach. PROJECTS WIKI. Arquitetura Física. 2011. Disponível em: < http://ihuru.fe.up.pt/ldso /1011/doku.php?id=wikiaware:ra:fisica:intro>. Acesso em: 18 ago. 2014. REZENDE, R. Conceitos Fundamentais de Banco de Dados. 2006. Disponível em: <http://www.devmedia.com.br/conceitos-fundamentais-de-banco-de-dados/1649>. Acesso em: 03 out. 2014. ROVER, Ardinete; PEREIRA, Débora E. S. Diretrizes para Elaboração de Trabalhos Científicos: apresentação, elaboração de citações e referências de trabalhos científicos. Joaçaba: Unoesc, 2013.143p. SILVA, Bruno L. R. Sistema de Controle via SMS do Alarme Automotivo. 2012. Trabalho apresentado a banca examinadora do curso de Engenharia da Computação da FATECS – Faculdade de Tecnologia e Ciências Sociais Aplicadas – Centro Universitário de Brasília. Disponível em: <www.repositorio.uniceub.br> Acesso em: 13 out. 2014. TANENBAUM, Andrew S. Computer Networks. New Jersey, US: Prentice Hall, 2004. 891p TATEOKI, Getulio T. Monitoramento de Dados Via Internet Baseado em Telefonia Celular. 2007. Dissertação submetida à faculdade de Engenharia Ilha Solteira – UNESP como parte dos requisitos para obtenção do título de mestre em Engenharia Elétrica. Disponível em: < http://www.feis.unesp.br/Home/departamentos/engenhariaeletrica/pos- graduacao/191-dissertacao_getulio_taruo_tateoki.pdf >. Acesso em: 08 set. 2014. TORRES, Gabriel. Como o Protocolo TCP/IP Funciona. 2007. Disponível em: <http://www .clubedohardware.com.br/artigos/1351>. Acesso em 07 out. 2014. TRIVIÑOS, A. N. S. Introdução à pesquisa em ciências sociais: a pesquisa qualitativa em educação. São Paulo: Atlas, 1987. WAZLAWICK, Raul S. Análise e Projeto de Sistemas de Informação Orientados a Objetos. 2 ed. Editora Elsevier, 2011. WENDLING, Marcelo. Sensores. Guaratinguetá, 2010. Disponível em: < http://www2.feg. unesp.br/Home/PaginasPessoais/ProfMarceloWendling/4---sensores-v2.0.pdf>. Acesso em 09
108 out. 2014. ZANATTA, Rodrigo. A. Análise do Controle de Amônia em Aviários. 2007. Monografia (Pós-Graduação em Engenharia de Segurança do Trabalho) – Universidade do Extremo Sul Catarinense, UNESC, Criciúma, 2007. Disponível em: <http://www.bib.unesc.net/biblioteca /sumario/000030/000030F1.pdf>. Acesso em: 01 out. 2014. ZELENOVSKY, Ricardo; MENDONÇA, Alexandre. Hardware e Interfaceamento. Rio de Janeiro: MZ Editora Ltda, 2002. p.1031.
109 APÊNDICES
110 APÊNDICE A – SCRIPT DO MODELO FÍSICO DO BANCO DE DADOS. CREATE DATABASE IF NOT EXISTS `telemetria_amonia`; USE `telemetria_amonia`; -- MySQL dump 10.13 Distrib 5.5.16, for Win32 (x86) -- -- Host: localhost Database: telemetria_amonia -- ------------------------------------------------------ -- Server version 5.5.23 -- -- Table structure for table `modulo_gsm` -- DROP TABLE IF EXISTS `modulo_gsm`; CREATE TABLE `modulo_gsm` ( `id_gsm` int(4) NOT NULL, `nome_gsm` varchar(25) NOT NULL, `csq` int(3) DEFAULT NULL, `credito` varchar(250) DEFAULT NULL, `criado` datetime NOT NULL, `modificado` datetime DEFAULT NULL, PRIMARY KEY (`id_gsm`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; -- -- Table structure for table `dispositivo` -- DROP TABLE IF EXISTS `dispositivo`; CREATE TABLE `dispositivo` ( `id_dis` int(4) NOT NULL, `id_usu` int(4) NOT NULL, `id_gsm` int(4) NOT NULL, `nome_dis` varchar(40) NOT NULL, `conexao` datetime DEFAULT NULL, `criado` datetime NOT NULL, `modificado` datetime DEFAULT NULL, `id_gsm_id_gsm` int(11) DEFAULT NULL, `id_usu_id_usu` int(11) DEFAULT NULL, PRIMARY KEY (`id_dis`), KEY `FK22C5B091DAB784FB` (`id_gsm`), KEY `FK22C5B091CBF95AD4` (`id_usu`), KEY `FK22C5B0913DA20420` (`id_usu_id_usu`), KEY `FK22C5B091B152979D` (`id_gsm_id_gsm`), CONSTRAINT `dispositivo_ibfk_1` FOREIGN KEY (`id_usu`) REFERENCES `usuario` (`id_usu`), CONSTRAINT `dispositivo_ibfk_2` FOREIGN KEY (`id_gsm`) REFERENCES `modulo_gsm` (`id_gsm`), CONSTRAINT `FK22C5B0913DA20420` FOREIGN KEY (`id_usu_id_usu`) REFERENCES `usuario` (`id_usu`), CONSTRAINT `FK22C5B091B152979D` FOREIGN KEY (`id_gsm_id_gsm`) REFERENCES `modulo_gsm` (`id_gsm`), CONSTRAINT `FK22C5B091CBF95AD4` FOREIGN KEY (`id_usu`) REFERENCES `usuario` (`id_usu`), CONSTRAINT `FK22C5B091DAB784FB` FOREIGN KEY (`id_gsm`) REFERENCES `modulo_gsm` (`id_gsm`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; -- -- Table structure for table `registros_amonia` -- DROP TABLE IF EXISTS `registros_amonia`; CREATE TABLE `registros_amonia` (
111 `id_reg_amonia` int(4) NOT NULL AUTO_INCREMENT, `id_dis` int(4) NOT NULL, `data_reg` date NOT NULL, `hora_reg` time NOT NULL, `conc_medida_reg` int(3) DEFAULT NULL, `conc_menor` int(3) DEFAULT NULL, `conc_maior` int(3) DEFAULT NULL, `data_hora_cme` datetime DEFAULT NULL, `data_hora_cma` datetime DEFAULT NULL, PRIMARY KEY (`id_reg_amonia`), KEY `FK909FA7E230CB05AE` (`id_dis`), CONSTRAINT `FK909FA7E230CB05AE` FOREIGN KEY (`id_dis`) REFERENCES `dispositivo` (`id_dis`), CONSTRAINT `registros_amonia_ibfk_1` FOREIGN KEY (`id_dis`) REFERENCES `dispositivo` (`id_dis`) ) ENGINE=InnoDB AUTO_INCREMENT=16 DEFAULT CHARSET=utf8; -- -- Table structure for table `usuario` -- DROP TABLE IF EXISTS `usuario`; CREATE TABLE `usuario` ( `id_usu` int(4) NOT NULL AUTO_INCREMENT, `nome_usu` varchar(40) NOT NULL, `usuario` varchar(25) NOT NULL, `senha` varchar(25) NOT NULL, `email` varchar(40) DEFAULT NULL, `telefone` varchar(13) DEFAULT NULL, `endereco` varchar(100) NOT NULL, `cpf` varchar(14) DEFAULT NULL, `nivel` int(1) NOT NULL, `ativo` tinyint(1) NOT NULL, `criado` datetime NOT NULL, `modificado` datetime DEFAULT NULL, `confirmarSenha` varchar(255) DEFAULT NULL, PRIMARY KEY (`id_usu`), UNIQUE KEY `usuario` (`usuario`) ) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8;
112 APÊNDICE B – CONFIGURAÇÃO DO SERVIDOR VIRTUAL NO ROTEADOR D-LINK DIR-600.
113 ANEXOS
114 ANEXO A – QUADRO COM OS CÓDIGOS “AT” DE ACESSO E CONFIGURAÇÃO UTILIZADOS PARA GERENCIAMENTO DO SIM 900. COMANDO RESPOSTA DESCRIÇÃO “AT AT” “OK” AT duas vezes para reconhecer baudrate. “ATE0” “ATE0rnrnOK” Desabilita eco dos comandos AT. “AT+CSQ” “+CSQ:<rssi><ber>” Busca intensidade do sinal na rede. “AT+CREG=0” “OK” Define o tipo de acesso a rede não solicitando o código resultado. “AT+CREG?” “+CREG: <n><status> OK” Aguarda o registro na rede. “AT+CUSD=1,”*544”,15” “+CUSD: 0,”String” Solicita o valor dos créditos pré- pago. “AT+CIPMUX=1” “OK” Ativa múltiplas conexões (multi IP). “AT+CSTT?” “CMNET” Verifica APN. “AT+CSTT=”claro.com.br” ,”claro”,”claro”” “OK” Configura provedor APN para chip da operadora CLARO. “AT+CSTT?” “claro.com.br” Verifica APN após configurá-lo. “AT+CIICR” “OK” Solicita conexão com GPRS. “AT+CIFSR” “IP <000.000.000.000>” Comando para obter um endereço IP local. “AT+CIPSTART=1,”TCP” ,”189.8.207.51”,”4550”” “CONNECT OK” Cria conexão com o servidor TCP onde está localizada a Aplicação Web de Monitoramento. “AT+CIPSEND=1” “SEND OK” Envia dados para o servidor. “AT+CIPSTART=2,”UDP” ,”a.ntp.br”,”123”” “CONNECT OK” Cria conexão com o servidor UDP do Observatório Nacional para solicitar a data e hora atual. “AT+CDNSCFG=”8.8.8.8” ,”8.8.4.4 ”” “OK” Envia comando de configuração do DNS. “AT+CDNSGIP=”a.ntp.br”” “+CDNSGIP: 1” Pergunta o IP do target pára o servidor DNS. “AT+CIPSEND=2” “+RECEIVE,3,48:rn” Envia solicitação para o servidor e aguarda retorno dos valores. “AT+CMGF=1” “OK” Solicita serviço de envio de dados por SMS. “AT+CMGS=”55DDD NUMERO”” “>” “+CMGS” Cadastra o número de celular que deve receber a mensagem. Após receber ‘>’ insere a mensagem. OBS: Após inserir a mensagem a ser enviada ao servidor e ao celular deve ser inserido o comando 26, que representa CTRL Z na tabela ASC II. Esse caractere indica ao SIM900 o término da mensagem. Os comandos estão apresentados no quadro em ordem de desenvolvimento para a correta execução do sistema embarcado do módulo GSM.

Mais conteúdo relacionado

Mais procurados (20)

DOCX
Perguntas e respostas de manutenção
oantu
 
PPT
BalançO Patrimonial
rafaelkeidann
 
PPTX
Dobutamina
rogocar2005
 
PPTX
Métodos de elevação de petróleo
Victor Said
 
PPTX
CORRESPONDENTES BANCÁRIOS NO BRASIL
INSTITUTO VOZ POPULAR
 
PPT
Aula 17 – fundamentos físicos da hidráulica
Hans Haddler
 
PPT
Envelhecimento
Ana Hollanders
 
PPTX
Metanfetamina Apresentação
Samuel Jumes
 
DOC
Inquérito hábitos alimentares
recurso1
 
PPTX
Apresentação antidepressivos e ansioliticos
Paula Soares
 
PDF
Simbologia hidraulica e pneumatica
Cris Cazco
 
PDF
Termodinâmica2
Fernando Machado Rocha
 
PDF
Introdução às Finanças Pessoais ]
Secretaria de Estado da Tributação do RN
 
PPT
Educação financeira ao alcance de todos
Ronaldo Andrade
 
PPT
03 funcionamento do motor
Instituto Federal de Pernambuco - Campus Barreiros
 
PPTX
Compressores e Reservatórios de Ar
Renato Pagel
 
PDF
Acido, base e sal
Julyanne Rodrigues
 
PPTX
Tratamentos Superficie.pptx
LuisCampo34
 
PPTX
Literacia financeira 6ºa
Celeste Ferreira
 
PPT
Elementos de m+íquina curso completo
Jacs Engenharia
 
Perguntas e respostas de manutenção
oantu
 
BalançO Patrimonial
rafaelkeidann
 
Dobutamina
rogocar2005
 
Métodos de elevação de petróleo
Victor Said
 
CORRESPONDENTES BANCÁRIOS NO BRASIL
INSTITUTO VOZ POPULAR
 
Aula 17 – fundamentos físicos da hidráulica
Hans Haddler
 
Envelhecimento
Ana Hollanders
 
Metanfetamina Apresentação
Samuel Jumes
 
Inquérito hábitos alimentares
recurso1
 
Apresentação antidepressivos e ansioliticos
Paula Soares
 
Simbologia hidraulica e pneumatica
Cris Cazco
 
Termodinâmica2
Fernando Machado Rocha
 
Introdução às Finanças Pessoais ]
Secretaria de Estado da Tributação do RN
 
Educação financeira ao alcance de todos
Ronaldo Andrade
 
03 funcionamento do motor
Instituto Federal de Pernambuco - Campus Barreiros
 
Compressores e Reservatórios de Ar
Renato Pagel
 
Acido, base e sal
Julyanne Rodrigues
 
Tratamentos Superficie.pptx
LuisCampo34
 
Literacia financeira 6ºa
Celeste Ferreira
 
Elementos de m+íquina curso completo
Jacs Engenharia
 

Semelhante a TCC - SISTEMA PARA MONITORAMENTO DO GÁS AMÔNIA EM AVIÁRIOS (20)

PDF
Desenvolvimento de-robo-movel (1)
Levi Germano
 
PDF
ugv-embrapa-veiculo-terrestre-autonomo-para-monitoramento-de-talhoes-de-silvi...
mefkhytheroboticist
 
PDF
Gestao contexto qos_qoe
IP10
 
PDF
Sistema de Aquisição de Dados aplicado à Soldagem
Alexandre Blum Weingartner
 
PDF
Desenvolvimento de um Sistema de Controle para Quadrirrotores
UmbertoXavierdaSilva
 
PDF
Plano de Projeto de Software para produtos da Lacertae SW
rafahreis
 
PDF
Aplicac3a7c3a3o da-abordagem-gqm-para-a-definic3a7c3a3o-de-um-processo-de-eng...
JADSON SANTOS
 
PDF
Monitoramento de Redes TCP/IP - Monografia
Pietro Scherer
 
PDF
FInal Project Report - PT
João Cardoso
 
PDF
Tcc Sistema controle_dimensional_2015 Engenharia Eletrônica
Leonardo Sasso
 
PDF
Dm ivo costa_2009_ant
Cristian Ochoa Arias
 
PDF
2012 oscar fernandogaidosrosero
Paulae Marcelo
 
PDF
Trabalho sae 2008 versao final a
Sergio Gebara
 
PDF
GERENCIAMENTO DO ESCOPO DE PROJETO DE SISTEMA DE DETECÇÃO, ALARME E COMBATE A...
Patrick Pires Alvim
 
DOC
TG_AccelerCar
Wislan Lima
 
PDF
Implementacao e desempenho da virtualizacao no dcomp ufs
Edward David Moreno
 
PDF
SISTEMA DE AQUISIÇÃO DE DADOS EM MATLAB UTILIZANDO COMUNICAÇÃO WI-FI™ VIA NOD...
UFPA
 
PDF
UFPA PPGCC LPRAD 2014-02 - Edinaldo La-Roque - OPNET - Tutorial Rede LTE Basi...
Edinaldo La-Roque
 
PDF
CIP_JOAO_VIVEIROS_TESE
João Viveiros
 
PPTX
GOM - Novo ATOS Plus
Robtec
 
Desenvolvimento de-robo-movel (1)
Levi Germano
 
ugv-embrapa-veiculo-terrestre-autonomo-para-monitoramento-de-talhoes-de-silvi...
mefkhytheroboticist
 
Gestao contexto qos_qoe
IP10
 
Sistema de Aquisição de Dados aplicado à Soldagem
Alexandre Blum Weingartner
 
Desenvolvimento de um Sistema de Controle para Quadrirrotores
UmbertoXavierdaSilva
 
Plano de Projeto de Software para produtos da Lacertae SW
rafahreis
 
Aplicac3a7c3a3o da-abordagem-gqm-para-a-definic3a7c3a3o-de-um-processo-de-eng...
JADSON SANTOS
 
Monitoramento de Redes TCP/IP - Monografia
Pietro Scherer
 
FInal Project Report - PT
João Cardoso
 
Tcc Sistema controle_dimensional_2015 Engenharia Eletrônica
Leonardo Sasso
 
Dm ivo costa_2009_ant
Cristian Ochoa Arias
 
2012 oscar fernandogaidosrosero
Paulae Marcelo
 
Trabalho sae 2008 versao final a
Sergio Gebara
 
GERENCIAMENTO DO ESCOPO DE PROJETO DE SISTEMA DE DETECÇÃO, ALARME E COMBATE A...
Patrick Pires Alvim
 
TG_AccelerCar
Wislan Lima
 
Implementacao e desempenho da virtualizacao no dcomp ufs
Edward David Moreno
 
SISTEMA DE AQUISIÇÃO DE DADOS EM MATLAB UTILIZANDO COMUNICAÇÃO WI-FI™ VIA NOD...
UFPA
 
UFPA PPGCC LPRAD 2014-02 - Edinaldo La-Roque - OPNET - Tutorial Rede LTE Basi...
Edinaldo La-Roque
 
CIP_JOAO_VIVEIROS_TESE
João Viveiros
 
GOM - Novo ATOS Plus
Robtec
 
Anúncio

Último (9)

PDF
SENAC Modelagem de Dados - Aula02 curso de ADS.pdf
JhonataLamim1
 
PDF
Apresentação sobre Funções Matemáticas e o módulo.pdf
Gabriel Vitor
 
PPTX
Gestão de Mudanças - Fases do processo de mudança organizacional
Gateware Group
 
PDF
Certificado em Redes Neurais Artificiais em Python
CaioSilva506151
 
PPTX
Gestão de Mudanças - O que é e como é implementada
Gateware Group
 
PDF
Explorando o Futuro do Corpo: Implantes Neurais e o Biohacking dos Sentidos
cooperliora
 
PDF
SENAC Modelagem de Dados - Aula01 do curso de ADSpdf
JhonataLamim1
 
PPTX
Desenvolvimento-de-Produtos-Inovadores.pptx
ssuser1d7565
 
PDF
Apresentação de Manipulação de strings em Python .pdf
Gabriel Vitor
 
SENAC Modelagem de Dados - Aula02 curso de ADS.pdf
JhonataLamim1
 
Apresentação sobre Funções Matemáticas e o módulo.pdf
Gabriel Vitor
 
Gestão de Mudanças - Fases do processo de mudança organizacional
Gateware Group
 
Certificado em Redes Neurais Artificiais em Python
CaioSilva506151
 
Gestão de Mudanças - O que é e como é implementada
Gateware Group
 
Explorando o Futuro do Corpo: Implantes Neurais e o Biohacking dos Sentidos
cooperliora
 
SENAC Modelagem de Dados - Aula01 do curso de ADSpdf
JhonataLamim1
 
Desenvolvimento-de-Produtos-Inovadores.pptx
ssuser1d7565
 
Apresentação de Manipulação de strings em Python .pdf
Gabriel Vitor
 
Anúncio

TCC - SISTEMA PARA MONITORAMENTO DO GÁS AMÔNIA EM AVIÁRIOS

  • 1. 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
  • 2. JEAN LUIZ ZANATTA J. SISMAAG - SISTEMA PARA MONITORAMENTO DO GÁS AMÔNIA EM 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
  • 3. 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
  • 4. JEAN LUIZ ZANATTA J. SISMAAG - SISTEMA PARA MONITORAMENTO DO GÁS AMÔNIA EM 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
  • 5. 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.
  • 6. 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.
  • 7. 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.
  • 8. 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
  • 9. 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
  • 10. 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
  • 11. 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
  • 12. 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
  • 13. 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
  • 14. 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
  • 15. 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
  • 16. 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
  • 17. 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).
  • 18. 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.
  • 19. 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.
  • 20. 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 Desenvolvimento do relatório 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 Desenvolvimento do relatório de TCC III. X X X Entrega do relatório de TCC III. X
  • 21. 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
  • 22. 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).
  • 23. 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
  • 24. 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).
  • 25. 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).
  • 26. 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.
  • 27. 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).
  • 28. 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).
  • 29. 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).
  • 30. 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
  • 31. 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 (Unified 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.
  • 32. 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.
  • 33. 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).
  • 34. 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.
  • 35. 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).
  • 36. 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
  • 37. 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.
  • 38. 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).
  • 39. 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
  • 40. 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).
  • 41. 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
  • 42. 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).
  • 43. 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).
  • 44. 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.
  • 45. 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”.
  • 46. 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.
  • 47. 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.
  • 48. 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
  • 49. 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.
  • 50. 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.
  • 51. 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.
  • 52. 51 entrada foram definidas pelo administrador de forma a atender as necessidades do sistema proposto, sendo que o software para monitoramento estará exposto na web, para manter um controle de acesso necessita de um eficiente controle de segurança. Dados como usuário, senha e nível devem estar registrados ao cadastrar um usuário de forma que o sistema, quando o usuário efetuar o acesso, define sua prioridade. Quadro 5 - Requisito Funcional Manter Informações de Módulo GSM. Fonte: o autor. O requisito Manter Informações de Módulo GSM tem acesso apenas pelo usuário administrador, sendo que o atributo identificador deve ser definido quando ele tiver em mãos os dados do módulo GSM implantado, pois através deste identificador o sistema reconhece que o módulo GSM “x” está associado ao dispositivo “y”. Os atributos “csq” e “crédito” da entidade móduloGSM, mencionados no modelo conceitual, são atualizados na Aplicação Web de Monitoramento pelo próprio sistema, quando o módulo GSM envia as informações. São considerados importantes, pois é através destes dados que o administrador tem conhecimento da qualidade do sinal, número que pode variar de 0 a 31, e conhecimento do valor do crédito do chip utilizado no módulo GSM, valor este que sempre deve estar positivo, pois só assim as informações podem ser repassadas para a Aplicação Web de Monitoramento. F02. MANTER INFORMAÇÕES DE MÓDULO GSM Descrição: Manter os registros de módulo GSM no sistema com as opções de inserir, alterar, excluir e consultar os dados dos mesmos. São informações do módulo GSM, esse responsável por enviar as informações dos registros de gás amônia efetuados pelo sensor para a aplicação web de monitoramento; Fontes: Administrador; Usuários: Administrador; Informações de entrada: Identificador, nome GSM, CSQ e credito. Informações de saída: - Gerar uma listagem contendo todos os dados de todos os módulos GSM do sistema; - Gerar uma listagem contendo todos os dados de apenas um módulo GSM do sistema, podendo realizar a consulta pelo seu nome ou pelo usuário associado a ele; Restrições lógicas: - O usuário administrador pode excluir um Modulo GSM já cadastrado no sistema somente quando não existir um dispositivo já cadastrado associado ao mesmo. - O atributo identificador é do tipo inteiro, de três posições, e refere-se a sua identificação para reconhecimento na entidade Dispositivo, pois o módulo GSM é quem envia as informações coletados pelo dispositivo para a aplicação web de monitoramento; Restrições tecnológicas: Possuir acesso à internet.
  • 53. 52 Quadro 6 - Requisito Funcional Manter Informações de Dispositivo. Fonte: o autor. O requisito funcional Gerenciar Registros de Concentração do Gás Amônia é considerado de um nível mais complexo, passa pelos mesmos processos dos requisitos anteriores que são: inserir, alterar, excluir e consultar os dados, porém com restrições, onde somente o sistema pode inserir ou alterar os dados, cabendo ao administrador poder excluir e consultar os dados, e restando ao cliente apenas poder consultar os dados. Segue no quadro 7 o detalhamento deste requisito. F03. MANTER INFORMAÇÕES DE DISPOSITIVO Descrição: Manter os registros de dispositivo no sistema com as opções de inserir, alterar, excluir e consultar os dados do mesmo. O dispositivo é quem realiza a aquisição de sinal, através do sensor, e os dados são armazenados na aplicação web através de seu identificador. Fontes: Administrador; Usuários: Administrador; Informações de entrada: Identificador, nome do dispositivo, usuário do tipo cliente e módulo GSM; Informações de saída: - Gerar uma listagem contendo todos os dados de todos os dispositivos do sistema; - Gerar uma listagem contendo todos os dados de apenas um dispositivo do sistema, consultando-o pelo seu nome ou pelo usuário associado a ele ou pelo módulo GSM associado a ele; Restrições lógicas: - O usuário administrador pode inserir um dispositivo no sistema, somente após associar ao mesmo, um usuário cliente e um módulo GSM já cadastrados no sistema; - O usuário administrador pode excluir um dispositivo do sistema somente após não haver nenhuma associação de registros de concentração de amônia do mesmo; - O atributo identificador é do tipo inteiro, de três posições, e refere-se a sua identificação para reconhecimento do dispositivo na aplicação web de monitoramento, pois ao enviar as informações para a aplicação mencionada, um dos dados informados pelo módulo GSM é o identificador do dispositivo, e é através deste identificador que o sistema insere ou atualizado os dados na aplicação; - Os atributos usuário do tipo cliente e módulo GSM são os respectivos: * usuário, este é quem adquiriu o próprio dispositivo; * módulo GSM, este é o responsável por mandar as informações deste dispositivo para a aplicação web de monitoramento; Restrições tecnológicas: Possuir acesso á internet.
  • 54. 53 Quadro 7 - Requisito Funcional Gerenciar Registros de Concentração do Gás Amônia. Fonte: o autor. O requisito funcional Gerenciar Registros de Concentração do Gás Amônia diz respeito apenas as operações das informações que estarão armazenadas na tabela RegistroAmonia pelos usuários definidos. Quando o módudo GSM for requisitado pelo firmware para enviar as informações coletadas pelo sensor do dispositivo para a Aplicação Web de Monitoramento, cabe ao software realizar o tratamento destes dados, pois no pacote de dados enviado pelo módulo GSM existem valores que devem ser armazenados em tabelas diferentes no banco de dados. O pacote enviado para a Aplicação Web de Monitoramento pelo módulo GSM contem os seguintes dados:  Identificador do dispositivo;  Concentração de gás amônia medida pelo sensor;  Dia, mês, ano, hora, minutos e segundos;  CSQ e crédito; F04. GERENCIAR REGISTROS DE CONCENTRAÇÃO DO GÁS AMÔNIA Descrição: Obter os dados registrados pelo sensor do dispositivo e registrá-los na aplicação web de monitoramento para o usuário cliente e administrador poderem efetuar a consulta de informações em tempo real; Fontes: Administrador; Usuários: Sistema GSM, Administrador e Cliente; Informações de entrada: Data, hora, concentração do gás amônia e identificador do dispositivo; Informações de saída: - Gerar uma listagem contendo todos os dados dos registros de concentração de amônia do aviário do respectivo cliente, consultando-o pelo nome do cliente; Restrições lógicas: - Estes dados podem ser inseridos ou alterados somente pelo usuário Sistema GSM; - Antes de o Sistema GSM inserir os dados na aplicação web de monitoramento, o software deve verificar através do identificador do dispositivo enviado pelo módulo GSM, se o próprio dispositivo está cadastrado no sistema. Caso não exista, o software deve ignorar as informações enviadas pelo módulo GSM; - O sistema GSM deve inserir os dados somente quando não houver outro registro de concentração do gás amônia para a data especificada; - O sistema GSM deve atualizar os dados somente quando houver outro registro de concentração de gás amônia para a data especificada; - Os dados de registros de concentração de gás amônia podem ser excluídos da aplicação web de monitoramento pelo usuário administrador, informando o dispositivo; Restrições tecnológicas: - Possuir acesso à internet; - Possuir acesso à rede de telefonia celular onde o aviário está localizado;
  • 55. 54 Os únicos dados que não devem ser armazenados na tabela RegistroAmonia são os de CSQ e crédito. Estes devem ser atualizados em módulo GSM. 4.1.2 Modelo de Casos de Uso O modelo de casos de uso visa capturar e descrever as funcionalidades que o sistema deve prover para os atores que interagem com o mesmo. Os atores identificados no contexto deste projeto estão descritos no quadro 8. Quadro 8 - Atores do Sistema. ATOR DESCRIÇÃO Administrador Representa os usuários funcionários responsáveis pela manutenção da aplicação da empresa que vendeu o sistema. Cliente Representa os usuários clientes da empresa que vendeu o sistema. Sistema GSM Representa o sistema de telefonia rede GSM/GPRS responsável por fazer a comunicação com o servidor e inserir no banco de dados os dados coletados pelo dispositivo de hardware. Fonte: o autor. A seguir é apresentado o diagrama de casos de uso e descrições associadas do sistema de monitoramento do gás amônia em aviários. Diagrama 2 - Casos de Uso do Sistema de Monitoramento do Gás Amônia em Aviários. Fonte: o autor.
  • 56. 55 4.1.3 Análise O tópico de análise definido no trabalho tem por objetivo detalhar as operações “CRUD” para usuário, módulo GSM e dispositivo, também o requisito Manter Informação de Registros de Concentração de Amônia, contendo as respectivas operações e consultas do sistema. Dividido em três atividades sendo elas diagrama de sequencia, modelo conceitual e contratos, a fase de análise se concentra na fase de análise dos casos de uso Manter Informações de Registros de Concentração de Amônia e Manter Informações de Dispositivo, pois os requisitos Manter Informações de Usuário e Módulo GSM segue o mesmo padrão do Manter Informações de Dispositivo. 4.1.3.1 Diagrama de Sequência O Diagrama de Sequência elaborado no projeto tem como objetivo mostrar como as mensagens entre os objetos são trocadas no decorrer do tempo apenas para a realização da operação Registrar Concentração de Amônia, pois para os casos de uso manter Informações de usuário, Modulo GSM e Dispositivo as operações são menos complexas, sendo elas de salvar, alterar, consultar e excluir. As interações entre os objetos para estas operações onde não são ilustradas no diagrama de sequência estão no diagrama de comunicação no item 4.1.4.1. Para registrar a concentração do gás amônia o ator Sistema GSM deve repassar informações para a interface que a partir dos dados recebidos do Módulo GSM deve indicar para qual dispositivo as informações serão registradas, e então armazenar os dados. Diagrama 3 - Diagrama de Sequencia Registrar Concentração de NH³. Fonte: o autor.
  • 57. 56 4.1.3.2 Modelo Conceitual Para o desenvolvimento, o diagrama de classes da UML é utilizado, com algumas restrições. Informalmente, podemos dizer que o modelo conceitual é um diagrama de classes sem métodos. Apenas conceitos, atributos e associações são representados. Com o auxílio da ferramenta Astah Community, usando o diagrama de classes da UML, foi desenvolvido o modelo conceitual a seguir: Diagrama 4 - Modelo Conceitual. Fonte: o autor. 4.1.3.3 Contratos Na elaboração do Diagrama de Sequencia, foram identificadas as operações e consultas para registros de concentração de amônia. A operação de “registrar concentração do gás amônia” implica a existência de uma intenção por parte do usuário Sistema GSM, que é capturada pelo contrato de operação. No Quadro 9 encontra-se o contrato para a operação indicar dispositivo efetuada pelo sistema no requisito funcional Manter Informações de Dispositivo. Quadro 9 - Contrato Operação Indicar Dispositivo. Fonte: o autor. Operação:  indicarDisp(id); Pré-condições:  Deve existir um dispositivo cadastrado com o atributo idDisp igual ao parâmetro id; Pós-condições:  O controlador retorna o dispositivo encontrado para então poder efetuar o registro uma nova concentração;
  • 58. 57 A pré-condição e pós-condição da operação indicar dispositivo são bem básicas. Na pré-condição simplesmente deve existir um dispositivo já cadastrado no sistema, pois para registrar a concentração do gás amônia o sistema deve informar de qual dispositivo foi registrado estes dados. O quadro 10, diz respeito ao contrato da operação “registrar concentração do gás amônia”, esta que é requisitada pelo sistema GSM ao enviar os dados de telemetria. Quadro 10 - Contrato Operação Registrar Nova Concentração NH³. Fonte: o autor. Para as operações CRUD do sistema foram elaborados apenas os contratos das operações do caso de uso Manter Informações de Dispositivo, pois, como mencionado anteriormente no item 4.1.1, os três casos de uso seguem o mesmo padrão. No quadro 11 segue o contrato para a operação de inserção de dispositivo. Quadro 11 - Contrato Operação Inserir Dispositivo. Fonte: o autor. Para o contrato acima mencionado as duas pré-condições foram estabelecidas devido ao fato de que para o administrador poder inserir um novo dispositivo no sistema, deve-se associar ele a um usuário do tipo cliente e um módulo GSM, pois o dispositivo pertence a um cliente e cada dispositivo deve ter um módulo GSM para enviar seus dados coletados para a aplicação web de monitoramento. Operação:  registrarNovaConcentração(data, hora, conc_medida); Pré-condições:  Deve existir um dispositivoCorrente; Pós-condições:  Foi criada uma instancia de registroAmonia chamada rA;  Foi criada uma associação entre dispositivoCorrente e rA;  Foram alterados os atributos de rA conforme os parâmetros; Operação:  salvarDisp(id, nome, usuário, moduloGSM); Pré-condições:  Existir um usuário já cadastrados no sistema com o atributo idUsu igual ao parâmetro usuário;  Existir um modulo GSM já cadastrado no sistema com o atributo idGSM igual ao parâmetro moduloGSM; Pós-condições:  Foi criada uma instancia de Dispositivo chamada disp;  Foi criada uma associação entre Controlador e disp;  Foram alterados os atributos de disp conforme os parâmetros;
  • 59. 58 Quadro 12 - Contrato Operação Alterar Dispositivo. Fonte: o autor. O contrato de operação alterar dispositivo acima é bem simples, sendo que para alterar os dados de qualquer dispositivo já cadastrado a aplicação deve indicar um dispositivo, o controlador deve buscar este dispositivo e depois de verificado sua existência alterar os dados. O contrato do quadro 13 segue o mesmo principio do anterior, onde a aplicação deve indicar um dispositivo, o controlador deve buscar este dispositivo e depois de verificado sua existência, porém somente irá destruí-lo se não haver nenhum registro de concentração de gás amônia relacionado a ele. Quadro 13 - Contrato Operação Excluir Dispositivo. Fonte: o autor. 4.1.4 Projeto da Camada Model A camada Model representa a parte que implementa a lógica de negócios da aplicação. O modelo encapsula o estado e comportamento da aplicação, sendo responsável por obter os dados convertendo-os em conceitos significativos, assim como, processar, validar, associar e qualquer outra tarefa relativa ao tratamento dos dados. É o único componente do MVC que faz a interface da aplicação frente á fonte de dados, que é representada pelo banco de dados. A tecnologia utilizada para a criação da camada Model na aplicação é o Hibernate. O Projeto da Camada Model está dividido em três tópicos. Primeiramente é elaborado o diagrama de comunicação (colaboração), seguido do diagrama de classes do projeto e por último a modelagem do banco de dados a se utilizar com a elaboração do modelo conceitual e lógico do mesmo. Operação:  alterarDisp(); Pré-condições:  Existir um dispositivoCorrente denominado disp; Pós-condições:  Foram alterados os atributos de disp conforme os parâmetros; Operação:  excluirDisp(); Pré-condições:  Existir um dispositivoCorrente denominado disp;  Não existir nenhum registro de concentração do gás amônia com o atributo idDisp igual ao parâmetro id; Pós-condições:  Foi excluído o dispositivo indicado pela aplicação;
  • 60. 59 4.1.4.1 Diagrama de Comunicação O diagrama de comunicação, também conhecido como diagrama de colaboração, permite realizar a modelagem dinâmica do sistema, diferentemente dos artefatos já concluídos, que são estáticos. Nessa fase, veremos como os objetos que fazem parte da arquitetura do sistema trocam mensagens para realizar suas responsabilidades. As mensagens, enumeradas sequencialmente, mostram a implementação das operações, descrevendo parâmetros e variáveis locais. O Diagrama de Comunicação elaborado visa mostrar a comunicação dinâmica entre os objetos da operação “inserir dispositivo” no sistema. Diagrama 5 - Diagrama de Comunicação Inserir Dispositivo. Fonte: o autor. Na operação “alterar dispositivo”, primeiramente o usuário administrador indica o dispositivo no qual deseja realizar as alterações e então insere os novos dados no formulário e salva. O diagrama 6 visa mostrar a troca de mensagens entre os objetos para a operação “alterar dispositivo”. Diagrama 6 - Diagrama de Comunicação Alterar Dispositivo. Fonte: o autor. O diagrama 7 visa mostrar a comunicação dinâmica entre os objetos para a operação
  • 61. 60 “excluir dispositivo”. Diagrama 7 - Diagrama de Comunicação Excluir Dispositivo. Fonte: o autor. Para o caso de uso Manter Informações de Registros de Concentração de Amônia, a operação principal é a de registrar a concentração de amônia na aplicação web de monitoramento. O diagrama 8 ilustra o diagrama de comunicação desta operação. Diagrama 8 - Diagrama de Comunicação Registrar Concentração de NH³. Fonte: o autor. 4.1.4.2 Diagrama de Classes do Projeto O diagrama de classes demostra em seu conteúdo as quatro classes definidas no projeto com os relacionamentos entre elas, seus atributos, métodos e como os dados do sistema estão dispostos entre si. Os métodos contidos no Controlador são responsáveis pela execução de eventos emitidos da Aplicação para as quatro classes do sistema: Usuario, ModuloGSM, Dispositivo e RegistroAmonia. Estes eventos estão relacionados a indicar, associar, criar, alterar, excluir, alterar ou registrar concentração de amônia para qualquer objeto que venha represente a classe definida. Já os métodos contidos nas Classes propriamente ditas são responsáveis por executar decisões referentes aos eventos emitidos pelo Controlador, a exemplo, para registrar dados de
  • 62. 61 concentração de amônia o Controlador chama o método indicarDisp(id), o Dispositivo retorna com o método getDis(id), registrarNovaConcentracao(data, hora, concentracao), criarRegistroAmonia(), associarRA(registroAmonia) e então a classe RegistroAmonia chama o método setDados(data, hora, conc_medida) armazenando os dados na tabela no banco de dados. O diagrama 9 ilustra o diagrama de classes do projeto. Para fins de visualização dos atributos e métodos das classes, nos métodos da classe Usuário foi removida a visibilidade dos atributos. Diagrama 9 - Diagrama de Classes do Projeto. Fonte: o autor. 4.1.4.3 Modelagem do Bando de Dados Embasado no modelo conceitual e diagrama de classes foi realizada a modelagem do banco de dados. Para a modelagem do banco elaborou-se dois diagramas. Primeiramente, foi desenvolvido o diagrama de modelagem conceitual seguido da modelagem lógica. O diagrama 10 ilustra o diagrama de modelagem conceitual do banco de dados que é utilizado para realizar a identificação das entidades e seus atributos a serem implementados e
  • 63. 62 os relacionamentos entre as mesmas. Diagrama 10 - Diagrama da Modelagem Conceitual do Banco de Dados. Fonte: o autor. A modelagem lógica, responsável pela visualização das tabelas com seus respectivos atributos, chaves primárias e chaves estrangeiras do banco de dados do sistema e apresentada no diagrama 11 através do diagrama modelo lógico do banco de dados. Diagrama 11 - Diagrama do Modelo Lógico do Banco de Dados. Fonte: o autor.
  • 64. 63 4.1.5 Projeto da Camada View Uma View exibe uma representação dos dados modelados. Esta camada é responsável pela apresentação, trata-se da fronteira entre usuário e o sistema em si. A tecnologia utilizada para a criação das telas (visões) da aplicação é o framework Primefaces em conjunto com o JSF. No modelo tradicional do MVC, a View é composta por GUI’s (Graphical Users Interface), enquanto que no MVC web, caso do projeto, a visualização das informações acontece através das páginas XHTML, onde as informações tratadas e visualizadas são dinâmicas. As diferenças estão no fato de que para a aplicação web é papel da camada Controller definir a View apropriada para a exibição da resposta obtida pela requisição feita, além de medir as notificações de Model, principalmente pela necessidade do reuso, é na View que ocorrem todas as interações do usuário que serão tratadas pelo controle para chamar os métodos apropriados no modelo. Os tópicos a seguir demonstram primeiramente o diagrama de Estados de Navegação, indicando quais janelas e eventos compõe o sistema. Após encontra-se o tópico do Projeto Gráfico das Telas do Sistema. 4.1.5.1 Diagrama de Estados de Navegação O diagrama de Estados de Navegação indica quais são as janelas que compõe o sistema e quais eventos permitem ao usuário navegar de uma para outra, permitindo poder visualizar o fluxo principal da Aplicação Web de Monitoramento proposta. Muitas vezes não é possível, antes da implementação do projeto, traçar exatamente todas as funcionalidade que a aplicação terá, mas pode-se ter uma clara visão de como se dará a navegação dentro da aplicação. Cada evento que rotula as transições do diagrama posteriormente será associado a um controle (botão) da janela na origem da transição. O diagrama 12 apresenta o Diagrama de Estados de Navegação da Aplicação Web de Monitoramento. O usuário ao acessar a página na internet é direcionado automaticamente para uma tela de login, onde após inserir seus dados corretamente o sistema o direciona para uma tela principal. Se o usuário for do tipo cliente poderá apenas consultar os registros da concentração do gás amônia efetuados pelo seu dispositivo. Se do tipo administrador, terá acesso às páginas para manter registros de usuário, dispositivo, módulo GSM e registros da concentração de gás amônia de todos os clientes que tem um dispositivo ativo.
  • 65. 64 Diagrama 12 - Diagrama de Estados de Navegação. Fonte: o autor. 4.1.5.2 Projeto Gráfico das Telas do Sistema Segundo Wazlawick 2011, para fazer o projeto gráfico de cada janela, o projetista deverá saber quais são os objetivos da janela e qual caso de uso ela realiza. É possível também que algumas janelas realizem apenas alguns fluxos alternativos de um caso de uso. As janelas da aplicação são baseadas nos componentes do framework Primefaces, e estão no formato XHTML. Para cada componente definido deve-se criar uma janela para o usuário interagir com o sistema. A figura 1 ilustra a tela de Login do sistema. Figura 1 - Projeto Gráfico da Tela de Login. Fonte: o autor. A primeira interação que o usuário realizará com o sistema, é na tela de Login, onde ele estará "entrando" no sistema. Ao validar seu acesso, o sistema o redireciona dependendo de seu tipo (status), se estiver definido como 1 (administrador) ele será redirecionado para a tela “Principal Admin”, e se seu status estiver definido como 2 (cliente) será redirecionado
  • 66. 65 para a tela “Principal Cliente”. Se administrador, feito isso o usuário terá as seguintes opções a sua disposição: Cadastros de Usuário, Cadastros de Módulo GSM, Cadastros de Dispositivo ou então Registros de NH³. Se cliente, terá acesso apenas à tela de Registros de NH³ tendo a opção de selecionar de qual dispositivo deseja visualizar os registros caso tenha mais de um dispositivo cadastrado em seu nome. Os dois tipos de usuários também tem a opção de encerrar o sistema no momento em que desejar. Relação entre o componente gráfico da tela de Login e a operação realizada pelo sistema:  Botão “Log in”: através do componente <p:commandButton action=””> ativa a função Login() do Managed Bean LoginMB onde o sistema acessa a base de dados e verifica se o acesso é válido. Após isso, armazena os dados na sessão e então faz a verificação do status e redireciona o usuário para a página permitida. Foi incorporado o projeto Facelets ao sistema. É um método para desenho de layout que possuí tags para criação de templates (layouts de páginas que podem ser reaproveitadas). Então, para administradores foi criado um template com cabeçalho, menu e conteúdo. E para clientes foi criado um template apenas com cabeçalho e conteúdo, pois ao “entrar” no sistema ele terá acesso a apenas uma tela. Assim, após efetuar seu login, o administrador navegará por telas padronizadas mantendo o cabeçalho e menu estáticos sendo alterado apenas o conteúdo dependendo do que o usuário deseja visualizar. A figura 2 ilustra a tela “Principal Admin”, ela contém o cabeçalho e menu principal. A partir daí o usuário administrador poderá navegar para a tela que desejar. Ao clicar no botão desejado no menu, o que será alterado é apenas o espaço do conteúdo. Figura 2 - Projeto Gráfico da Tela Principal Admin. Fonte: o autor.
  • 67. 66 Relação entre os componentes gráficos da tela “Principal Admin” e as operações realizadas pelo sistema:  Botão “Cadastros” de Usuário: através do componente <p:menuitem action=””> ativa a navegação para “Listar Usuários”.  Botão “Cadastros” de Módulo GSM: através do componente <p:menuitem action=””> ativa a navegação para “Listar Módulos GSM”.  Botão “Cadastros” de Dispositivo: através do componente <p:menuitem action=””> ativa a navegação para “Listar Dispositivos”.  Botão “Registros” de NH³: através do componente <p:menuitem action=””> ativa a navegação para “Listar Registros de NH³” para administrador.  Botão “Log out”: através do componente <p:commandButton action=””> ativa a função Logout() do Managed Bean UsuarioMB onde o sistema torna a sessão inválida e ativa a navegação para a tela de Login. A figura 3 ilustra o conteúdo da tela “Listar Usuários”, onde o administrador tem acesso aos dados de todos os usuários cadastrados no sistema e também tem a opção de adicionar, alterar ou excluir um usuário cadastrado. Figura 3 - Projeto Gráfico da Tela Listar Usuários. Fonte: o autor. Relação entre os componentes gráficos da tela “Listar Usuários” e as operações realizados pelo sistema:  Botão “Novo”: através do componente <p:commandButton oncomplete=””> ativa a navegação para o formulário “dialogUsuario”, atribuí o valor true para novo usuário e null para o objeto do tipo Usuario, indicando para o sistema que um novo usuário será criado.  Botão “Alterar”: através do componente <p:commandButton oncomplete=””> ativa a navegação para o formulário “dialogUsuario”, atribui o valor false para novo usuário e o usuário selecionado para o objeto do tipo Usuario, trazendo assim
  • 68. 67 todas as informações do usuário no formulário e indicando para o sistema que o usuário selecionado poderá ter seus dados alterados.  Botão “Excluir”: através do componente <p:commandButton onclick=””> ativa a navegação para uma caixa de dialogo de confirmação. Após confirmado, ativa a função Excluir() do Managed Bean UsuarioMB onde o sistema realiza a verificação se é possível excluir o usuário selecionado, se sim o exclui da base de dados. A figura 4 ilustra a tela do formulário cadastro/alteração “dialogUsuario”, utilizada para cadastrar/alterar um usuário. Este formulário está editado dentro do arquivo da tela “Listar Usuários”. Figura 4 - Projeto Gráfico do Formulário dialogUsuario. Fonte: o autor. Neste formulário o administrador deve então inserir todos os dados do usuário a ser criado ou alterado. Relação entre os componentes gráficos do formulário de criação/alteração de usuário e as operações realizados pelo sistema:  Botão “Salvar”: através do componente <p:commandButton actionListener=””> ativa a função Salvar() do Managed Bean UsuarioMB onde o sistema salva os dados do usuário no Banco de Dados.  Botão “Cancelar”: através do componente <p:commandButton oncomplete=””> torna o formulário “dialogUsuario” invisível, cancelando a operação de criação ou alteração de usuário. A figura 5 ilustra o conteúdo da tela “Listar Módulos GSM”.
  • 69. 68 Figura 5 - Projeto Gráfico da Tela de Listar Módulos GSM. Fonte: o autor. Relação entre os componentes gráficos da tela “Listar Módulos GSM” e as operações realizados pelo sistema:  Botão “Novo”: através do componente <p:commandButton oncomplete=””> ativa a navegação para o formulário “dialogModuloGSM”, atribuí o valor true para novo módulo GSM e null para o objeto do tipo ModuloGSM, indicando para o sistema que um novo módulo GSM será criado.  Botão “Alterar”: através do componente <p:commandButton oncomplete=””> ativa a navegação para o formulário “dialogModuloGSM”, atribui o valor false para novo módulo GSM e o módulo GSM selecionado para o objeto do tipo ModuloGSM, trazendo assim todas as informações do módulo GSM no formulário e indicando para o sistema que o módulo GSM selecionado poderá ter seus dados alterados.  Botão “Excluir”: através do componente <p:commandButton onclick=””> ativa a navegação para uma caixa de dialogo de confirmação. Após confirmado, ativa a função Excluir() do Managed Bean ModuloGSMMB onde o sistema realiza a verificação se é possível excluir o módulo GSM selecionado, se sim o exclui da base de dados. A figura 6 ilustra a tela do formulário cadastro/alteração “dialogModuloGSM”, utilizada para cadastrar/alterar um módulo GSM. Este formulário está editado dentro do arquivo da tela “Listar Módulos GSM”. Figura 6 - Projeto Gráfico do Formulário dialogModuloGSM. Fonte: o autor. Neste formulário o administrador deve então inserir o código e nome do módulo GSM
  • 70. 69 a ser criado ou alterado. Relação entre os componentes gráficos do formulário de criação/alteração de módulo GSM e as operações realizados pelo sistema:  Botão “Salvar”: através do componente <p:commandButton actionListener=””> ativa a função Salvar() do Managed Bean ModuloGSMMB onde o sistema salva os dados do módulo GSM no Banco de Dados.  Botão “Cancelar”: através do componente <p:commandButton oncomplete=””> torna o formulário “dialogModuloGSM” invisível, cancelando a operação de criação ou alteração de módulo GSM. A figura 7 ilustra o conteúdo da tela “Listar Dispositivos”. Figura 7 - Projeto Gráfico da Tela de Listar Dispositivos. Fonte: o autor. Relação entre os componentes gráficos da tela “Listar Dispositivos” e as operações realizados pelo sistema:  Botão “Novo”: através do componente <p:commandButton oncomplete=””> ativa a navegação para o formulário “dialogDispositivo”, atribuí o valor true para novo dispositivo e null para o objeto do tipo Dispositivo, indicando para o sistema que um novo dispositivo será criado.  Botão “Alterar”: através do componente <p:commandButton oncomplete=””> ativa a navegação para o formulário “dialogDispositivo”, atribui o valor false para novo dispositivo e o dispositivo selecionado para o objeto do tipo Dispositivo, trazendo assim todas as informações do dispositivo no formulário e indicando para o sistema que o dispositivo selecionado poderá ter seus dados alterados.  Botão “Excluir”: através do componente <p:commandButton onclick=””> ativa a navegação para uma caixa de dialogo de confirmação. Após confirmado, ativa a função Excluir() do Managed Bean DispositivoMB onde o sistema realiza a verificação se é possível excluir o módulo GSM selecionado, se sim o exclui da base de dados. A figura 8 ilustra a tela do formulário cadastro/alteração “dialogDispositivo”, utilizada
  • 71. 70 para cadastrar/alterar um dispositivo. Este formulário está editado dentro do arquivo da tela “Listar Dispositivos”. Figura 8 - Projeto Gráfico do Formulário dialogDispositivo. Fonte: o autor. Neste formulário o administrador deve então inserir o código e nome do dispositivo a ser criado/alterado e informar através das caixas de seleção a qual usuário ele irá pertencer e a qual módulo GSM ele estará associado. Relação entre os componentes gráficos do formulário de criação/alteração de dispositivo e as operações realizados pelo sistema:  Botão “Salvar”: através do componente <p:commandButton actionListener=””> ativa a função Salvar() do Managed Bean DispositivoMB onde o sistema salva os dados do dispositivo no Banco de Dados.  Botão “Cancelar”: através do componente <p:commandButton oncomplete=””> torna o formulário “dialogDispositivo” invisível, cancelando a operação de criação ou alteração de dispositivo. A última tela que o administrador terá acesso e a tela “Listar Registros de NH³”. Nessa tela o administrador poderá visualizar os registros efetuados pelos dispositivos de todos os seus clientes. Primeiramente deve-se selecionar um cliente, em seguida deve-se selecionar um dispositivo do cliente selecionado anteriormente. A figura 9 ilustra o conteúdo da tela “Listar Registros de NH³” para o administrador. Figura 9 - Projeto Gráfico da Tela de Registros de NH³ Para Administrador. Fonte: o autor.
  • 72. 71 Relação entre os componentes gráficos da tela “Listra Registros de NH³” e as operações realizados pelo sistema:  Caixa de Seleção “Cliente”: através do componente <p:selectOneMenu> ativa a função getUsuariosClientes() do Managed Bean RegistroConcentracaoAmoniaMB que lista todos os usuários do tipo Cliente existentes no sistema. Selecionado o usuário cliente, o sistema o atribui para uma variável o objeto do tipo Usuario.  Caixa de Seleção “Dispositivo”: através do componente <p:selectOneMenu> ativa a função getDispositivosDoCliente() do Managed Bean RegistroConcentracaoAmoniaMB que lista todos os dispositivos do usuário cliente selecionado na caixa de seleção “Cliente”. Selecionado o dispositivo, o sistema “popula” o componente <p:dataTable> com os registros do dispositivo selecionado.  Botão “Excluir”: através do componente <p:commandButton onclick=””> ativa a navegação para uma caixa de dialogo de confirmação. Após confirmado, ativa a função Excluir() do Managed Bean RegistroConcentracaoAmoniaMB onde o sistema exclui o registro selecionado da base de dados. A figura 10 ilustra a tela “Principal Cliente”, ela contém apenas o cabeçalho e conteúdo. Nela o usuário cliente poderá selecionar o dispositivo desejado e visualizar os seus registros. Deve-se lembrar que estarão disponíveis para seleção apenas os dispositivos cadastrados em seu nome. Figura 10 - Projeto Gráfico da Tela Principal Cliente. Fonte: o autor. Relação entre os componentes gráficos da tela “Principal Cliente” e as operações realizados pelo sistema:
  • 73. 72  Caixa de Seleção “Dispositivo”: através do componente <p:selectOneMenu> ativa a função getDispositivosDoCliente() do Managed Bean RegistroConcentracaoAmoniaMB que lista todos os dispositivos do usuário cliente “logado” no sistema. Selecionado o dispositivo, o sistema “popula” o componente <p:dataTable> com os registros do dispositivo selecionado.  Botão “Log out”: através do componente <p:commandButton action=””> ativa a função Logout() do Managed Bean UsuarioMB onde o sistema torna a sessão inválida e ativa a navegação para a tela de Login. 4.1.6 Projeto da Camada Controller A camada Controller é responsável por realizar a comunicação entre o Model (modelo) e a View (visão). Sua finalidade é controlar interações que ocorram a partir do usuário (recebe entradas) e descobre o que essa entrada significa para o modelo, ou ainda, do modelo em resposta às ações anteriores. No projeto da aplicação web a solução encontrada para a criação do controlador central é a utilização da tecnologia da especificação Java JSF (Java Server Faces), e para os componentes da camada View realizar a interação com a camada Model o JSF interage com classes modelo denominadas Managed Beans, que ficam separadas da camada de visualização e nelas é que, por exemplo, parte do texto, fica guardada para interagir com um modelo, lógica de negócio ou outro componente visual. A seguir segue a definição das classes Managed Beans criadas no projeto e seus métodos que são utilizados para interação entre View e Model de cada requisito especificado no item 4.1.1.  Classe AbstratoMB: é responsável pela troca de mensagens entre o sistema e o usuário. Nela existem métodos que o sistema utiliza para mostrar mensagem de erro e mensagem de informação ao usuário quando necessário. Todas as classes seguintes herdam as características da classe AbstratoMB.  Classe UsuarioMB: toda vez que o administrador clicar no botão “Cadastros” de usuários irá navegar pela tela “Listar Usuarios” e as ações responsáveis pela lógica de negócios e interação com o modelo dessa página estão contidos nesta classe. Métodos como adicionar(), alterar() e excluir() são responsáveis por buscar os valores dos formulários e interagir com a DAO. O método salvar() é “chamado” toda vez que o administrador clica no botão “Salvar”. É ele quem verifica através da variável booleana addNewUsu se o
  • 74. 73 administrador deseja criar um novo usuário ou apenas alterar um usuário existente. Os métodos getAllUsuarios(), getUsuariosClientes() e getUsuariosAdmins() são responsáveis por listar os usuários existentes. E por fim o método Logout() fica com a responsabilidade de encerrar o sistema, tornando a sessão inválida e ativar a navegação para a tela de Login.  Classe LoginMB: a classe LoginMB é responsável apenas for fazer a verificação de login do usuário. Primeiramente é injetado a ela a classe UsuarioMB através da anotação @manegedProperty() e então o método Login() fica responsável por verificar, através dos dados “usuário” e “senha” digitados no formulário da tela “Login”, se o usuário existe na base de dados do sistema e em qual o status (tipo) ele se enquadra, para então o encaminhar para a tela permitida.  Classe ModuloGSMMB: segue o mesmo principio da classe UsuarioMB, porém as ações responsáveis pela lógica de negócios e interação com o modelo são referentes a tela “Listar Modulos GSM”. No método excluir() o sistema realiza uma verificação. Se na base de dados existir algum dispositivo relacionado ao módulo GSM que se pretende excluir, o sistema insere uma mensagem de erro na tela informando ao usuário que é impossível excluir o módulo GSM. Isso a fim de manter a integridade lógica dos dados.  Classe DispositivoMB: esta segue contém as ações responsáveis pela lógica de negócios, interação com o modelo e interação entre os próprios componentes da tela “Listar Dispositivos”. Segue o mesmo principio da classe UsuarioMB e ModuloGSMMB. Contém os métodos getUsuariosTipoClientes() e getModulosGSM() que são “chamados” nos selects do formulário de cadastro/alteração de dispositivo.  Classe RegistroConcentracaoAmoniaMB: Managed Bean responsável pela interação das telas de “Registros de NH³”, tanto do Administrador como do Cliente, com a camada Model. Nesta classe existem métodos para buscar registros de amônia tanto do cliente como do dispositivo. Os métodos getUsuSelecionado() e getDispSelecionado() armazenam o usuário e o dispositivo selecionado pelo administrador. Também existem os métodos usuarioChangeListener (ValueChangeEvent event) e dispositivoChangeListener(ValueChangeEvent event), o primeiro “popula” o select “Dispositivo” e o segundo “popula” a tabela com os registros efetuados pelo dispositivo selecionado. Por fim o método refresh() fica responsável por atualizar a tela “Registro de NH³” no momento em que há atualização efetuada pelo dispositivo corrente.
  • 75. 74 4.1.7 Servidor: Comunicação e Armazenamento dos Dados Após a modelagem dos processos de negócio e análise de requisitos, no projeto da Aplicação Web de Monitoramento, desenvolvido no Netbeans IDE 7.1, criou-se uma classe denominada ServidorTCP. Sua responsabilidade é a de realizar a comunicação com o sistema GSM por meio de um canal de comunicação designado por socket em protocolo TCP, que garante a entrega das mensagens pela mesma ordem a qual foram enviadas, processar os dados enviados pelo GSM e então armazená-los na base de dados da Aplicação. O quadro 14 ilustra o código desenvolvido para a realização das tarefas citadas acima. Quadro 14 - Classe Java ServidorTCP. Fonte: o autor.
  • 76. 75 Pode-se observar que a classe contém seu método de execução e uma classe interna denominada ThreadTrataCliente estendendo de thread, esta responsável por tratar as conexões recebidas pelo servidor, pois a comunicação se dá via socket multi thread, ou seja, pode-se ter vários clientes conectados no mesmo instante de tempo. Primeiramente define-se uma porta que deve estar liberada no servidor para comunicação TCP, em seguida dois objetos são criados (socket para conexão com servidor e socket privado para sessão com o cliente). Utilizando-se de um tratador de erros, em seguida é indicada a porta associada ao serviço para o servidor e então é executado um loop infinito onde inicia-se a thread responsável por realizar o tratamento das conexões efetuadas pelo cliente. Depois de estabelecida conexão, o tipo stream19 inputStreamReader oferecido pelo Java realiza a troca de mensagens. Em seguida, o sistema executa o método run(), responsável pelas tarefas de leitura da informação, quebra de pacotes, atualização da base de dados e finalização de transferências e conexões liberando recursos para o sistema. 4.2 DESENVOLVIMENTO DOS MÓDULOS DE HARDWARE E INTERFACEAMENTO Apresenta a modelagem e implementação dos módulos de hardware e interfaceamento. Desenvolveu-se primeiramente o circuito de condicionamento de sinal, e lógica de processamento dos dados presentes no Módulo Slave (Dispositivo). Com o objetivo de documentar e organizar o desenvolvimento de hardware, os sistemas embarcados (firmwares) e interfaceamento utilizou-se os métodos de modelagem da SysML e BPMN. 4.2.1 Circuito de Condicionamento do Sinal do Dispositivo O circuito de condicionamento do sinal desenvolvido pelo autor é um circuito divisor de tensão. Este segue o padrão para aquisição de sinal definido pelo fabricante do sensor utilizado no projeto, que determina a utilização de um resistor de 10 KOhm. Os divisores de tensão composto pelos resistores de 1 MOhm e 560 KOhm são utilizados para diminuir a tensão de leitura (no máximo 5 V) para uma tensão que o módulo ADC do uC aceite (no máximo 3.3 V). Além disso, os valores são bem altos, pois a impedância desse divisor de tensão deve ser muito maior que a impedância do circuito a ser lido (RI), para evitar distorção na leitura do sinal. A taxa de amostragem deste sinal é de 250 milissegundos. O Esquema 4 19 Em Java, stream é um objeto que permite obter dados de um fluxo de entrada ou enviar dados para algum fluxo de saída, usando um protocolo comum. (O AUTOR).
  • 77. 76 ilustra o circuito de condicionamento de sinal do projeto. Esquema 4 - Esquema do Circuito de Condicionamento do Sinal. Fonte: o autor. Os pinos As e Ah do microcontrolador são utilizados para completar corretamente o ciclo ilustrado no quadro 2 do tópico 2.6.2.1. Através deles e da lógica implementada no firmware, o sistema deve atribuir nível lógico alto ou baixo nos pinos 3 e 4 do sensor, como ilustrado acima. Para mostrar o funcionamento do dispositivo, pode-se dividir a explicação do circuito da seguinte maneira:  Circuitos para os ciclos de aquecimento e de leitura do sensor: visando explicar o funcionamento do circuito de condicionamento do sinal, para conseguir completar os ciclos de aquecimento e leitura do sensor, o circuito utiliza de dois transistores BC 807 da NXP, responsáveis por drenar corrente para o sensor, resistores de pull-up, com o objetivo de obter um nível lógico (0, 0 V ou 1, 5 V) na base dos transistores, saídas As (para leitura) e Ah (para aquecimento) conectadas aos pinos de I/O do uC configurados como saída em modo open-drain. Saídas A/D_1 e A/D_2 conectadas aos pinos dos canais 1 e 2 do ADC do uC e estão configurados como entrada para leitura do sinal, como observado no esquema 4 acima. Os transistores são do tipo PNP (lógica positiva), e possuem seus terminais conectados da seguinte maneira:  Emissor: ligados a fonte de 5 V na placa;  Base: ligados aos pinos As e Ah do microcontrolador;  Coletor: com saída para os pinos positivo do sensor; Para o circuito desenhado a corrente entra no terminal Emissor, e sai no terminal Coletor e Base. O valor da corrente no terminal Base é quem controla o fluxo de corrente do
  • 78. 77 Emissor para o Coletor, ou seja, os pinos de I/O do microcontrolador é quem definem o valor da tensão nos “pólos” positivo do sensor. O esquema 5 abaixo tem por objetivo ilustrar as principais conexões e o circuito de condicionamento de sinal do Módulo Slave. O uC recebe os dados capturados pelo sensor (entrada de dados), processa, e os envia para o LCD (saída local). Também ilustra a conexão para o gravador (JTAG) e conexões para o driver 485, responsável por realizar a interface entre o uC e o barramento RS-485. O esquema é apenas ilustrativo, alguns dos componentes desenhados não são os reais utilizados. Esquema 5 - Principais Conexões do Módulo Slave (Dispositivo). Fonte: o autor. 4.2.1.1 Processamento dos Dados Através dos valores da tensão lidos pelo módulo ADC do microcontrolador nos pinos AD_1 e AD_2, calcula-se o valor da resistência (impedância) do sensor, aplicando a Lei de Ohm e então este valor passa a ser convertido para um valor real de concentração de NH³, em ppm (Partícula Por Milhão), podendo variar de 0 a 100. Para esta conversão, utilizou-se os valores ilustrados no quadro 15, que são referentes à sensibilidade do sensor. Eles foram disponibilizados pelo fabricante do sensor utilizado e define a razão de concentração do gás amônia em função da resistência (impedância) do sensor. Os valores relacionados ao ar, etanol e H2S são utilizados no gráfico apenas para efeito de comparação.
  • 79. 78 Gráfico 1 - Sensibilidade do Sensor TGS 2444. Fonte: Figaro Engineering Inc., 2010. Os valores da resistência do sensor foram extraídos do gráfico acima e armazenados em um vetor de 102 posições, como ilustra o quadro abaixo. Na posição 0 do vetor é armazenada a resistência equivalente a concentração de 0 ppp e na posição 100 do vetor é armazenada a resistência equivalente a 100 ppm. A posição 101 indica saturação, é utilizada como delimitador para informar que a concentração do gás amônia está fora da faixa do sensor, pois este sensor, segundo o fabricante, deve ser utilizado para medir na faixa de 0 ppm a 100 ppm. Quadro 15 – NH³ (ppm) em Função da Resistência (ohm) do Sensor. NH3/Rs NH3/Rs NH3/Rs NH3/Rs NH3/Rs NH3/Rs 0/50400 1/47250 2/37800 3/31500 4/26250 5/23100 6/21000 7/18900 8/17850 9/16800 10/15750 11/14785 12/13897 13/13083 14/12341 15/11665 16/11053 17/10500 18/10002 19/9551 20/9135 21/8746 22/8382 23/8043 24/7727 25/7435 26/7165 27/6917 28/6691 29/6485 30/6300 31/6134 32/5986 33/5853 34/5733 35/5623 36/5521 37/5424 38/5331 39/5239 40/5145 41/5048 42/4949 43/4848 44/4746 45/4646 46/4548 47/4453 48/4363 49/4278 50/4200 51/4130 52/4066 53/4009 54/3956 55/3906 56/3860 57/3814 58/3769 59/3723 60/3675 61/3624 62/3571 63/3517 64/3461 65/3405 66/3350 67/3297 68/3245 69/3196 70/3150 71/3108 72/3070 73/3035 74/3003 75/2973 76/2944 77/2917 78/2890 79/2863 80/2835 81/2806 82/2777 83/2747 84/2716 85/2684 86/2652 87/2619 88/2586 89/2553 90/2520 91/2487 92/2454 93/2421 94/2388 95/2356 96/2324 97/2293 98/2263 99/2234 100/2205 101/2178 Fonte: o autor.
  • 80. 79 Para calcular o valor real de concentração de NH³, após efetuar a leitura das tensões do circuito de condicionamento de sinal e calcular a impedância do sensor através da lei de Ohm, o sistema então compara com este os valores armazenados no vetor, e a posição do vetor onde o valor mais próximo ao medido é encontrado, equivale ao valor real da concentração do gás no ambiente. 4.2.2 Contexto do Projeto A fim de documentar e organizar o desenvolvimento de hardware do J.SISMAAG, definiu-se o escopo do projeto através do diagrama de blocos da SysML. O diagrama 13 ilustra o contexto do projeto de hardware, envolvendo o Módulo Dispositivo e o Módulo GSM. Diagrama 13 - Contexto do Projeto do Dispositivo. Fonte: o autor. O diagrama de blocos foi desenvolvido com a ferramenta Astah SysML, na versão Trial, disponível para testes em até 30 dias após sua instalação. Esta etapa foi de extrema importância, pois assim pode-se saber o escopo e limites do projeto. Aos limites da cor vermelho está à representação do Módulo Slave (Dispositivo), o qual foi disponibilizado pela empresa Altem com autorização para realizar as alterações necessárias, como desenvolver o circuito de condicionamento de sinal, aquisição e processamento dos dados e atender aos requisitos do projeto. E aos limites da cor azul, está a representação do Módulo Master (GSM), o qual foi disponibilizado pela empresa como sendo um produto. A empresa também disponibilizou o manual de usuário, para então desenvolver o sistema embarcado do mesmo.
  • 81. 80 A seguir encontra-se a etapa de desenvolvimento dos requisitos funcionais do sistema embarcado do Módulo Slave (Dispositivo) e Módulo Master (GSM). 4.2.3 Requisitos Funcionais A etapa de levantamento de requisitos do projeto é representada na forma gráfica, através do diagrama de requisitos funcionais da SysML, sendo que cada requisito possui duas propriedades básicas, um identificador (id) e um texto (text) com a descrição do mesmo. Os requisitos funcionais são derivados de um requisito base, representando as funcionalidades do sistema. O elemento rationale é utilizado para anotação, descrevendo o nível do risco que o sistema estará exposto para cada requisito. Para melhor entendimento, elaborou-se o diagrama de requisitos funcionais de cada Módulo separadamente. No diagrama 14 são apresentados os requisitos funcionais do dispositivo de aquisição e processamento dos dados (Módulo Slave). O primeiro requisito desenhado é o sistema embarcado em si, em seguida encontram-se os requisitos derivados dele, como, inicialização dos componentes envolvidos, gerenciamento de leitura dos dados e comunicação com GSM e visualização dos dados local, através de um LCD. Diagrama 14 - Requisitos Funcionais do Projeto do Dispositivo. Fonte: o autor.
  • 82. 81 Para a elaboração dos requisitos do Módulo Master (GSM), foram seguidos os mesmos padrões utilizados para o Dispositivo. Diagrama 15 - Requisitos Funcionais do Projeto do GSM. Fonte: o autor. Do mesmo modo que no diagrama de contexto, o diagrama de requisitos funcionais também foi desenvolvido com a ferramenta Astah SysML. Com a elaboração dele, o entendimento funcional dos sistemas embarcados do projeto se tornam fácil, pois o diagrama possibilitou uma modelagem da estrutura e comportamentos dos softwares embarcados.
  • 83. 82 4.2.4 Modelagem dos Processos Com o objetivo de detalhar todos os processos executados pelo software embarcado de cada módulo é desenvolvida a modelagem dos processos utilizando a notação gráfica BPMN. O fluxograma 1 apresenta o processo de gerenciamento do projeto de hardware e interfaceamento. Ele está dividido em dois controladores, gerenciamento do Dispositivo e gerenciamento do GSM, representando separadamente os processos executados em cada módulo. Fluxograma 1 - Processo Gerenciamento de Hardware e Interfaceamento. Fonte: o autor. No processo ilustrado acima, pode-se visualizar que em cada controlador existe dois elementos, inicio (verde) e fim (vermelho), e um subprocesso onde existem diversas tarefas a serem cumpridas. O fluxograma 2 apresenta o subprocesso a ser executado no sistema embarcado do Módulo Slave (Dispositivo). Fluxograma 2 - Subprocesso Gerenciamento do Dispositivo. Fonte: o autor.
  • 84. 83 Visualizando o fluxograma 2, pode-se observar que primeiramente o sistema deverá executar as tarefas de inicialização e configuração de alguns componentes do microcontrolador utilizados no processo, como, watchdog, timers, GPIO’s, UART e ADC. Em seguida, o contador do ciclo de funcionamento do sensor deverá estar igual ou acima de 250 milissegundos para então poder realizar os processos de aquisição dos dados. Para melhor entendimento do processo de gerenciamento do Dispositivo, optou-se por dividi-lo em mais quatro subprocessos, são eles: configurar pinos do sensor, configurar pinos de comunicação com GSM, solicitar leitura do sensor e tratar pacotes. Os próximos quatro fluxogramas apresentam as tarefas dos subprocessos mencionados. Os pinos responsáveis por drenar ou cessar corrente ao circuito que “alimenta” o sensor são o 28 e 29 do PORT 1. Eles devem estar definidos como sendo saída em modo open-drain, para evitar queimar os pinos do uC, ver item 4.2.1, e inicialmente devem estar em nível lógico alto, ou seja, em modo cessar drenar corrente, como ilustra o fluxograma 3. Fluxograma 3 - Subprocesso Configurar Pinos do Sensor. Fonte: o autor. Para o processo de comunicação com o Módulo Master via RS-485 primeiramente os pinos do uC conectados ao RX e TX do transceiver 485 deverão estar definidos como sendo saída. O próximo passo é verificar o buffer da UART e esperar a transmissão de dados, em seguida habilitar TX e desabilitar RX, pois esta configuração deixa o Dispositivo em modo de recepção, aguardando o pedido do mestre, o Módulo Master (GSM). Fluxograma 4 - Subprocesso Configurar Pinos de Comunicação com GSM. Fonte: o autor. O fluxograma 5 apresenta as tarefas executadas no subprocesso de leitura das tensões no circuito de condicionamento de sinal. Atendendo ao requisito de funcionamento do sensor,
  • 85. 84 primeiramente o sistema zera o contador e drena corrente para Vh. Espera 2 milissegundos e drena corrente pra Vc. Espera 6 milissegundos e efetua a leitura das tensões, pois este é o ponto ideal de detecção. Por fim, no tempo estabelecido pelo fabricante no datasheet do sensor, cessa o drenar corrente pra Vh e Vc. O fluxograma 05 ilustra esse subprocesso. Fluxograma 5 - Subprocesso Solicitar Leitura do Sensor. Fonte: o autor. O último subprocesso a ser especificado no Dispositivo contém tarefas que devem ser realizadas para comunicar e enviar os dados necessários ao GSM. As execuções das tarefas levam em consideração um controle de fluxo de dados, controle de erros de transmissão e seguem o protocolo de comunicação definido no item 2.6.3.1.1. Fluxograma 6 - Subprocesso Tratar Pacotes. Fonte: o autor. A partir do fluxograma 7 é apresentado o subprocesso a ser executado no sistema embarcado do Módulo Master (GSM). As tarefas a serem executadas nele são mais complexas do que no Dispositivo, pois além das tarefas de inicialização dos componentes e de comunicação com o Dispositivo, o microcontrolador deve se comunicar via interface UART
  • 86. 85 controlando o motor20 GSM/GPRS SIM900. Desta maneira, o subprocesso de gerenciamento do Módulo Master (GSM) contém dez subprocessos que estão detalhados separadamente. Fluxograma 7 - Subprocesso Gerenciamento do GSM. Fonte: o autor. O subprocesso configurar pinos de comunicação com dispositivo é igual ao subprocesso ilustrado no fluxograma 3 apresentado anteriormente, porém deve-se dar atenção às configurações do uC na placa, pois os pinos do microcontrolador ligados ao TX e RX do transceiver 485 não são os mesmos do Dispositivo. O fluxograma 8 ilustrado a seguir define as tarefas de configuração dos pinos do uC conectados ao SIM900. São eles pinos de DCD, POWER e RESET. Da maneira estabelecida no fluxograma, inicialmente o SIM900 permanece desligado. Fluxograma 8 - Subprocesso Configurar Pinos de Comunicação com SIM900. Fonte: o autor. 20 Termo referido ao controle de serviços executados pelo modulo GSM/GPRS SIM900 abordado no projeto. (O AUTOR).
  • 87. 86 O fluxograma 9 ilustra as tarefas que o sistema embarcado do GSM deve executar para buscar um Dispositivo conectado ao barramento RS-485. O sistema deve definir um ID para o dispositivo iniciando em zero, e incrementando este valor até encontrá-lo. Também deve ser definido um valor para comando de HANDSHAKE, pois é verificando este comando que o Dispositivo retorna dados de confirmação (0x6F e 0x6B, correspondentes a “o” e “k” na tabela ASC II). Antes de armazenar o ID do Dispositivo encontrado, o sistema também realiza uma verificação desses valores no buffer da UART. Fluxograma 9 - Subprocesso Buscar Dispositivos no Barramento RS-485. Fonte: o autor. Um processo muito importante a ser executado é o de verificar o valor de créditos do chip, pois este fator é crucial ao correto funcionamento do J.SISMAAG, se estiver R$0,00 simplesmente o SIM900 não se comunica com a Aplicação Web de Monitoramento. As tarefas são básicas, o sistema envia um comando ao SIM900 solicitando este valor, verifica o retorno, se igual ao especificado, a solicitação foi registrada pelo SIM900, então armazena temporariamente o valor de créditos. O fluxograma 10 ilustra este subprocesso. Fluxograma 10 - Subprocesso Solicitar Créditos. Fonte: o autor. Os subprocessos dos fluxogramas 11 e 12 a seguir devem ser executados toda vez em que haver a necessidade de enviar alguma informação para a Aplicação Web de Monitoramento.
  • 88. 87 Fluxograma 11 - Subprocesso Abrir Conexão com Servidor. Fonte: o autor. Após executado o processo para abrir conexão com servidor, e o mesmo ter retornado sucesso, o sistema deve então enviar os dados desejados, dados estes, que podem ser de valor em créditos pré-pago do chip do SIM900 utilizado, ou de valor de concentração de NH³ medido pelo Dispositivo no momento. Tanto pra um como pra outro o processo é o mesmo, pois o que difere um de outro é o pacote de dados a ser enviado. Fluxograma 12 - Subprocesso Enviar Dados p/ Servidor. Fonte: o autor. Com o objetivo de obter o momento preciso em que o sistema registra o valor de concentração de NH³ do ambiente, o mesmo deve buscar a data e hora no servidor NTP do observatório nacional e armazenar os valores para então enviá-los junto ao valor concentração de NH³, a Aplicação Web de Monitoramento. O fluxograma 13 apresenta todas as tarefas a serem executadas para atender a este processo. Fluxograma 13 - Subprocesso Atualizar Data e Hora. Fonte: o autor. Outro requisito a ser atendido pelo GSM é o de verificar o valor de CSQ (nível do sinal) estabelecido no local em que os módulos estão implantados. O fluxograma 14 ilustra esse subprocesso. Primeiramente o sistema embarcado do GSM deve solicitar ao SIM900 o
  • 89. 88 serviço definido, verificar sua resposta. Se o buffer da UART for maior que sete bytes, o valor foi recebido com sucesso, então deve armazena o valor para enviá-lo a Aplicação Web de Monitoramento. Fluxograma 14 - Subprocesso Solicitar CSQ. Fonte: o autor. No fluxograma 15 é ilustrado o subprocesso em que o sistema embarcado do GSM solicita a concentração de NH³ ao Dispositivo de aquisição e processamento dos dados. Este, segue o mesmo padrão do subprocesso buscar dispositivo no barramento RS-485, com a diferença de que o ID do Dispositivo já deve estar armazenado, assim basta apenas repassar seu ID e o comando de LERNH3 e posteriormente verificar o retorno e, se todas as condições estabelecidas forem atendidas, armazenar a concentração de NH³ recebida para posteriormente enviá-la para a Aplicação Web de Monitoramento. Fluxograma 15 - Subprocesso Solicitar Concentração de NH³ via RS-485. Fonte: o autor. O último subprocesso a ser executado pelo sistema embarcado do GSM é o de enviar um SMS para o número especificado se a concentração de NH³ estiver igual ou acima de 50 ppm, avisando o usuário cliente que o valor está no limite. Essa decisão foi tomada pelo fato de no momento em que essa situação ocorrer, ele não esteja online. Partindo do mesmo princípio de comunicação com o SIM900, o sistema deve enviar um comando a ele solicitando o serviço de envio de dados via SMS. Se atendido a todas as condições estabelecidas retorna sucesso, caso contrário retorna erro.
  • 90. 89 Fluxograma 16 - Subprocesso Envia SMS de Aviso p/ Celular do Cliente. Fonte: o autor. Os tópicos 4.2.5 e 4.2.6 a seguir apresentam a implementação dos principais processos executados pelos firmwares do sistema embarcado do Dispositivo e GSM. Tanto pra um como pra outro, os projetos foram criados na IDE keil uVision 4 em linguagem de programação C. 4.2.5 Sistema Embarcado do Dispositivo Para o sistema embarcado do Dispositivo o projeto criado é denominado de “Amonia” e está estruturado em arquivos separados por três pastas, sendo elas: “Startup”, “Headers” e “Sources”. A pasta “Startup” é definida por defaut pela IDE de desenvolvimento ao criar o projeto. Nela contem dois arquivos com extensões:  .s: arquivo de inicialização do dispositivo de núcleo Cortex-M3 para série NXP LPC17xx utilizada no projeto. A ARM Limited fornece o software para o uso dos processadores baseados em Cortex-M. Ele é distribuído livremente dentro da ferramenta de desenvolvimento, a Keil uVision, que apoia o uso dos processadores baseados em ARM;  .c: arquivo fonte do sistema do dispositivo para a série NXP LPC17xx que contém definições do sistema, como configuração de clock e registradores. Também é um arquivo disponibilizado pela ARM Limited; A pasta “Headers” contem os arquivos com extensão .h, onde existe um arquivo para cada função a ser executada, como por exemplo, um arquivo para utilização do módulo ADC, outro para configuração de GPIO, entre outros. Nestes arquivos são definidas macros, protótipos de funções e variáveis globais. Para cada arquivo criado com extensão .h, existe outro arquivo com o mesmo nome, porém com extensão .c, estes estão localizados dentro da
  • 91. 90 pasta “Sources” e são responsáveis por utilizar as macros, variáveis e implementar as funções definidas nos “Headers”. Na pasta “Sources”, além dos arquivos com o mesmo nome dos de extensão .h, existe outro denominado de main.c, este responsável pela inicialização do sistema (utilizado as funções definidas em “Startup”) e execução da rotina principal do programa utilizando das funções definidas nos outros arquivos “Sources”. A seguir serão apresentados os códigos das principais funções executadas pelo sistema embarcado do Dispositivo. No quadro 16 pode-se visualizar o código do subprocesso configurar pinos do sensor do Dispositivo que está especificado no fluxograma 03. Quadro 16 - Configuração Inicial dos Pinos Responsáveis por Controlar a Corrente Elétrica no sensor. Fonte: o autor. O código apresentado no quadro 17 ilustra o processo executado para ler as tensões dos dois pinos utilizados do módulo ADC do microcontrolador presente no Módulo Slave (Dispositivo). Quadro 17 - Função Responsável pela Aquisição do Sinal. Fonte: o autor. Nota-se que a leitura é realizada duas vezes. Isso se dá pelo fato de se obter uma maior precisão na medição. O quadro 18 ilustra o código da função responsável por calcular o valor de real de concentração de NH³. Após calcular o valor medido pelo sensor (resistência), a função realiza
  • 92. 91 a conversão deste valor para o valor real da concentração com base nos valores ilustrados no quadro 15, valores estes, que no código fonte são armazenados em um vetor de 102 posições, onde cada posição do vetor armazena a respectiva resistência. Dessa forma, a função encontra a posição correspondente ao valor de leitura do sensor e a retorna. O valor retornado é então a concentração de NH³ em ppm (partícula por milhão). Quadro 18 - Função Responsável por Realizar a Conversão em ppm. Fonte: o autor. O quadro 19 representa o código da rotina principal do programa, onde a cada iteração, o sistema executa o processo de alimentar Whatchdog timer, ler tensões do circuito de condicionamento de sinal, calcular impedância (resistência do sensor), calcular o valor real de concentração de NH3, comunicar com GSM através da função trata_pacotes e então atualizar o LCD. Quadro 19 - Rotina Principal do Sistema Embarcado Dispositivo e Método Trata_pacotes(). Fonte: o autor.
  • 93. 92 O item 4.2.6 finaliza a etapa de desenvolvimento do J.SISMAAG. Nele é apresentado o código das principais funções executadas pelo GSM. 4.2.6 Sistema Embarcado do GSM Para o sistema embarcado do GSM o projeto criado no Keil uVision 4 é denominado de “Telemetria_GSMLPC1751” e, igual ao projeto do Dispositivo, está estruturado em arquivos separados por três pastas, sendo elas: “Startup”, “Headers” e “Sources”, seguindo o mesmo padrão de projeto. Após os processos de inicialização e configuração das UART’s e configuração dos pinos da interface RS-485 e pinos de comunicação com SIM900 é executado o processo para buscar dispositivos no barramento RS-485, ilustrado no fluxograma 9. O quadro 20 apresenta o código desenvolvido para a realização deste processo. Quadro 20 - Função Responsável por Buscar Dispositivos no Barramento RS-485. Fonte: o autor. Armazenado os endereços dos dispositivos encontrados, o sistema embarcado realiza então os processos de comunicação com o módulo SIM900. Para comunicar, foram desenvolvidos dois métodos: Sim900_send_cmd(cmd, timeout), onde deve-se repassar por parâmetro o comando “AT” para solicitar o serviço desejado e um tempo de retorno, e UART_receiving_wait(porta, timeout), onde deve-se repassar por parâmetro a porta da UART e um tempo de resposta, para então verificar o tamanho do buffer e saber qual a resposta do SIM900 ao serviço solicitado. Os códigos das duas funções descritas estão apresentados no quadro 21.
  • 94. 93 Quadro 21 - Funções de Comunicação com SIM900. Fonte: o autor. Os comandos “AT” utilizados para atender a todos os requisitos de comunicação com o SIM900 estão disponíveis em anexos. Primeiramente, através do método Sim900_warm_up, o sistema liga automaticamente o SIM900, verifica o nível do sinal e então define o tipo de acesso a rede. Em seguida, solicita os créditos do chip de telefonia celular utilizado e então inicializa a conexão PDP (Packet Data Protocol) a fim de obter um endereço para se conectar a rede IP. Conectado a rede, o próximo passo e conectar com o servidor onde está a Aplicação Web de Monitoramento e então enviar o valor de créditos para armazenamento. No quadro 22 é apresentado o código da rotina principal do sistema embarcado do GSM. Na rotina principal a lógica estabelecida é de que o sistema deve primeiramente atualizar a data e hora. Esse processo é executado solicitando o serviço de conexão do SIM900 ao servidor do Observatório Nacional através do domínio “a.ntp.br”, onde o mesmo retorna ao sistema embarcado os valores de data e hora atualizados. Em seguida, solicita o CSQ (nível do sinal) novamente e, dentro de um laço de repetição, executa os mesmos processos para todos os dispositivos encontrados no barramento RS-485 anteriormente. Para cada Dispositivo encontrado o sistema embarcado faz uma verificação ao solicitar a concentração de NH³ atual, se não haver erro na leitura armazena o valor, caso contrário armazena um erro e então envia os dados para a Aplicação Web de Monitoramento. O processo para “alimentar” o Whatchdog Timer só é executado caso o sistema envie os dados para o servidor, caso contrário o contador irá “estourar” seu tempo limite e o sistema embarcado irá reiniciar.
  • 95. 94 Quadro 22 - Rotina Principal do Sistema Embarcado GSM. Fonte: o autor.
  • 96. 95 O último processo executado pelo sistema embarcado do GSM é o de verificar qual é o valor da concentração de NH³ medido pelo Dispositivo. Neste caso, se este valor chegar a 25 ppm, o sistema imediatamente deve enviar uma mensagem ao número de celular cadastrado, avisando o usuário sobre a situação. Deve-se ressaltar que o valor limite atribuído para o sistema enviar aviso por SMS é diferente para cada situação, como, idade do lote e cama de frango. Todos os processos citados são executados a um intervalo de tempo de aproximadamente 30 segundos, dependendo do tempo de resposta do SIM900 a cada serviço solicitado, e o programa também realiza a verificação dos Dispositivos no barramento RS-485 a cada 10 minutos.
  • 97. 96 5 RESULTADOS O sistema desenvolvido foi implementado gerando resultados satisfatórios. Como já mencionado, a aplicação básica para testes foi o monitoramento do gás amônia, com aquisição de dados em intervalos de 250 milissegundos e envio dos dados para visualização na internet e, caso necessário no celular, em intervalos de 10 segundos. Este capítulo tem por objetivo apresentar os resultados obtidos nas fases de testes em laboratório e análise do monitoramento dos dados medidos em campo. Primeiramente realizou-se testes de aquisição e processamento dos dados e comunicação entre os Módulos GSM e Dispositivo e Aplicação Web de Monitoramento, em laboratório. Em seguida, o trabalho foi conduzido então ao processo de monitoramento dos dados com os módulos atuando diretamente no aviário. 5.1 AQUISIÇÃO E PROCESSAMENTO DOS DADOS Para a realização dos testes de aquisição e processamento do sinal, foi verificada a concentração de gás amônia através de um medidor portátil Gas Alert NH³, devidamente calibrado, em um ambiente fechado, especificamente uma caixa contendo uma solução de amoníaco 10% misturada em água, e o valor constatado no medidor, em paralelo, foi comparado com o valor obtido do dispositivo, como ilustra a fotografia 6. Fotografia 6 - Testes Gás Alert NH3 e Dispositivo. Fonte: o autor. Deve-se lembrar que o sistema permite uma visualização local dos dados obtidos através de um LCD. Foi verificado que o valor da concentração registrado no dispositivo aumentou gradativamente ao perceber a presença de NH³ no ambiente tendo um tempo de
  • 98. 97 resposta muito rápido, menos de 3 segundos, inicialmente, não correspondendo ao valor constatado no medidor que tem um tempo de resposta mais lento, em torno de 8 segundos. Logo após a estabilização dos valores, pode-se constatar então que eles estavam tendendo a se igualar, tendo uma pequena variação da referencia (medidor portátil) para o dispositivo desenvolvido, variando de 3 – 5 ppm. Segundo dados do fabricante do sensor, essa diferença deve ser considerada, pois, para determinado valor em ppm e temperatura ambiente, o sinal do sensor varia. O gráfico 2 ilustra esta situação, onde para 10 ppm, num intervalo de 3 a 9 minutos, o sensor assume valores diferentes. Gráfico 2 - Sensor Response Pattern. Fonte: Figaro Engineering Inc., 2010. O processo de aferição do Dispositivo foi executado por um período de 5 dias onde os valores foram comparados, visualizando o LCD e Medidor Portátil, constantemente. Chegou- se a conclusão de que o funcionamento do sensor no sistema embarcado do Dispositivo está correto, pois na mudança de ar limpo para concentração de gás amônia no ambiente e no processo contrário, o padrão de resposta obtido seguiu o padrão de resposta típico do sensor, definição esta dada pelo fabricante, sendo assim, pode-se dizer que a aferição foi bem sucedida. 5.2 COMUNICAÇÃO ENTRE DISPOSITIVO E GSM Os drivers RS-485, responsáveis por realizar a troca de informações entre os módulos, se comunicam com os microcontroladores através da interface UART. Na etapa de testes de comunicação entre os módulos foi utilizado o modo Debugger da keil uVision 4, que possibilita ao programador uma visualização detalhada dos processos executados pelo programa, para poder observar o fluxo de dados no buffer das UART’s. Foram dois os
  • 99. 98 problemas encontrados para serem resolvidos, obter sucesso nessa comunicação e transmitir os dados sem perda de informação. Como a troca de informações é constante, há a necessidade de zerar o buffer após cada envio de dados. Mas isso não foi o suficiente, pois nem sempre o Dispositivo irá responder a uma requisição do GSM e quando isso ocorre o buffer da UART do Dispositivo ainda permanece com dados, prejudicando assim a leitura na próxima requisição solicitada pelo GSM. A solução encontrada foi a de, dentro do método que gera a interrupção da UART, implementar uma lógica para verificar o primeiro byte e o tamanho do pacote recebido. Se os valores não forem iguais ao esperado o sistema deve limpar o buffer. A grosso modo, o sistema embarcado do Dispositivo deve ler o buffer, limpá-lo antes de verificar se há a necessidade de retornar dados e, se retornar, limpá-lo novamente. No segundo problema encontrado, a variável que armazena o valor da concentração de NH³ é do tipo short, ou seja, ocupa 2 bytes no buffer pois armazena números inteiros de 16 bits. Seria impossível enviar esse valor no Dispositivo e recuperá-lo depois no GSM sem erro, certamente o valor recebido seria diferente do enviado. Esse problema foi solucionado realizando operações de deslocamento e lógica de bits, assim, no Dispositivo o número inteiro de 16 bits se tornou dois de 8 bits para ser enviado, e no GSM os dois números de 8 bits se tornaram novamente um de 16 bits para ser armazenado sem diferença de valores. Quadro 23 - Operações de Deslocamento e Lógica de Bits na Variável NH³. Fonte: o autor. Também foi observado que o tipo da variável que armazena o valor de concentração NH³ deve ser igual tanto no Dispositivo como no GSM, caso contrário o erro permaneceria. 5.3 COMUNICAÇÃO ENTRE GSM E APLICAÇÃO WEB DE MONITORAMENTO Como visto anteriormente, o sistema embarcado do GSM solicita os serviços desejados ao SIM900 enviando comandos “AT” e ele responde a essa solicitação, isso através da interface UART. O procedimento adotado para verificar se o SIM900 estava atendendo aos serviços solicitados foi o mesmo utilizado no item 5.2, modo Debugger, procedimento este, que possibilitou observar o fluxo de dados no buffer da UART.
  • 100. 99 A conexão de dados entre o SIM900 e o servidor é realizada por meio de uma rede IP externo, necessário para o serviço utilizado, que é o de acesso à internet. Para isso utilizou-se do recurso Virtual Server (Servidor Virtual), disponível no roteador da empresa Altem, que permite aos usuários e tecnologias de comunicação, como GPRS, ter acesso a serviços da rede local do próprio usuário. No Servidor Virtual é que a Aplicação Web de Monitoramento ficou armazenada, para tal feito houve a necessidade de acessar a página de configuração do roteador da empresa Altem, ver apêndices, onde definiu-se uma porta pública do roteador para redirecionar para uma porta privada específica e um endereço IP da rede local (IP do computador onde o servidor TCP e Apache Tomcat são executados), para duas regras definidas. A primeira é definida para comunicação via protocolo TCP com o SIM900, onde a porta 4550 do equipamento é redirecionada para tal. E a segunda é definida para comunicação via protocolo HTTP com o usuário, onde a porta 80 do equipamento é redirecionada para tal. Com o Servidor Virtual pronto para uso, iniciou-se os testes de conexão com o SIM900. Nesta etapa tudo funcionou perfeitamente, pois antes, realizou-se a verificação de todas as respostas aos serviços solicitados para atender aos requisitos de gerenciamento de comunicação com o SIM900, apresentado no Diagrama 15. Deve-se ressaltar que ao solicitar qualquer serviço ao SIM900 um tempo de resposta deve ser respeitado, dependendo do serviço, e esse tempo foi determinado observando o fluxo de dados no buffer na UART. Concluído a fase de testes em laboratório, iniciou-se as atividades para a realização da análise do monitoramento dos dados em campo. 5.4 ANÁLISE DO MONITORAMENTO DOS DADOS MEDIDOS EM CAMPO Um dos requisitos básicos para operação do sistema desenvolvido é que o aviário onde os módulos serão instalados deve estar localizado em uma área de abrangência de uma operadora de telefonia celular. Para o projeto em questão, o serviço GSM/GPRS foi contratado sob o formato pré-pago da empresa CLARO. Para os módulos poderem atuar no aviário sem qualquer tipo de dano físico houve a necessidade de acomoda-los em uma caixa plástica com tampa, deixando-os livres de qualquer contato com o ambiente. Em virtude disso, o sensor passou a ser conectado ao módulo Dispositivo por meio de um cabo, ficando a 2 metros de distância da mesma, com quatro conexões, Vh, Vc, GND Vh e GND Vc e, uma conexão para blindagem, GND, a fim
  • 101. 100 de evitar interferências no processo de medição. A fotografia 7 ilustra os módulos acomodados dentro da caixa pronta para ser fechada e levada ao aviário. Fotografia 7 - Caixa com os Módulos Dispositivo e GSM. Fonte: o autor. O aviário, onde foram instalados os módulos para a realização desta etapa do trabalho, está localizado a aproximadamente 7500 metros de distância da cidade de Luzerna. A cama de frango atual dele é reutilizada (está no quarto lote de frangos). No aviário, a caixa com os módulos pôde ser fixada na parede e o sensor em um ponto estratégico, em torno de 60 centímetros de altura em relação à cama do frango. Na primeira tentativa de telemetria o processo falhou, pois no local o CSQ (nível do sinal) da operadora CLARO varia de 5-8 dBm e o valor mínimo para o processo de telemetria funcionar perfeitamente é 10 dBm. Com o objetivo de melhorar o sinal, a solução foi verificar a melhor posição e instalar uma antena externa. Ela ficou a aproximadamente 5 metros de altura em relação ao solo, ajustando o nível do sinal para 11 dBm. A fotografia 8 ilustra a parte interna do aviário com os módulos e sensor instalados e a parte externa onde foi posicionada e fixada a antena. Fotografia 8 - Módulos Instalados no Aviário. Fonte: o autor.
  • 102. 101 O sistema pôde ser testado com os módulos atuando no aviário por cinco dias. Nesse intervalo de dias apresentou desempenho que superou as expectativas, pois todos os critérios estabelecidos no desenvolvimento do mesmo foram atendidos. A figura 11 apresenta os registros de concentração de NH³ no aviário medidos de ‘31-10-2014’ a ’04-11-2014’. Figura 11 - Dados de Concentração de NH³ Medidos no Aviário. Fonte: o autor. Como mencionado no item 2.3, nos ambientes produtivos de frangos de corte os limites aceitáveis de concentração de NH³ a partir da quarta semana não podem exceder o valor de 50 ppm. Desta forma, o limite de concentração de NH³ estabelecido no sistema foi de 45 ppm, devido a margem de erro a ser considerada no processo de medição, que é de 5 %. Ao se igualar a este valor, o mesmo deve enviar um SMS ao responsável pela manutenção do aviário avisando-o da situação atual de gás amônia no ambiente, para então ele poder tomar as medidas de controle necessárias. Fotografia 9 - SMS de Aviso. Fonte: o autor. Como exemplo, pode-se visualizar na fotografia 9 que o sistema enviou automaticamente um SMS de aviso para o número de celular cadastrado ao medir 50 ppm para o valor da concentração de NH³ no ambiente.
  • 103. 102 6 CONCLUSÃO O presente trabalho tem como contribuições finais o monitoramento do gás amônia em aviários, de forma a observar sua concentração em tempo real e as variações com o passar do tempo, armazenando os dados digitais obtidos, possibilitando ao integrado adotar medidas de controle em tempo hábil. A fim de fornecer os dados que alimentarão o sistema de gerência, a realização da leitura e armazenamento dos dados se dá de forma automática com a integração software- hardware proposta. Essa integração, principal parte a ser estudada uma vez que a aplicação web a ser desenvolvida irá trabalhar em cima dos dados obtidos. Por motivos favoráveis ao projeto e ao usuário do sistema, como, ser um sistema de cobertura global, de conectividade instantânea, transmissão de dados segura e em alta velocidade, menor custo e compatibilidade, optou-se por utilizar a tecnologia GSM/GPRS que é um tipo de comunicação sem fio. Observando os documentos de especificação de requisitos elaborados neste trabalho, pode-se então dar inicio a implementação e testes do sistema. O que determinou a escolha dos componentes de hardware junto à empresa Altem Tecnologia foi o fator aplicabilidade aliado a qualidade, funcionalidade e eficiência. Este trabalho vem ao encontro dos objetivos do curso de Engenharia de Computação, que visa capacitar profissionais para atuar em processos de automação, integrando aspectos relacionados ao desenvolvimento e gerência de projetos de hardware e software, colaborando de forma decisiva em vários campos onde se aplicam esses processos. 6.1 SUGESTÕES DE TRABALHOS FUTUROS Como ações em potenciais, para trabalhos futuros pode-se apontar o aprimoramento deste trabalho com a adição de mais sensores ao processo de aquisição de dados, no mínimo três espalhados em pontos estratégicos dentro do aviário. Esse processo poderia ser feito utilizando o sistema 1-Wire, onde possibilita a comunicação digital entre um controlador e dispositivos da série 1-Wire, tais como os sensores, seguindo o padrão mestre escravo. Dessa maneira a informação se torna mais precisa, pois dentro dos aviários a concentração de NH³ varia de um ponto para outro em função da ventilação e variáveis ambientais como temperatura e umidade.
  • 104. 103 Outro fator importante a ser mencionado é referente ao sinal de telefonia celular no local onde o sistema desenvolvido possa ser implantado. Como mencionado, o processo de telemetria só funciona se existir um sinal acima ou igual a 10 dBm, e os aviários normalmente estão localizados fora do perímetro urbano onde muitas vezes o sinal é ruim (menos de 10 dBm) ou até nem existe (0 dBm) e nem sempre esse problema é solucionado com apenas a instalação de uma antena externa. A fim de obter uma boa qualidade no sinal de telefonia celular nesses locais, pode-se instalar um repetidor de sinal. Para isso, o melhor posicionamento da antena externa, de preferências no ponto mais alto do terreno, aumenta a captação do sinal que é amplificado e distribuído pela antena interna garantindo qualidade na comunicação via SMS e conexão com a internet. Atualmente existem, no mercado, repetidores que distribuem sinal para vários aparelhos ao mesmo tempo em uma área de até 2000 m² com um custo médio de instalação de R$1.000,00. A solução definida para no caso de ocorrer uma perda de comunicação do SIM900 com o servidor seria a de acoplar um slot para cartão micro SD no módulo Dispositivo e implementar uma lógica no sistema embarcado para quando esta situação ocorrer, o sistema armazenar os dados e envia-los para a Aplicação Web de Monitoramento quando o sinal se estabilizar. Este sistema de monitoramento também poderia ser integrado a um sistema de controle automatizado, facilitando ao integrado todo o processo de manutenção no aviário e uma base de dados mais detalhada, com armazenamento de, por exemplo, ganho de peso do frango em função da concentração de NH³ e temperatura ambiente.
  • 105. 104 REFERÊNCIAS ARC Eletronics. RS422 Balanced Differential Drivers 2000. Disponível em: <http://www. arcelect.com/rs422.htm>. Acesso em 28 ago. 2014. BALIEIRO, F. A. H. Loja Virtual Utilizando Interface WEB/SMS. 2008. Monografia – Universidade Federal do Rio de Janeiro - Escola Politécnica Departamento de Eletrônica e Computação, UFRJ, Rio de Janeiro, 2008. Disponível em: <http://monografias.poli.ufrj. br/monografias/monopoli10003133.pdf>. Acesso em 02 out. 2014. BAPTISTA, Manuel. Sistemas de Instrumentação. 2005. Trabalho científico apresentado ao Departamento de Informática, curso de Engenharia de Sistemas e Informática da Escola Superior de tecnologia de Viseu. Disponível em: <http://www.estgv.ipv.pt/paginaspessoais /maeb/im/Teorica_Bibliografia/Cap_E_Sistemas%20de%20Aquisi%C3%A7%C3%A3o%20d e%20Dados/1-Introdu%C3%A7%C3%A3o /Texto%20de%20Estudo%20%20Sistemas %20de%20Instrumenta%C3%A7%C3%A3o%20-%20Capitulo%204.pdf> Acesso em: 13 out. 2014. BUCHMANN, M. Rafael; DA SILVA S. Bruno; PEREIRA C. Maurício. Padrões de Comunicação Serial Clássicos: RS-232, RS-422 e RS-485. 2013. Trabalho Instrumentação e Técnicas de Medidas – Universidade Federal do Rio de Janeiro – Escola Politécnica. Disponível em: <http://www.peb.ufrj.br/cursos/eel710/ProtocoloRS.pdf> Acesso em: 25 abr. 2014. CAELUM. Introdução ao JSF e Primefaces. 2006. Apostila do Curso FJ-22 – Lab. Java com Testes, JSF e Design Patterns. Disponível em: < http://www.caelum.com.br/apostila- java-testes-jsf-web-services-design-patterns/introducao-ao-jsf-e-primefaces/>. Acesso em 13 out. 2014. CENTRAL DE INTELIGÊNCIA DE AVES E SUÍNOS (CIAS). A Avicultura no Brasil. Concórdia, 2010. Disponível em: <http://www.cnpsa.embrapa.br/cias/index.php?option=com _content&view=article&id=13&Itemid=15> Acesso em: 01 out. 2014. CERVO, Amado; BERVIAN, Pedro. A pesquisa. In: CERVO, Amado; BERVIAN, Pedro. Metodologia Científica. São Paulo: Mc Graw-Hill do Brasil, 1976. p. 65-70. CORDEIRO, Jader S. T. Estudo Comparativo Entre os Frameworks de Mapeamento Objeto-Relacional Hibernate e Toplink. 2011. Monografia Apresentada ao Programa de Pós-Graduação em Desenvolvimento de Sistemas Para Web da Universidade Estadual de Maringá. Disponível em: <http://www.espweb.uem.br/site/files/tcc/2010/Jader%20dos%20 Santos%20Teles%20Cordeiro%20%20Estudo%20comparativo%20entre%20frameworks%20 de%20mapeamento%20objeto-relacional%20Hibernate%20e%20TopLink.pdf>. Acesso em: 13 out. 2014. CUNHA, Jônata Noronha. CORECHA, Josias Farias. MORAES, Marcelo C. Lima. Protótipo de um Site com a Localização dos Radares de Trânsito na Cidade de Belém. 2008. Monografia – Instituto de Ensinos Superiores da Amazônia, Curso de Engenharia da Computação, Belém, 2008. Disponível em: < http://www3.iesam-pa.edu.br/ojs/index.php/ computacao/article/viewFile/220/211 >. Acesso em: 14 nov. 2014.
  • 106. 105 CUNHA, Judson M. Protótipo de Rede Industrial Utilizando o Padrão Serial RS485 e Protocolo Modbus. 2000. Trabalho de conclusão de curso submetido à Universidade Regional de Blumenau para obtenção dos créditos na disciplina com nome equivalente no curso de Ciênicas da Computação – bacharelado. Disponível em: < http://dsc.inf.furb.br/ arquivos/tccs/monografias/2000-2judsonmichelcunhavf.pdf> Acesso em: 13 out. 2014. CURTIS, S.E. Environmental management in animal agriculture. Iowa: Iowa State University Press, 1983. 650 p. DANTAS, Tiago. Hardware e Software. 2008. Disponível em: <http://www.mundoed ucacao.com/informatica/hardware-software.htm>. Acesso em: 14 nov. 2014. DE ALMEIDA, José H. M. PHP com MySQL. 2012. Disponível em: < http://www.inf.ufsc .br/~fristtram/2464_php_com_mysql.pdf> Acesso em: 18 abr. 2014. DEITEL P. J.; DEITEL H. M. Ajax, Rich Internet Aplications e Desenvolvimento Web para Programadores, Pearson, 2008. DERMANN, G. Tiago; DELGADO, L. Jader; GONSALES, D. Alex; OJEDA, M. Francisco. Integração de Sensores a um módulo de Aquisição de Dados. Porto Alegre, 2013. Trabalho aceito para apresentação da 14ª mostra de pesquisa, ensino e extensão. – Instituto Federal de Educação, Ciência e Tecnologia do Rio Grande do Sul. Disponível em: <http://mostra.poa.ifrs.edu.br/2013/site/arquivos/trabalhos/ trab_118.pdf > Acesso em: 14 mai. 2014. FERNANDES, F. C.; FURLANETO, A. Riscos Biológicos em Aviários. In: Rev. Bras. Med. Trab., Belo Horizonte , Vol. 2 , n. 2 , abr-jun , 2004. p. 140-152. Figaro Engineering Inc. Tentative Product Information: TGS 2444 – for the detection ammonia. 2010. Disponível em: <http://www.figaro-gas-sensor.fr/pdf/TGS2444.pdf> Acesso em: 21 abr. 2014. FONSECA, J. J. S. Metodologia da pesquisa científica. Fortaleza: UEC, 2002. Apostila. GERHARDT, T. E; SILVEIRA, D. T. Métodos de Pesquisa. Porto Alegre: editora da UFRGS, 2009. Disponível em: <ftp://ftp.sead.ufrgs.br/Publicacoes/derad005.pdf>. Acesso em: 18 ago. 2014. GUEDES, G. T. A. UML - Uma abordagem prática. São Paulo: Novatec, 2004. p319. GUIMARRÃES, Célio. Introdução a Linguagens de Marcação: HTML, XHTML, SGML, XML. São Paulo, 2005. Disponível em: <http://www.ic.unicamp.br/~celio/inf533/ docs/markup.html>. Acesso em 05 out. 2014. HOSPEDAGEM INTELIGENTE (MCO2). Os 3 servidores Web mais populares no Mundo. Disponível em: <http://www.1hospedagemdesites.com.br/os-3-servidores-web- mais-populares-do-mundo/>. Acesso em 02 out. 2013. IMALL. Icomsat. 2012. Disponível em: < http://imall.iteadstudio.com/im120417009.html >
  • 107. 106 Acesso em: 14 nov. 2014. KIOSKEA BRASIL. O Protocolo HTTP. 2013. Disponível em: <http://pt.kioskea.net/con tents/266-o-protocolo-http>. Acesso em 28 out. 2014. KÖCHE, José Carlos. Tipos de pesquisa. In: KÖCHE, José Carlos. Fundamentos de Metodologia Científica. 14. ed. rev. e ampl. Petrópolis: Vozes, 1997. p. 122-126. LEITE, A. GIRARDI, R. A Process for Multi-Agent Domain and Application Engineering: the Domain Analysis and Application Requirements Engineering Phases, Proceedings of the 11th International Conference on Enterprise Information Systems, Ed. INSTIIC. Milan, Italy, p. 156-161, 2009. LOBO, Fábio. O que é front-end e back-end? 2011. Disponível em: <http://fabiolobo.com .br/o-que-e-front-end-e-back-end.html> Acesso em: 14 nov. 2014. LUCKOW, Décio H; MELO, Alexandre A. Programação Java para a Web. São Paulo: Novatec Editora, 2010. MCKIE, Stewart. “Everything you wanted to know about Client/Server computing but were afraid to ask”. 1997. Disponível em: <http://www.duke.com/controller/Issues/DecJan /Clientse.htm>. Acesso em: 04 out. 2014. MIRAGLIOTTA, M.Y. Avaliação dos níveis de amônia em dois sistemas de produção de frangos de corte com ventilação e densidade diferenciados. 2000. 122 f. Dissertação (Mestrado em Construções Rurais e Ambiência) - Faculdade de Engenharia Agrícola, UNICAMP, Campinas, 2000. Disponível em: <http://www.bibliotecadigital.unicamp.br/doc ument/?code=vtls000222783>. Acesso em 01 out. 2014. NetBeans E-Commerce Tutorial. Designing Application. 2013. Disponível em: < https://netbeans.org/kb/docs/javaee/ecommerce/design.html> Acesso em: 13 jul. 2014. NETCRAFT. October 2013 Web Server Survey. 2013. Disponóvel em: <http://news. netcraft.com/>. Acesso em 04 out. 2014. NXP Semiconductors N. V. LPC 17xx Series – Product Data Sheet. 2010. Disponível em: <http://www.nxp.com/products/microcontrollers/cortex_m3/series/LPC1700.html#overview> Acesso em: 21 abr. 2014. OLIVEIRA, M. C. Efeito de dietas contendo subprodutos de arroz formuladas com base nos conceitos de proteína bruta e ideal sobre a qualidade química da cama de frango. In: Arq. Inst. Biol., v. 71, Supl., 2004. OLIVEIRA, Paulo. A. V.; MONTEIRO, Alessandra N. T. R. Emissão de Amônia na Produção de Frangos de Corte. 2013. Artigo Embrapa Suínos e Aves. Disponível em: < http://ainfo.cnptia.embrapa.br/digital/bitstream/item/91032/1/final7197.pdf>. Acesso em: 02 nov. 2014. OMG. Systems Modeling Language. 2012. Disponível em: <http://www.omg.org/spec /SysML/1.3/PDF/> Acesso em: 22 out. 2014.
  • 108. 107 OMG. Business Process Model & Notation. [S.l.], 2013. Disponível em: < http://www.omg. org/spec/BPMN/2.0.2/PDF/>. Acesso em: 22 out. 2014. PFLEEGER, Shari Lawrence; Engenharia de Software: Teoria e Prática. Tradução Dino Franklin. 2. ed. São Paulo: Pretience Hall, 2004.537 p. Tradução de: Software Engineering. PEREIRA, Fábio. Tecnologia ARM: microcontroladores de 32 bits. São Paulo: Érica, 2007, p.447. PRESSMAN, Roger Simon; Engenharia de Software.Tradução José Carlos Barbosa dos Santos; Pearson Makron Books, 1995. 1056p. Tradução de: Software Engineering:A Practitioner’s Approach. PROJECTS WIKI. Arquitetura Física. 2011. Disponível em: < http://ihuru.fe.up.pt/ldso /1011/doku.php?id=wikiaware:ra:fisica:intro>. Acesso em: 18 ago. 2014. REZENDE, R. Conceitos Fundamentais de Banco de Dados. 2006. Disponível em: <http://www.devmedia.com.br/conceitos-fundamentais-de-banco-de-dados/1649>. Acesso em: 03 out. 2014. ROVER, Ardinete; PEREIRA, Débora E. S. Diretrizes para Elaboração de Trabalhos Científicos: apresentação, elaboração de citações e referências de trabalhos científicos. Joaçaba: Unoesc, 2013.143p. SILVA, Bruno L. R. Sistema de Controle via SMS do Alarme Automotivo. 2012. Trabalho apresentado a banca examinadora do curso de Engenharia da Computação da FATECS – Faculdade de Tecnologia e Ciências Sociais Aplicadas – Centro Universitário de Brasília. Disponível em: <www.repositorio.uniceub.br> Acesso em: 13 out. 2014. TANENBAUM, Andrew S. Computer Networks. New Jersey, US: Prentice Hall, 2004. 891p TATEOKI, Getulio T. Monitoramento de Dados Via Internet Baseado em Telefonia Celular. 2007. Dissertação submetida à faculdade de Engenharia Ilha Solteira – UNESP como parte dos requisitos para obtenção do título de mestre em Engenharia Elétrica. Disponível em: < http://www.feis.unesp.br/Home/departamentos/engenhariaeletrica/pos- graduacao/191-dissertacao_getulio_taruo_tateoki.pdf >. Acesso em: 08 set. 2014. TORRES, Gabriel. Como o Protocolo TCP/IP Funciona. 2007. Disponível em: <http://www .clubedohardware.com.br/artigos/1351>. Acesso em 07 out. 2014. TRIVIÑOS, A. N. S. Introdução à pesquisa em ciências sociais: a pesquisa qualitativa em educação. São Paulo: Atlas, 1987. WAZLAWICK, Raul S. Análise e Projeto de Sistemas de Informação Orientados a Objetos. 2 ed. Editora Elsevier, 2011. WENDLING, Marcelo. Sensores. Guaratinguetá, 2010. Disponível em: < http://www2.feg. unesp.br/Home/PaginasPessoais/ProfMarceloWendling/4---sensores-v2.0.pdf>. Acesso em 09
  • 109. 108 out. 2014. ZANATTA, Rodrigo. A. Análise do Controle de Amônia em Aviários. 2007. Monografia (Pós-Graduação em Engenharia de Segurança do Trabalho) – Universidade do Extremo Sul Catarinense, UNESC, Criciúma, 2007. Disponível em: <http://www.bib.unesc.net/biblioteca /sumario/000030/000030F1.pdf>. Acesso em: 01 out. 2014. ZELENOVSKY, Ricardo; MENDONÇA, Alexandre. Hardware e Interfaceamento. Rio de Janeiro: MZ Editora Ltda, 2002. p.1031.
  • 111. 110 APÊNDICE A – SCRIPT DO MODELO FÍSICO DO BANCO DE DADOS. CREATE DATABASE IF NOT EXISTS `telemetria_amonia`; USE `telemetria_amonia`; -- MySQL dump 10.13 Distrib 5.5.16, for Win32 (x86) -- -- Host: localhost Database: telemetria_amonia -- ------------------------------------------------------ -- Server version 5.5.23 -- -- Table structure for table `modulo_gsm` -- DROP TABLE IF EXISTS `modulo_gsm`; CREATE TABLE `modulo_gsm` ( `id_gsm` int(4) NOT NULL, `nome_gsm` varchar(25) NOT NULL, `csq` int(3) DEFAULT NULL, `credito` varchar(250) DEFAULT NULL, `criado` datetime NOT NULL, `modificado` datetime DEFAULT NULL, PRIMARY KEY (`id_gsm`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; -- -- Table structure for table `dispositivo` -- DROP TABLE IF EXISTS `dispositivo`; CREATE TABLE `dispositivo` ( `id_dis` int(4) NOT NULL, `id_usu` int(4) NOT NULL, `id_gsm` int(4) NOT NULL, `nome_dis` varchar(40) NOT NULL, `conexao` datetime DEFAULT NULL, `criado` datetime NOT NULL, `modificado` datetime DEFAULT NULL, `id_gsm_id_gsm` int(11) DEFAULT NULL, `id_usu_id_usu` int(11) DEFAULT NULL, PRIMARY KEY (`id_dis`), KEY `FK22C5B091DAB784FB` (`id_gsm`), KEY `FK22C5B091CBF95AD4` (`id_usu`), KEY `FK22C5B0913DA20420` (`id_usu_id_usu`), KEY `FK22C5B091B152979D` (`id_gsm_id_gsm`), CONSTRAINT `dispositivo_ibfk_1` FOREIGN KEY (`id_usu`) REFERENCES `usuario` (`id_usu`), CONSTRAINT `dispositivo_ibfk_2` FOREIGN KEY (`id_gsm`) REFERENCES `modulo_gsm` (`id_gsm`), CONSTRAINT `FK22C5B0913DA20420` FOREIGN KEY (`id_usu_id_usu`) REFERENCES `usuario` (`id_usu`), CONSTRAINT `FK22C5B091B152979D` FOREIGN KEY (`id_gsm_id_gsm`) REFERENCES `modulo_gsm` (`id_gsm`), CONSTRAINT `FK22C5B091CBF95AD4` FOREIGN KEY (`id_usu`) REFERENCES `usuario` (`id_usu`), CONSTRAINT `FK22C5B091DAB784FB` FOREIGN KEY (`id_gsm`) REFERENCES `modulo_gsm` (`id_gsm`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; -- -- Table structure for table `registros_amonia` -- DROP TABLE IF EXISTS `registros_amonia`; CREATE TABLE `registros_amonia` (
  • 112. 111 `id_reg_amonia` int(4) NOT NULL AUTO_INCREMENT, `id_dis` int(4) NOT NULL, `data_reg` date NOT NULL, `hora_reg` time NOT NULL, `conc_medida_reg` int(3) DEFAULT NULL, `conc_menor` int(3) DEFAULT NULL, `conc_maior` int(3) DEFAULT NULL, `data_hora_cme` datetime DEFAULT NULL, `data_hora_cma` datetime DEFAULT NULL, PRIMARY KEY (`id_reg_amonia`), KEY `FK909FA7E230CB05AE` (`id_dis`), CONSTRAINT `FK909FA7E230CB05AE` FOREIGN KEY (`id_dis`) REFERENCES `dispositivo` (`id_dis`), CONSTRAINT `registros_amonia_ibfk_1` FOREIGN KEY (`id_dis`) REFERENCES `dispositivo` (`id_dis`) ) ENGINE=InnoDB AUTO_INCREMENT=16 DEFAULT CHARSET=utf8; -- -- Table structure for table `usuario` -- DROP TABLE IF EXISTS `usuario`; CREATE TABLE `usuario` ( `id_usu` int(4) NOT NULL AUTO_INCREMENT, `nome_usu` varchar(40) NOT NULL, `usuario` varchar(25) NOT NULL, `senha` varchar(25) NOT NULL, `email` varchar(40) DEFAULT NULL, `telefone` varchar(13) DEFAULT NULL, `endereco` varchar(100) NOT NULL, `cpf` varchar(14) DEFAULT NULL, `nivel` int(1) NOT NULL, `ativo` tinyint(1) NOT NULL, `criado` datetime NOT NULL, `modificado` datetime DEFAULT NULL, `confirmarSenha` varchar(255) DEFAULT NULL, PRIMARY KEY (`id_usu`), UNIQUE KEY `usuario` (`usuario`) ) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8;
  • 113. 112 APÊNDICE B – CONFIGURAÇÃO DO SERVIDOR VIRTUAL NO ROTEADOR D-LINK DIR-600.
  • 115. 114 ANEXO A – QUADRO COM OS CÓDIGOS “AT” DE ACESSO E CONFIGURAÇÃO UTILIZADOS PARA GERENCIAMENTO DO SIM 900. COMANDO RESPOSTA DESCRIÇÃO “AT AT” “OK” AT duas vezes para reconhecer baudrate. “ATE0” “ATE0rnrnOK” Desabilita eco dos comandos AT. “AT+CSQ” “+CSQ:<rssi><ber>” Busca intensidade do sinal na rede. “AT+CREG=0” “OK” Define o tipo de acesso a rede não solicitando o código resultado. “AT+CREG?” “+CREG: <n><status> OK” Aguarda o registro na rede. “AT+CUSD=1,”*544”,15” “+CUSD: 0,”String” Solicita o valor dos créditos pré- pago. “AT+CIPMUX=1” “OK” Ativa múltiplas conexões (multi IP). “AT+CSTT?” “CMNET” Verifica APN. “AT+CSTT=”claro.com.br” ,”claro”,”claro”” “OK” Configura provedor APN para chip da operadora CLARO. “AT+CSTT?” “claro.com.br” Verifica APN após configurá-lo. “AT+CIICR” “OK” Solicita conexão com GPRS. “AT+CIFSR” “IP <000.000.000.000>” Comando para obter um endereço IP local. “AT+CIPSTART=1,”TCP” ,”189.8.207.51”,”4550”” “CONNECT OK” Cria conexão com o servidor TCP onde está localizada a Aplicação Web de Monitoramento. “AT+CIPSEND=1” “SEND OK” Envia dados para o servidor. “AT+CIPSTART=2,”UDP” ,”a.ntp.br”,”123”” “CONNECT OK” Cria conexão com o servidor UDP do Observatório Nacional para solicitar a data e hora atual. “AT+CDNSCFG=”8.8.8.8” ,”8.8.4.4 ”” “OK” Envia comando de configuração do DNS. “AT+CDNSGIP=”a.ntp.br”” “+CDNSGIP: 1” Pergunta o IP do target pára o servidor DNS. “AT+CIPSEND=2” “+RECEIVE,3,48:rn” Envia solicitação para o servidor e aguarda retorno dos valores. “AT+CMGF=1” “OK” Solicita serviço de envio de dados por SMS. “AT+CMGS=”55DDD NUMERO”” “>” “+CMGS” Cadastra o número de celular que deve receber a mensagem. Após receber ‘>’ insere a mensagem. OBS: Após inserir a mensagem a ser enviada ao servidor e ao celular deve ser inserido o comando 26, que representa CTRL Z na tabela ASC II. Esse caractere indica ao SIM900 o término da mensagem. Os comandos estão apresentados no quadro em ordem de desenvolvimento para a correta execução do sistema embarcado do módulo GSM.