pontifÍcia universidade catÓlica do paranÁlaplima/ensino/tcc/concluidos/2019/...figura 31 -...
TRANSCRIPT
-
PONTIFÍCIA UNIVERSIDADE CATÓLICA DO PARANÁ
ESCOLA POLITÉCNICA
CURSO DE ENGENHARIA DE COMPUTAÇÃO
JOAN EMILIO DEITOS
IMPLEMENTAÇÃO FINAL
PRONTUÁRIO ELETRÔNICO PARA ENFERMIDADES PULMONARES EM
EQUINOS
Orientadora: Dra. Deborah Ribeiro Carvalho
Co orientador: Me. Bruno Campagnolo de Paula
Co orientador: Dr. Pedro Vicente Michelotto Júnior
CURITIBA
QUARTO BIMESTRE, 2019
-
JOAN EMILIO DEITOS
IMPLEMENTAÇÃO FINAL
PRONTUÁRIO ELETRÔNICO PARA ENFERMIDADES PULMONARES EM
EQUINOS
Trabalho de Conclusão de Curso apresentado ao Curso de Graduação em Engenharia de Computação da Pontifícia Universidade Católica do Paraná, como requisito parcial à obtenção do título de Engenheiro em Computação. Orientadora: Prof. Dra. Deborah Ribeiro Carvalho Co orientador: Me. Bruno Campagnolo de Paula Co orientador: Dr. Pedro Vicente Michelotto Júnior
CURITIBA
QUARTO BIMESTRE, 2019
-
AGRADECIMENTOS
Agradeço a todos os professores que me guiaram até o presente momento. Em
especial à professora Deborah Ribeiro Carvalho pela oportunidade de desenvolver
este trabalho. Agradeço, meus amigos e colegas Matheus Marassi, Fabio Albertasi,
Felipe Dias, Lucas Borges, Rômulo Lopes, Ívan Mori, e muitos outros que contribuíram
intelectualmente e emocionalmente durante essa jornada.
Agradeço ao meu sogro, Ubiratan; minha cunhada, Débora; aqueles que tenho como
meus avós de sangue, Ires e Valéria; aqueles que me receberam na família, Sueli,
Sônia, Solange e Mauri; e a toda minha família pela ajuda e apoio incondicional que
dedicam à mim.
Meu agradecimento especial aos meus pais, Clevi e Jacy, por tudo o que fizeram e
fazem por mim; meus irmãos, Jorge e Mateus, que sempre são grandes apoios para
mim; e as razões de minha dedicação diária, minha esposa Thelma e meus filhos
Bruna e Eduardo.
-
RESUMO
O prontuário constitui que um documento, que permite registrar dados vitais do paciente a partir da jornada de procedimentos e consultas realizados. Este registro pode ocorrer em papel ou meio digital. Por meio do prontuário eletrônico é possível reduzir erros, otimizar recursos, ampliar a segurança e facilitar o intercâmbio de dados entre dos diversos profissionais de saúde. A partir da evolução e capacidades dos dispositivos mobiles, esta tem constituído uma plataforma interessante para o desenvolvimento prontuário eletrônico. Situação que traz maior facilidade para a sua utilização durante a avaliação dos animais, dado o fato que esta não ocorre em um consultório tal como considerando pacientes humanos. O objetivo deste trabalho de conclusão de curso é prototipar um prontuário eletrônico de pacientes equinos para acompanhamento do sistema pulmonar em dispositivos mobile. Os dados coletados e armazenados serão utilizados para orientação e sugestões de exames clínicos, para o estabelecimento de diagnósticos.
Palavras-chave: Prontuário eletrônico. PEP. Equinos.
-
LISTA DE ILUSTRAÇÕES
Figura 1 - Diagrama em blocos do projeto ................................................................ 13
Figura 2 - Marketshare de sistemas operacionais móveis no Brasil .......................... 15
Figura 3 - Mapa de navegação do aplicativo ............................................................. 16
Figura 4 - Protótipo da tela de login e cadastro e edição dos usuários ..................... 17
Figura 5 - Protótipo do menu principal ...................................................................... 17
Figura 6 - Protótipos da tela de cadastro e busca de cavalo ..................................... 18
Figura 7 - Protótipo da tela de entrada de queixas .................................................... 19
Figura 8 - Protótipo da tela de exame ....................................................................... 20
Figura 9 - Protótipo da tela de sugestão de diagnóstico ........................................... 20
Figura 10 - Fluxograma do exame ............................................................................ 21
Figura 11 - Fluxograma do armazenamento do exame ............................................. 22
Figura 12 - Fluxograma de leitura da TAG no aplicativo ........................................... 23
Figura 13 – Desenho do protótipo da antena ............................................................ 25
Figura 14 - Circuito integrado EM4095 ...................................................................... 26
Figura 15 - Desenho esquemático do EM4095 ......................................................... 26
Figura 16 - Módulo ESP32 ........................................................................................ 27
Figura 17 - Fluxograma de leitura da TAG no hardware ........................................... 28
Figura 18 - Resultado dos testes de cadastro no banco de dados (1 de 2) .............. 34
Figura 19 - Resultado dos testes de cadastro no banco de dados (2 de 2) .............. 34
Figura 20 - Telas de cadastro e lista de cavalos cadastrados desenvolvidas ........... 35
Figura 21 - Tela de login e cadastro desenvolvidas .................................................. 35
Figura 22 - Resultado da criação de novo usuário .................................................... 36
Figura 23 - Tela desenvolvida de seleção de sintomas ............................................. 37
Figura 24 - Telas de exame desenvolvidas ............................................................... 38
Figura 25 - Fluxograma de teste de comunicação software-hardware – ESP32 ....... 39
Figura 26 - Terminal mostrando dados enviados e recebidos pelo ESP32 ............... 39
Figura 27 - Teste de integração aplicativo-hardware ................................................ 40
Figura 28 - Circuito conversor desenvolvido (Inferior) ............................................... 41
Figura 29 - Circuito conversor desenvolvido (Topo) .................................................. 41
Figura 30 - Antena desenvolvida ............................................................................... 42
Figura 31 - Versão final do hardware ........................................................................ 44
Figura 32 - Placa de circuito impresso do hardware integrado.................................. 44
-
Figura 33 - Defeito de fabricação (cobre não retirado completamente) .................... 47
Figura 34 - Defeito de fabricação (cobre retirado completamente) ........................... 48
Figura 35 - Falha de fabricação da antena ................................................................ 48
-
LISTA DE TABELAS
Tabela 1 - Cronograma do projeto ............................................................................ 28
Tabela 2 - Testes em caixa preta .............................................................................. 30
Tabela 3 - Testes em caixa branca ........................................................................... 31
Tabela 4 - Análise de riscos ...................................................................................... 32
Tabela 5 - Estrutura de dados de diagnóstico hipotético ........................................... 37
Tabela 6 - Características da antena ........................................................................ 42
Tabela 7 - Modelo de informações no sistema (Asma leve) ...................................... 46
-
LISTA DE ABREVIATURAS E SIGLAS
ABNT Associação Brasileira de Normas Técnicas
CE Comissão de estudos
CI Circuito integrado
H Henry – Grandeza de medição de indutores
IN Instrução normativa
ISO International Organization for Standardization
NBR Norma brasileira
PEP Prontuário eletrônico do paciente
PUCPR Pontifícia Universidade Católica do Paraná
UI User interface – Interface do usuário
UX User experience – Experiência do usuário
Ω Ohm – Grandeza de medição de resistência elétrica
-
SUMÁRIO
1 INTRODUÇÃO ............................................................................................. 11
2 DETALHAMENTO DO PROBLEMA ............................................................ 13
2.1 BANCO DE DADOS ..................................................................................... 13
2.1.1 Cloud Firestore ........................................................................................... 14
2.1.2 Firebase Authentication ............................................................................. 14
2.2 APLICATIVO ................................................................................................ 14
2.2.1 Mapa de navegação .................................................................................... 15
2.2.2 Protótipo do aplicativo ............................................................................... 16
2.2.2.1 Telas de login e cadastro .............................................................................. 16
2.2.2.2 Menu principal .............................................................................................. 17
2.2.2.3 Cadastro e busca de cavalos ....................................................................... 18
2.2.2.4 Telas do exame ............................................................................................ 19
2.2.3 Fluxogramas do aplicativo ........................................................................ 21
2.2.3.1 Exame .......................................................................................................... 21
2.2.3.2 Armazenamento do exame ........................................................................... 22
2.2.3.3 Leitura da TAG de identificação.................................................................... 23
2.3 HARDWARE ................................................................................................. 24
2.3.1 Antena ......................................................................................................... 24
2.3.2 Circuito conversor ...................................................................................... 25
2.3.3 Circuito microcontrolado ........................................................................... 27
2.3.4 Fluxograma do hardware ........................................................................... 27
3 CRONOGRAMA DO PROJETO ATUALIZADO .......................................... 28
4 PROCEDIMENTOS DE TESTE E VALIDAÇÃO DO PROJETO ................. 30
4.1 TESTES EM CAIXA PRETA ......................................................................... 30
4.2 TESTES EM CAIXA BRANCA ...................................................................... 31
5 ANÁLISE DOS RISCOS REVISADO ........................................................... 32
6 DESENVOLVIMENTO .................................................................................. 34
6.1 INTEGRAÇÃO APLICATIVO-BANCO DE DADOS ...................................... 34
6.2 PREENCHIMENTO GUIADO E SUGESTÃO DE DIAGNÓSTICO ............... 36
6.3 INTEGRAÇÃO APLICATIVO-HARDWARE .................................................. 38
6.4 CIRCUITO CONVERSOR ............................................................................ 40
6.5 ANTENA ....................................................................................................... 41
-
6.6 INTEGRAÇÃO DO HARDWARE ......... ERRO! INDICADOR NÃO DEFINIDO.
6.7 PERMANENCIA DE DADOS SEM ACESSO À INTERNET ......................... 44
6.8 NOVO MODELO DE EXAMES ..................................................................... 45
6.9 SISTEMA DE PREENCHIMENTO GUIADO ................................................ 45
6.10 SISTEMA DE SUGESTÕES DE DIAGNÓSTICOS ...................................... 46
7 PROBLEMAS ENCONTRADOS .................................................................. 47
7.1 PROBLEMAS COM HARDWARE ................................................................ 47
7.2 PROBLEMAS DE CRONOGRAMA .............................................................. 49
8 CONCLUSÃO............................................................................................... 50
8.1 CONSIDERAÇOES DE ROHS ..................................................................... 50
9 REFERÊNCIAS BIBLIOGRÁFICAS ............................................................ 51
-
11
1 INTRODUÇÃO
O prontuário é um instrumento, pelo qual, é possível registrar dados vitais do
paciente a partir da jornada de procedimentos e consultas realizados. Também,
protege o profissional da saúde, mantendo o registro de sua conduta. Este registro
pode ocorrer por meios físicos, como em fichas clínicas de papel, ou por meios digitais,
como planilhas ou softwares especializados.
Através do prontuário eletrônico do paciente (PEP), é possível reduzir erros,
otimizar recursos, ampliar a segurança e, ainda, facilita o intercâmbio de dados entre
diversos profissionais da saúde.
Com a evolução das capacidades dos dispositivos móveis (mobiles), como
smartphones ou tablets, estes vêm se tornando de grande interesse para o
desenvolvimento de plataformas acessíveis, bem como prontuários eletrônicos.
A capacidade de preencher um prontuário eletrônico, em um dispositivo mobile,
é especialmente interessante para profissionais da saúde animal, como, médicos
veterinários, os quais, por diversas vezes, não realizam consultas em um consultório.
Um dos fatores que torna o prontuário, seja ele físico ou eletrônico, um
instrumento de grande segurança, é a identificação única do paciente. Para nós, seres
humanos, existem opções de identificação única como o Cadastro de Pessoas Físicas
(CPF), matrícula da certidão de nascimento, etc. Em animais, uma forma amplamente
utilizada para identificação única, é através do implante de um circuito integrado (tag
de identificação) no próprio corpo do animal.
Este implante carrega informações sobre o animal, como um código de
identificação única, código do país, entre outros. A obtenção dos dados deste circuito
integrado ocorre através de sinais de radiofrequência.
Tendo como partida estas informações, em uma parceria entre os Programas
de Pós-Graduação em Ciência Animal (PPGCA), com participação da graduanda em
Medicina Veterinária, Thasla de Freitas Santi e do professor Dr. Pedro Vicente
Michelotto Jr., e em Tecnologia em Saúde (PPGTS) da Pontifícia Universidade
Católica do Paraná (PUCPR), é proposto neste projeto o desenvolvimento de um
aplicativo, para mobile, de prontuário eletrônico, com foco em doenças do trato
respiratório de equinos, em que dados obtidos serão compartilhados em uma base de
dados e o desenvolvimento de um leitor da tag de identificação que comunique-se
diretamente com o aplicativo.
-
12
Este documento está estruturado em Detalhamento do problema, onde são
apresentados uma visão geral do projeto; Cronograma do Projeto, onde é apresentado
os prazos deste desenvolvimento; Procedimentos de Teste e Validação do Projeto,
onde são descritos os processos de aceitação do projeto; Análise dos Riscos, uma
breve apresentação dos riscos do desenvolvimento; e Conclusão.
-
13
2 DETALHAMENTO DO PROBLEMA
Este projeto tem como foco o desenvolvimento de uma solução para médicos
veterinários realizarem exames e gerar diagnósticos para enfermidades no trato
respiratório de cavalos. Com foco em mobilidade, é proposto o desenvolvimento de
um aplicativo de prontuário eletrônico que possua um preenchimento da ficha clínica
inteligente e que apresente sugestões de diagnóstico, de acordo com os dados
inseridos. Para auxiliar na identificação dos animais, será desenvolvido um leitor de
tags de identificação, seguindo a norma técnica ABNT NBR 14766, que determina
aspectos técnicos que os dispositivos devem seguir.
O diagrama em blocos da Figura 1 representa como é subdividido o
desenvolvimento deste trabalho.
Figura 1 - Diagrama em blocos do projeto
Fonte: O autor
São duas as macros partes do projeto: O aplicativo, composto pela modelagem
do banco de dados e desenvolvimento do gestor de preenchimento inteligente do
prontuário e motor de inferência para sugestão de diagnóstico; e o leitor de tags de
identificação, composto por um circuito controlador, um circuito conversor e uma
antena. A interface de comunicação entre os dois dispositivos se dará utilizando a
tecnologia Bluetooth.
2.1 BANCO DE DADOS
Para armazenamento de informações compartilháveis deste trabalho, foi
escolhido os serviços Firebase, disponibilizados pela Google.
-
14
Dentre os diversos serviços oferecidos, os que interessam neste
desenvolvimento são o Cloud Firestore e o Firebase Authentication. Além disso, o
framework IONIC oferece suporte nativo a esses serviços.
2.1.1 Cloud Firestore
É um serviço de armazenamento na nuvem, flexível e escalonável, que utiliza
NoSQL, como linguagem. Possui um plano de cota gratuita, para até cinquenta mil
leituras e vinte mil gravações por dia.
Por se tratar de um banco de dados que utiliza NoSQL, sua utilização torna-se
bastante interessante, pois, em um prontuário de uso prático, grande parte dos
campos acabam sendo negligenciados, por não haver necessidade de coletá-los; e
utilizando esta linguagem, é possível inserir apenas os dados pertinentes para aquele
exame, sem haver a necessidade de consumir a memória do servidor com campos
com valores nulos, ou padrões, e ainda economiza o volume da dados que precisam
ser carregados ou enviados pelo dispositivo móvel.
2.1.2 Firebase Authentication
O Firebase Authentication é uma forma prática, rápida e segura de implementar
um processo de autenticação de usuários ao aplicativo. Apesar de neste projeto
utilizar apenas autenticação por e-mail e senha, é oferecido suporte para autenticar
via conta do Google, Facebook, Twitter, Microsoft, entre outros.
2.2 APLICATIVO
Este módulo é o principal, em ponto de vista como produto do projeto. Será
este módulo ao qual os outros deverão ser integrados. Sendo este o aplicativo em si,
todos os conceitos de UI e UX serão aplicados a ele.
O aplicativo será desenvolvido utilizando o framework IONIC, versão 4, pois
nele é possível desenvolver tanto para smartphones com sistema operacional Android
(Google) quanto iOS (Apple).
A proposta é que o aplicativo seja acessível para maior parte dos médicos
veterinários e segundo dados disponibilizados no site statcounter.com na Figura 2,
-
15
entre abril de 2018 e março de 2019, no Brasil, o percentual de usuário de Android é
de 83,59% e de iOS (Apple) de 14,24%.
Figura 2 - Marketshare de sistemas operacionais móveis no Brasil
Fonte: statcounte.com
O IONIC é um framework é um conjunto de ferramentas de código aberto para
desenvolvimento de performance e alta qualidade utilizando tecnologias web, como,
HTML, CSS, JavaScript, etc.
2.2.1 Mapa de navegação
Para o aplicativo, foi elaborado o mapa de navegação, como mostrado a Figura
3 a seguir.
-
16
Figura 3 - Mapa de navegação do aplicativo
Fonte: O autor
Através do mapa de navegação pode-se ter uma visão geral de como será a
navegação dentro do aplicativo, assim como quantas e quais telas há no plano de
desenvolvimento. Os protótipos das telas, bem como as descrições das telas, estão
descritos na seção 2.2.2 deste documento.
2.2.2 Protótipo do aplicativo
Um protótipo é uma representação ou implementação concreta, porém parcial,
do design de um sistema, (BENYON, 2010). Além disso, um protótipo é uma
ferramenta de grande utilidade nas etapas iniciais de um projeto e serve como guia
para quem desenvolve e como ferramenta para validação em etapas iniciais, para
quem é o cliente do projeto.
Sendo assim, foram desenvolvidos protótipos de para validação do
desenvolvimento do aplicativo. A navegação entre as diferentes telas descritas nesta
seção seguem o - Mapa de navegação do aplicativo da Figura 3.
2.2.2.1 Telas de login e cadastro
A tela de login é a tela inicial para novos usuários do aplicativo. Nela, o usuário
deve entrar com e-mail e senhas já cadastrados para seguir para as próximas telas
-
17
do aplicativo, ou ainda, seguir à tela de cadastro onde poderá inserir seu nome, e-mail
e senha para posteriormente autenticar-se na tela de login.
Figura 4 - Protótipo da tela de login e cadastro e edição dos usuários
Fonte: O autor
Nestas duas telas, a aplicação acessa os serviços da Firebase Authentication
para cadastrar e validar a entrada do usuário.
2.2.2.2 Menu principal
Figura 5 - Protótipo do menu principal
Fonte: O autor
-
18
A tela do menu principal é o ponto inicial para qualquer ação do aplicativo. Seja
ela realizar um novo exame, consultar exames já realizados, cadastrar um novo cavalo
e buscar um cavalo já cadastrado. Seu design busca ser simples para rápida
localização e fácil reconhecimento da ação desejada.
2.2.2.3 Cadastro e busca de cavalos
A tela de cadastro de um novo cavalo busca coletar apenas dados pertinentes
à identificação do animal. A tag de identificação do cavalo é a principal informação a
ser coletada, ela servirá como chave de identificação no banco de dados.
Como informação complementar será implementado ao menos um campo para
descrição de alguma característica de nascença do animal, como a descrição de
manchas, por exemplo.
A tela de busca de pacientes mostrará uma lista de cavalos registrados. Essa
lista será carregada ao dispositivo móvel ao iniciar o aplicativo pela primeira vez, caso
haja acesso à internet.
Haverá um botão de leitura de tag, na qual iniciará o processo de aquisição de
dados bluetooth do leitor. O fluxo para esta aquisição está descrito no fluxograma da
Figura 12 e Figura 17.
Figura 6 - Protótipos da tela de cadastro e busca de cavalo
Fonte: O autor
-
19
2.2.2.4 Telas do exame
São três as etapas de realização do exame: Entrada de queixas, entradas de
dados e sugestão de diagnóstico. Esse fluxo do aplicativo é descrito pela Figura 10.
A tela de entrada de queixas, Figura 7, é a etapa inicial do exame do equino.
Nesta tela o usuário deverá entrar com as queixas apresentadas pelo cavalo. Estas
podem partir de análise do profissional que está conduzindo o exame, ou ainda, de
situações relatadas pelo responsável pelo animal.
É possível que hajam múltiplas queixas nesta etapa, sendo assim, é importante
que todas sejam marcadas para auxiliar no restante do exame.
Figura 7 - Protótipo da tela de entrada de queixas
Fonte: O autor
Após a entrada das queixas, internamente são ajustadas variáveis heurísticas,
ou seja, variáveis que, de acordo com os seus pesos, escolherá qual dado será de
maior pertinência para a sequência do exame. Isso dará ao sistema capacidade de
gestão do preenchimento inteligente da ficha clínica, de forma transparente para o
usuário.
A Figura 8 representa dois exemplos de como a tela do exame será
apresentada para entrada de dados pelo usuário.
-
20
Figura 8 - Protótipo da tela de exame
Fonte: O autor
A etapa final do exame é a apresentação das sugestões de diagnósticos,
através dos dados inseridos.
Esses dados serão salvos localmente e posteriormente sincronizados com o
servidos de banco de dados, dependendo da disponibilidade de conexão com a
internet.
Figura 9 - Protótipo da tela de sugestão de diagnóstico
Fonte: O autor
-
21
2.2.3 Fluxogramas do aplicativo
Nesta seção, serão apresentados os fluxos para a realização das principais
funções deste projeto.
2.2.3.1 Exame
Este fluxo representa os passos seguidos para a realização do procedimento
do exame.
Figura 10 - Fluxograma do exame
Fonte: O autor
-
22
O preenchimento guiado e a sugestão de diagnóstico, que contemplam o
exame, são as duas principais funcionalidades do aplicativo. Apesar disso, por se
tratar de um desenvolvimento de aplicativo para dispositivos móveis, o algoritmo
criado para executar essas tarefas, deve impactar o menos possível as capacidades
do smartphone.
Com esses pontos em foco, para este trabalho, está em desenvolvimento um
sistema especialista, o qual, geralmente, chamamos de inteligência artificial, que
consistem em regras que buscam reproduzir o conhecimento de um especialista.
Neste caso, no conhecimento de um médico veterinário.
2.2.3.2 Armazenamento do exame
O fluxo do aplicativo para armazenar os dados obtidos é representado a seguir.
Figura 11 - Fluxograma do armazenamento do exame
Fonte: O autor
-
23
Tendo em vista que um dos desafios para o desenvolvimento deste trabalho é
a elaboração de uma estratégia para utilizar o aplicativo em situações sem acesso à
internet, este fluxograma descreve como esses dados serão sincronizados ao fim de
um exame.
Será utilizada uma sinalização (verdadeira ou falsa) para indicar se o exame já
foi enviado ao serviço de banco de dados. Assim, não importa quantos exames forem
realizados, suas informações serão guardadas no dispositivo para sincronização
posterior.
2.2.3.3 Leitura da TAG de identificação
O projeto do hardware é dividido em três módulos: a antena, o circuito oscilador
e o circuito microcontrolado
A leitura de Tags de identificação possui duas etapas: uma no aplicativo e outra
no hardware desenvolvido.
Figura 12 - Fluxograma de leitura da TAG no aplicativo
Fonte: O autor
-
24
No aplicativo, Figura 12, o fluxo de leitura contempla não apenas a aquisição
da informação, mas, também, a verificação se o dispositivo de hardware está pareado
com o dispositivo móvel.
2.3 HARDWARE
Para auxiliar na identificação dos animais que serão tratados, será
desenvolvido um leitor de tags de identificação. No Brasil, por recomendação da
Comissão de Estudos (CE) e da Associação Brasileira de Normas Técnicas (ABNT),
foi adotado pelo Ministério da Agricultura, Pecuária e Abastecimento (MAPA), com a
publicação da Instrução Normativa (IN) n°05 no final de janeiro de 2018, a norma
técnica ABNT NBR 14766, baseada na norma internacional ISO 11784. Nestes
documentos são definidos aspectos técnicos para a comunicação entre leitor e a tag,
como protocolo de comunicação, frequência definida para a comunicação, etc.
O desenvolvimento do leitor terá três partes distintas: antena, circuito conversor
e circuito controlador.
2.3.1 Antena
A antena a ser desenvolvida é a parte do projeto capaz de estabelecer a
comunicação entre a tag de identificação e o circuito microcontrolado. Operada pelo
circuito conversor, causará um efeito de excitamento na tag que produzirá
interferências no sinal original, que, depois de decodificado, resultará nas informações
contidas nela.
Segundo Kraus (1988) antenas possuem uma infinidade de variações, mas,
todas funcionam a partir dos mesmos princípios do eletromagnetismo. A antena a ser
desenvolvida nos âmbitos deste projeto, não segue as mesmas ideias das antenas
comuns, como as de televisões, rádios, entre outras. Estas possuem a função de
captar os sinais eletromagnéticos de uma faixa de frequência específica que serão
convertidos posteriormente em sons e/ou imagens.
Para ser capaz de receber as informações das tags de identificação, a antena
deve transmitir energia eletromagnética e, a interferência gerada pelo objeto passivo,
a tag, será filtrada e decodificada pelos padrões descritos nas normas.
-
25
Figura 13 – Desenho do protótipo da antena
Fonte: O autor
2.3.2 Circuito conversor
O circuito conversor produzirá um sinal elétrico oscilante, na faixa de frequência
determinada. A antena será inserida neste circuito e ele decodificará o sinal de
resposta do circuito integrado de identificação.
Para a decodificação das tags, será utilizado o circuito integrado EM4095. Este,
é um leitor de baixo custo que converte o sinal adquirido e envia ao circuito
microcontrolado no padrão de comunicação RS232.
-
26
Figura 14 - Circuito integrado EM4095
Fonte: emmicroelectronic.com
Este conversor é projetado para converter diversos protocolos, além do
protocolo descrito na NBR 14766.
𝐶𝐷𝐶2 = 𝐶2 = 10 𝑛𝐹
𝐶𝐹𝐶𝐴𝑃 = 𝐶1 = 10 𝑛𝐹
𝐶𝐴𝐺𝑁𝐷 = 𝐶5 = 100 𝑛𝐹
𝐶𝐷𝐸𝐶 = 𝐶4 = 100 𝑛𝐹
Figura 15 - Desenho esquemático do EM4095
Fonte: O autor
-
27
2.3.3 Circuito microcontrolado
O circuito microcontrolado é o responsável por interpretar os dados do circuito
conversor, de acordo com as especificações deste padrão, e transmiti-los ao
aplicativo, através de tecnologia sem fio, como bluetooth ou wifi.
O ESP32 é um microcontrolador, desenvolvido pela Espressif Systems, de 32-
bit de dois núcleos. Dentre seus diferenciais se destacam a presença de um módulo
wireless (802.11 b/g/n) e um módulo bluetooth v4.2.
Figura 16 - Módulo ESP32
Fonte: esp32.net
2.3.4 Fluxograma do hardware
O hardware possui um principal fluxo de processamento que é o de leitura da
tag e envio ao aplicativo. Este está descrito através do fluxograma da Figura 17.
-
28
Figura 17 - Fluxograma de leitura da TAG no hardware
Fonte: O autor
3 CRONOGRAMA DO PROJETO ATUALIZADO
A seguir é apresentado a tabela de cronograma do projeto atualizado para a
entrega do projeto físico revisado. O cronograma em gráfico de Gantt consta em
ANEXO B e ANEXO C.
Tabela 1 - Cronograma do projeto Id Tarefa Duração Início Término
1 TCC 179 dias Seg 18/03/19 Qua 20/11/19
1.1 Atividades da disciplina TCC 178 dias Seg 18/03/19 Ter 19/11/19
1.1.1 Envio do Plano de Projeto 26 dias Seg 18/03/19 Seg 22/04/19
1.1.2 Defesa dos Planos de Projeto 4 dias Ter 23/04/19 Sex 26/04/19
1.1.3 Envio do Projeto Físico 37 dias Seg 29/04/19 Ter 18/06/19
1.1.4 Defesa do Projeto Físico 2 dias Qua 19/06/19 Qui 20/06/19
1.1.5 Envio do Projeto Físico Revisado 74 dias Sex 21/06/19 Ter 01/10/19
1.1.6 Defesa dos Protótipos 4 dias Qua 02/10/19 Seg 07/10/19
1.1.7 Envio do Relatório Final 27 dias Ter 08/10/19 Qua 13/11/19
1.1.8 Defesa da Implementação Final 4 dias Qui 14/11/19 Ter 19/11/19
2 Planejamento com equipe do projeto 167 dias Seg 18/03/19 Seg 04/11/19
2.1 Levantamento de requisitos 3 dias Seg 18/03/19 Qua 20/03/19
2.2 Modelagem de negócios 3 dias Qui 21/03/19 Seg 25/03/19
-
29
2.3 Análise de risco 8 dias Ter 26/03/19 Qui 04/04/19
2.4 Reuniões semanais 166 dias Ter 19/03/19 Seg 04/11/19
3 Software 181 dias Seg 18/03/19 Sex 22/11/19
3.1 Banco de dados 171 dias Seg 18/03/19 Sex 08/11/19
3.1.1 Modelagem de banco de dados 126 dias Seg 18/03/19 Sex 06/09/19
3.1.2 Desenvolvimento e validação 96 dias Seg 01/07/19 Sex 08/11/19
3.1.2.1 Operação 81 dias Seg 01/07/19 Sex 18/10/19
3.1.2.2 Teste de aceitação 50 dias Seg 02/09/19 Sex 08/11/19
3.2 Aplicação 176 dias Seg 18/03/19 Sex 15/11/19
3.2.1 Definição de plataforma de desenvolvimento 7 dias Seg 18/03/19 Ter 26/03/19
3.2.2 Definição de linguagem 7 dias Seg 18/03/19 Ter 26/03/19
3.2.3 Modelagem de casos de uso 37 dias Ter 26/03/19 Qua 15/05/19
3.2.4 Desenvolvimento e validação 161 dias Seg 08/04/19 Sex 15/11/19
3.2.4.1 Operação 105 dias Ter 11/06/19 Sex 01/11/19
3.2.4.2 Teste de aceitação 81 dias Seg 29/07/19 Sex 15/11/19
3.2.5 Desenvolvimento da UI 66 dias? Seg 12/08/19 Sex 08/11/19
3.3 Implantação 110 dias Seg 24/06/19 Qui 21/11/19
3.3.1 Testes de integração 96 dias Seg 24/06/19 Sex 01/11/19
3.3.2 Teste de validação 105 dias Seg 01/07/19 Qui 21/11/19
3.3.3 Ajustes de codificação 105 dias Seg 01/07/19 Qui 21/11/19
4 Hardware 181 dias Seg 18/03/19 Sex 22/11/19
4.1 Levantamento de requisitos 15 dias Seg 18/03/19 Sex 05/04/19
4.2 Levantamento componentes 15 dias Seg 18/03/19 Sex 05/04/19
4.3 Antena 156 dias Seg 25/03/19 Dom 27/10/19
4.3.1 Desenho em ferramenta de CAD 105 dias Seg 25/03/19 Sex 16/08/19
4.3.2 Testes de grandesas elétricas 14 dias Seg 19/08/19 Qua 04/09/19
4.3.3 Integração com circuito conversor 48 dias Seg 19/08/19 Ter 22/10/19
4.4 Circuito conversor 171 dias Seg 18/03/19 Dom 10/11/19
4.4.1 Levantamento de requisitos 14 dias Seg 18/03/19 Qui 04/04/19
4.4.2 Desenho em ferramenta de CAD 14 dias Sex 05/04/19 Qua 24/04/19
4.4.3 Integração com antena 48 dias Seg 26/08/19 Ter 29/10/19
4.4.4 Testes de validação 56 dias Seg 26/08/19 Sex 08/11/19
4.5 Circuito microcontrolado 181 dias Seg 18/03/19 Sex 22/11/19
4.5.1 Levantamento de requisitos 14 dias Seg 18/03/19 Qui 04/04/19
4.5.2 Integração do hardware 71 dias Seg 29/07/19 Sex 01/11/19
4.5.3 Testes de validação 56 dias Sex 06/09/19 Sex 22/11/19
4.5.4 Ajustes de codificação 86 dias Seg 29/07/19 Sex 22/11/19
Fonte: O autor
-
30
4 PROCEDIMENTOS DE TESTE E VALIDAÇÃO DO PROJETO
Os procedimentos de testes foram distribuídos em duas categorias: testes em
caixa preta, que dizem respeitos à testes de funcionalidades, ou testes de
funcionamento do sistema; e testes em caixa branca, que condizem à testes de
módulos individuais do desenvolvimento.
4.1 TESTES EM CAIXA PRETA
Tabela 2 - Testes em caixa preta
Local Funcionalidade Metodologia de teste Validação
Software Navegação Navegar pelas diversas
telas do aplicativo
Navegar sem que haja
encerramento inesperado
Software Cadastrar novo cavalo Cadastrar um novo
cavalo, reiniciar o
aplicativo e verificar se
ele foi recuperado
corretamente
Verificar que o cavalo
está cadastrado em mais
de um dispositivo
Software Cadastro de usuário Cadastrar novo email
com senha para utilizar
o aplicativo
Verificar em outro
dispositivo se o usuário
consegue validar o
acesso
Software Exame Realização do exame Verificar se o exame
chega a um resultado
conclusivo e os dados
salvos no histórico
Hardware Leitura de tag Aproximar leitor de uma
tag de identificação
Observar em um display
se dados obtidos são os
mesmos da tag
Software -
Hardware
Comunicação entre
aplicativo e hardware
desenvolvido
Após leitura com
hardware, obter dados
via aplicativo
Validar se dados obtidos
são os mesmos da tag
Fonte: O autor
-
31
4.2 TESTES EM CAIXA BRANCA
Tabela 3 - Testes em caixa branca
Local Funcionalidade Metodologia de teste Validação
Software Gestão de
preenchimento
inteligente
Gerar dados de exame
no aplicativo através de
exames reais
Validação pelo feedback
do especialista
Software Armazenamento no
serviço de banco de
dados
Gravar dados de
exames
Verificação e
comparação com dados
salvos através de acesso
pelo terminal do serviço
de armazenamento
Software Cadastro de usuário Cadastro de novo
usuário
Verificação e
comparação com dados
salvos através de acesso
pelo terminal do serviço
de armazenamento
Software Cadastro de cavalo Cadastro de novo
cavalo
Verificação e
comparação com dados
salvos através de acesso
pelo terminal do serviço
de armazenamento
Hardware Leitura de tag Aproximar leitor de uma
tag de identificação
Observar via
comunicação serial com
computador os dados
obtidos
Software -
Hardware
Comunicação entre
aplicativo e hardware
desenvolvido
Após leitura com
hardware, obter dados
via aplicativo
Validar se dados obtidos
via comunicação serial
com computador e via log
de sistema
Fonte: O autor
-
32
5 ANÁLISE DOS RISCOS REVISADO
Foram revisados os principais riscos do projeto, disponibilizados com suas
consequências, mitigações, contingências, classificação do risco, entre outros.
Tabela 4 - Análise de riscos
Ris
co n
º 1
Data limite: 01/06/2019
Situação Ionic não suprir necessidades de desenvolvimento
Consequência Tempo de projeto desperdiçado
Mitigação Estudo e treinamento no uso da ferramenta. Buscar auxílio com professores que dominam a ferramenta.
Monitoramento Desenvolvimento constante de funcionalidades do projeto
Contingência Troca de plataforma de desenvolvimento
Probabilidade Impacto Severidade Classificação
1 3 3 Baixo
Ris
co n
º 2
Data limite: 01/07/2019
Situação EM4095 não chegar a tempo
Consequência Não será possível obter dados da tag
Mitigação Compra com mais de um fornecedor
Monitoramento Acompanhamento do envio e contato com fornecedor
Contingência Desenvolvimento do circuito alternativo
Probabilidade Impacto Severidade Classificação
2 2 4 Médio
Ris
co n
º 3
Data limite: 01/07/2019
Situação EM4095 não atender aos requisitos
Consequência Não será possível obter dados da tag
Mitigação Busca de soluções ou adaptações para criar uma solução
Monitoramento Contato com fornecedor para esclarecimentos
Contingência Pesquisa e aquisição de outros dispositivos que atendam à demanda
Probabilidade Impacto Severidade Classificação
1 3 3 Baixo
Ris
co n
º 4
Data limite: 01/06/2019
Situação Antena de placa de circuito impresso não atender aos requisitos
Consequência Não será possível a comunicação entre circuito desenvolvido e a tag
Mitigação Buscar variações de antenas em PCB para melhorar rendimento
Monitoramento Testes de mesa, analisando os pontos negativos das variações desenvolvidas
Contingência Utilização de antenas enroladas com fio de cobre
Probabilidade Impacto Severidade Classificação
1 2 2 Baixo
Ris
co n
º 5
Data limite: 20/08/2019
Situação Não fazer a comunicação entre hardware e software via bluetooth
Consequência Hardware e software não conseguirão fazer comunicação automaticamente
Mitigação Buscar auxilio com professores que tenham mais experiência com esse tipo de comunicação e com o Ionic.
Monitoramento Testes em comunicação simplificada quando o hardware e o software estiverem minimamente funcionais
-
33
Contingência Implementação de um display no hardware para que a entrada de dados da identificação do animal seja manual
Probabilidade Impacto Severidade Classificação
2 2 4 Médio
Ris
co n
º 6
Data limite: 01/06/2019
Situação Não ser possível utilizar o serviço de banco de dados Firebase
Consequência Tempo de projeto desperdiçado
Mitigação Estudo e treinamento no uso da ferramenta. Buscar auxílio com professores que dominam a ferramenta e pesquisa na internet
Monitoramento Desenvolvimento constante de funcionalidades do projeto
Contingência Troca de serviço de banco de dados
Probabilidade Impacto Severidade Classificação
1 3 3 Baixo
Ris
co n
º 7
Data limite: 01/07/2019
Situação Sistema de gerar diagnóstico não funcionar de maneira satisfatória
Consequência Funcionalidade comprometida
Mitigação Estudar outra forma de obter resultado esperado
Monitoramento Desenvolvimento constante de funcionalidades do projeto
Contingência Substituição do método de gerar diagnóstico
Probabilidade Impacto Severidade Classificação
2 2 4 Médio
Ris
co n
º 8
Data limite: 01/07/2019
Situação Sistema de preenchimento inteligente não funcionar de maneira satisfatória
Consequência Funcionalidade comprometida
Mitigação Estudar outra forma de obter resultado esperado
Monitoramento Desenvolvimento constante de funcionalidades do projeto
Contingência Substituição do método de calcular heurística para preenchimento
Probabilidade Impacto Severidade Classificação
2 2 4 Médio
Fonte: O autor
Destre os riscos apresentados, apenas o risco número 4, referente à antena do
projeto acabou sendo um risco que não foi tomada uma medida de contingência a
tempo. Devido às falhas apresentadas na seção 7.1, deste documento, houve atraso
na finalização do desenvolvimento do hardware.
Erro! Fonte de referência não encontrada.
-
34
6 DESENVOLVIMENTO
6.1 FASE DE PROTÓTIPO
6.1.1 Integração aplicativo-banco de dados
Inicialmente, para o desenvolvimento do aplicativo, foi criado um teste para
validar o uso do Ionic juntamente com a ferramenta de banco de dados Firebase. Foi
criado um projeto de CRUD, acrônimo do inglês Create (criar), Read (ler), Update
(atualizar) e Delete (deletar), para validar a inserção e recuperação de itens no banco
de dados.
Figura 18 - Resultado dos testes de cadastro no banco de dados (1 de 2)
Fonte: O autor
Figura 19 - Resultado dos testes de cadastro no banco de dados (2 de 2)
Fonte: O autor
-
35
Figura 20 - Telas de cadastro e lista de cavalos cadastrados desenvolvidas
Fonte: O autor
Ainda na integração do aplicativo com banco de dados, foi desenvolvido o
controle de acesso de usuário via cadastro de e-mail e senha através do serviço de
autenticação, também do Firebase.
Figura 21 - Tela de login e cadastro desenvolvidas
Fonte: O autor
-
36
Figura 22 - Resultado da criação de novo usuário
Fonte: O autor
Com as funções de CRUD e cadastro de usuários testadas e funcionando, os
passos seguintes, relativos ao banco de dados, são a definição dos dados a serem
armazenados pertinentes para realizar o exame e quais dados serão classificados
como mínimo necessários para utilizar o aplicativo sem acesso à internet.
6.1.2 Preenchimento guiado e sugestão de diagnóstico
Para realizar o exame com preenchimento guiado e, posteriormente, sugerir
diagnósticos com e sem acesso a um banco de dados na nuvem, serão armazenadas
as informações pertinentes a cada possível diagnóstico.
Nesta primeira etapa, cada uma destas possibilidades precisará de quatro
campos:
• Diagnóstico: Contém o nome ou identificação da condição a ser
diagnosticadas;
• Sintomas prováveis: lista dos sintomas que ocorrem para o devido
diagnóstico;
• Condições de validação: são as condições que serão levantadas pelo
aplicativo para guiar o exame;
• Condições de exclusão: são as condições que invalidam um
determinado diagnóstico. Pode haver condições ou não neste item.
Como exemplo hipotético, considera-se o diagnóstico da “doença 1” que possui
como sintomas “dificuldade de respirar” e “tosse”. Suas condições para validar este
diagnóstico são “secreção nasal” em uma ou nas duas narinas e “tosse” leve ou
moderada. E, por último, este diagnóstico é válido apenas se não houver febre. A
estrutura de dados deste diagnostico hipotético ficaria da seguinte forma:
-
37
Tabela 5 - Estrutura de dados de diagnóstico hipotético Diagnóstico Doença 1
Sintomas prováveis - Dificuldade de respirar
- Tosse
Condições necessárias - Secreção nasal = verdadeiro
- Tosse = verdadeiro (intensidade 1 ou 2)
Condições de exclusão - Febre = verdadeiro
Fonte: O autor
Desta maneira, ao selecionar os sintomas apresentados pelo cavalo, caso seja
selecionada algum dos sintomas prováveis, as condições necessárias e de exclusão
irão entrar na lista de exames a serem feitos pelo especialista.
Por questões de testes, os dados inseridos até esta etapa são genéricos para
consolidação do modelo proposto.
Figura 23 - Tela desenvolvida de seleção de sintomas
Fonte: O autor
-
38
Figura 24 - Telas de exame desenvolvidas
Fonte: O autor
Nas telas de exame desenvolvidas serão apresentados dinamicamente cada
uma das condições para validar os diagnósticos. Nas telas apresentadas são
mostrados botões com todas as condições inseridas para fins de testes. Estes não
estarão presentes na versão final, ou serão apresentados de outra forma.
Como proposto em fase anterior do projeto, a Figura 10 - Fluxograma do exame
será o modelo seguido para execução deste sistema especialista, considerando as
variáveis heurísticas como: sintomas prováveis, condições necessárias e condições
de exclusão. Desta maneira, após inserir todos os possíveis dados pertinentes no
exame, será apresentado ao usuário todos os diagnósticos prováveis do exame.
6.1.3 Integração aplicativo-hardware
Para testar a comunicação entre software e hardware, foi desenvolvido um
cenário simples e fictício, mostrado na Figura 25, onde o aplicativo envia um byte pré-
definido, como “A”, por exemplo, via comunicação seria Bluetooth, e, assim que o
ESP32 o recebe, responde com uma cadeia de caracteres, também pré-estabelecida,
e mostrada pelo aplicativo.
Para testar, foram efetuados diversos envios pelo aplicativo para testar a
consistência das informações enviadas e recebidas.
-
39
Figura 25 - Fluxograma de teste de comunicação software-hardware – ESP32
Teste de comunicação ESP32
Inicialização do sistema
Aguardando dados da comunicação serial (Bluetooth)
Recebe dados
Dado recebido = A
NÃO
Responde cadeia de caracteres via serial
SIM
Fonte: O autor
Figura 26 - Terminal mostrando dados enviados e recebidos pelo ESP32
Fonte: O autor
-
40
Figura 27 - Teste de integração aplicativo-hardware
Fonte: O autor
A tela de teste de comunicação entre o aplicativo e o hardware possui cinco
botões de controle para realizar a troca de mensagens. Os dois primeiros são apenas
para conectar e desconectar a comunicação serial; o botão “teste de envio” tem a
função de enviar o texto inserido na caixa de texto logo abaixo dele; o botão “teste de
recebimento” força a mensagem recebida para ser exibida na caixa de texto abaixo
dele; e o último apenas volta para a tela inicial do aplicativo.
6.1.4 Circuito conversor
O desenvolvimento do circuito conversor e da antena seguiu orientações
disponíveis nas notas da aplicação do circuito integrado EM4095, disponibilizado pelo
fabricante. Como protótipo, foi desenvolvida uma placa de circuito impresso, a seguir,
seguindo o esquemático da Figura 15, página 26.
-
41
Figura 28 - Circuito conversor desenvolvido (Inferior)
Fonte: O autor
Figura 29 - Circuito conversor desenvolvido (Topo)
Fonte: O autor
A escolha de soldar na placa barras de pinos é para agilizar no processo de
troca de componentes, caso necessário, durante os testes do circuito.
6.1.5 Antena
A antena do protótipo é uma antena planar de dupla face, ou seja, um espiral
em ambos os lados de uma placa de circuito impresso.
-
42
Figura 30 - Antena desenvolvida
Fonte: O autor
Esta antena é a quinta versão projetada. Os problemas ocorridos estão
descritos na seção 7 deste documento
A antena possui as seguintes características:
Tabela 6 - Características da antena
Grandeza Medida Unidade
Número de voltas 52 −
Espessura de trilha 0,635 𝑚𝑚
Espaçamento de trilhas 0,254 𝑚𝑚
Resistência 43,8 𝛺
Indutância 488,631 µ𝐻
Fonte: O autor
Os instrumentos utilizados para medir a resistência e a indutância da antena
foram, respectivamente Multímetro Tektronix DMM912 e LCR Meter Keysight E4980A,
ambos pertencentes aos laboratórios de Engenharia Elétrica e da Computação da
PUCPR.
Seguindo as orientações e equações fornecidas pela EM Microelectronic,
fabricante do EM4095, foram calculados os componentes e aplicados no circuito da
Figura 15. São consideradas as seguintes variáveis para os cálculos:
• 𝑓0 = 125 𝑘𝐻𝑧, frequência de operação definidos pelos padrões da
tecnologia;
• 𝐿𝐴 = 488,631 𝜇𝐻, indutância medida da antena;
• 𝑅𝐴𝑁𝑇 = 43,8 Ω, resistência elétrica medida da antena;
-
43
• 𝑅𝐴𝐷 = 3 Ω, resistência elétrica de saída para a antena, fornecido pelo
fabricante;
• 𝑉𝑐𝑐 = 𝑉𝑑𝑑 − 𝑉𝑠𝑠 = 5 𝑉, tensão de alimentação do circuito
A frequência de oscilação do circuito é produzida pela antena e ajustada com
um capacitor de ressonância. Este é calculado utilizando a seguinte equação.
𝐶3 = 𝐶𝑅𝐸𝑆 =1
(2. 𝜋. 𝑓0)2. 𝐿𝐴≅ 3,3 𝑛𝐹 (1)
Assim é possível calcular quais são a tensão e a corrente elétrica sendo
aplicadas à antena através das equações (2) e (3).
𝐼𝐴𝑁𝑇 (𝑝𝑖𝑐𝑜) =4. 𝑉𝑐𝑐
𝜋. (𝑅𝐴𝑁𝑇 + 2. 𝑅𝐴𝐷)≅ 127,8 𝑚𝐴 (2)
𝑉𝐴𝑁𝑇 (𝑝𝑖𝑐𝑜) =𝐼𝐴𝑁𝑇 (𝑝𝑖𝑐𝑜)
2. 𝜋. 𝑓0. 𝐶𝑅𝐸𝑆≅ 49,323 𝑉 (3)
Como as especificações do fabricante recomendam que a corrente de pico
máxima seja de 250 𝑚𝐴, as características atingidas pela antena desenvolvida são
aceitáveis.
Até esta etapa, os cálculos são direcionados a validar se a antena possui
características aceitáveis para o circuito. A partir deste ponto, é calculada a frequência
real de ressonância do circuito através de uma capacitância equivalente 𝐶0, levando
em conta os capacitores 𝐶6 e 𝐶7 aplicados na equação (4). Novamente seguindo
recomendações do fabricante, o capacitor 𝐶7 = 1,5 𝑛𝐹, pois deve pertencer ao
intervalo de 1 𝑛𝐹 à 2 𝑛𝐹 e o capacitor 𝐶6 = 1 𝑝𝐹 foi escolhido após alguns valores
estipulados, procurando manter a frequência de oscilação em torno de 125 𝑘𝐻𝑧.
𝐶0 = 𝐶3 +𝐶6. 𝐶7
𝐶6 + 𝐶7≅ 3,3 𝑛𝐹 (4)
Assim, aplicando os valores obtidos na equação (5), é obtido a frequência real
de ressonância do circuito
𝑓0 =1
2. 𝜋. √𝐿𝐴. 𝐶0= 125335 𝐻𝑧 ≅ 125 𝑘𝐻𝑧
(5)
Os outros valores de capacitores são sugeridos pelo fabricante:
𝐶1 = 𝐶2 = 10 𝑛𝐹
𝐶4 = 𝐶5 = 100 𝑛𝐹
-
44
6.2 IMPLEMENTAÇÃO FINAL
6.2.1 Integraçao do hardware
Após o desenvolvimento dos módulos de hardware separadamente, foi
desenvolvida um circuito integrando as três partes do hardware: circuito
microcontrolado, circuito conversor e antena. Foi desenhado o circuito (ANEXO D) e
fabricada a placa de circuito impresso. Na Figura 31 consta o desenho desenvolvido
e a Figura 32 a placa fabricada.
Figura 31 - Versão final do hardware
Figura 32 - Placa de circuito impresso do hardware integrado
6.2.2 Permanencia de dados sem acesso à internet
A estratégia adotada para manter as funcionalidades do aplicativo, mesmo
quando não há acesso ao banco de dados do Firebase, foi utilizando os recursos do
Ionic de monitoramento do dispositivo de rede e fazendo a persistência de dados
-
45
localmente. Desta maneira, quando o aplicativo é iniciado, as informações
cadastradas do usuário, como dados pessoais e o histórico de consultas, são
recebidas e armazenadas em um banco de dados local. Assim, sempre que houver
uma tentativa de leitura do banco de dados, mas, não houver acesso à internet, os
dados utilizados serão os dados locais, mesmo que temporariamente desatualizados.
Já o envio de dados novos, como, por exemplo, uma nova consulta realizada,
quando não há acesso à internet, ficarão armazenados localmente com uma
sinalização (flag) indicativa que esses dados não foram sincronizados previamente.
Deste modo, quando o aplicativo for iniciado novamente, se houver acesso à internet,
esses dados serão sincronizados com o banco de dados do Firebase.
6.2.3 Novo Modelo de exames
Os exames propostos a serem realizados no aplicativo seguem o modelo
proposto na ficha clínica (ANEXO E e ANEXO F) remodelada e validada pela equipe
de especialistas de Medicina Veterinária. Esta mudança, em relação à versão anterior
se deve ao feedback recebido na validação anterior.
6.2.4 Sistema de preenchimento guiado
O preenchimento guiado, da ficha clínica, é criado a partir dos dados inseridos
em “Queixas principais” e na “Anamnese”. Quando há o preenchimento de uma queixa
ou, em uma anamnese, é detectada alguma anormalidade, todos os diagnósticos que
possuem alguma dessas condições são inclusos na lista de possíveis diagnósticos.
Desta forma os exames exibidos serão aqueles que pertencem à lista de exames
necessários para todos os diagnósticos possíveis.
Uma informação inserida para a progressão deste projeto, no futuro, é um valor
de “peso” para cada exame a ser realizado. Desta maneira, os exames mais simples,
com menores “pesos”, serão realizados primeiro e os mais complexos vão ficando
para o fim, ou até mesmo, poderão ficar como sugestões de exames, como um exame
sanguíneo, por exemplo.
-
46
6.2.5 Sistema de sugestões de diagnósticos
Inicialmente, durante o planejamento deste projeto, foi discutido sobre o
sistema gerar sugestões de diagnósticos ao final do preenchimento da ficha clínica.
Como não há um consenso quanto a essa funcionalidade, foi decidido que,
principalmente para validar o modelo proposto, essa informação será apresentada no
final.
Para isso, seguindo orientações da equipe de especialistas da Medicina
Veterinária, foram inseridos e adequados ao sistema três possíveis diagnósticos para
validar o modelo: Asma leve, asma grave e pneumonia. O modelo para avaliar os
sintomas é utilizando a tríade: nome, operador e valor. Assim, os resultados para
comprovar aquele diagnóstico devem passar por todos critérios apresentados.
A escolha destes três se dá por apresentarem exames clínicos semelhantes,
porém com pequenas diferenças de resultados. Como exemplo de como os dados
ficarão no sistema, a Tabela 7 contêm os dados que representam a asma leve.
Tabela 7 - Modelo de informações no sistema (Asma leve)
Diagnóstico Sintomas
necessários
Anamneses
necessárias
Resultados para comprovar
Nome Op. Valor
Asma leve
Tosse Esforço respiratório Temperatura < 38,5
Secreção nasal Secreção nasal Respiração em repouso = Eupneia
Tosse Secreção nasal = Verdadeiro
-
47
7 PROBLEMAS ENCONTRADOS
Os problemas encontrados relacionados ao desenvolvimento do aplicativo são
relacionados principalmente à falta de experiência em programação em linguagens
web, que são especificamente o foco do IONIC. Apesar disso, além de existir grande
quantidade de soluções on-line a esse respeito, houve grande auxílio do professor co-
orientador Bruno Campagnolo de Paula disponibilizando materiais de
desenvolvimento próprio que guiaram boa parte do desenvolvimento.
7.1 PROBLEMAS COM HARDWARE
As maiores dificuldades encontradas são relacionadas ao desenvolvimento do
hardware. Como uma das propostas do projeto é o desenvolvimento de uma solução
de leitura de tags de identificação mais acessível utilizando antena em placa de
circuito impresso, houveram cinco modelos de antenas projetadas, das quais, apenas
uma chegou a fase final de testes.
O principal fator que levou a falha dos modelos anteriores foi o espaçamento
entre as trilhas. Uma das metas foi miniaturizar o circuito para que não ocupe uma
área grande, mas, falhas da máquina de prototipação de PCB no processo de
fabricação ocasionavam regiões onde o cobre da placa não era completamente
retirado (Figura 33), ou era completamente retirado (Figura 34).
Figura 33 - Defeito de fabricação (cobre não retirado completamente)
Fonte: O autor
-
48
Figura 34 - Defeito de fabricação (cobre retirado completamente)
Fonte: O autor
Outro problema que ocorreu durante a fabricação era a falha da prototipadora
no qual a placa era danificada, inviabilizando a continuação daquele processo,
obrigando a reiniciar o procedimento.
Figura 35 - Falha de fabricação da antena
Fonte: O autor
Estas falhas em produção causaram para um atraso no desenvolvimento do
hardware.
-
49
7.2 PROBLEMAS DE CRONOGRAMA
Este problema ocorreu devido aos atrasos com o desenvolvimento de
hardware. Devido as falhas que ocorriam nesta etapa do desenvolvimento, houve um
adiamento no cronograma para o desenvolvimento das etapas finais do aplicativo.
-
50
8 CONCLUSÃO
Concluindo, este trabalho se trata do desenvolvimento de um prontuário
eletrônico do paciente (PEP) para o uso de médicos veterinários, focado em doenças
respiratórias de equinos. O desenvolvimento do aplicativo, de forma geral, se deu de
forma satisfatória. Apesar das dificuldades com, não apenas de linguagens de
programação diferentes das normalmente utilizadas pelo desenvolvedor deste
trabalho, mas, também, de um campo de conhecimento diferente do campo de
Engenharia de Computação, o prosseguimento do desenvolvimento ocorreu de forma
gradual e positiva.
O aplicativo teve seu desenvolvimento de forma satisfatória e atingiu o objetivo
esperado para esse projeto.
O principal problema encontrado foi com o hardware, que apesar de ter seu
desenvolvimento bem avançado, não houve tempo hábil para sua conclusão.
Para etapas futuras é necessário a conclusão do desenvolvimento do
hardware. Também, é interessante o envolvimento com pessoas especializadas em
design de aplicativos mobile para tornar cada vez melhor a aplicação, não apenas em
funcionalidades, mas, também que seja agradável sua utilização.
8.1 CONSIDERAÇOES DE ROHS
Neste projeto, é proposto que o hardware utiliza baterias. Como considerações
de RoHS (Restriction of Hazardous Substances — Restrição de Substâncias
Perigosas), é recomendável o retorno dessas baterias a lojas que os vendam.
Usualmente, estes estabelecimentos possuem rede de coleta e descarte deste tipo de
material.
-
51
9 REFERÊNCIAS BIBLIOGRÁFICAS
[1] PORTAL EMBRAPA. Recomendação da Comissão de Estudos da ABNT para identificação de animais é adotada pelo Mapa. Disponível em: < https://www.embrapa.br/busca-de-noticias/-/noticia/32211862/recomendacao-da-comissao-de-estudos-da-abnt-para-identificacao-de-animais-e-adotada-pelo-mapa>. Acesso em: 10 mar. 2019.
[2] USBID. EM4095. Disponível em: < https://www.usbid.com/assets/datasheets/DE/em4095_ds.pdf>. Acesso em: 22 abr. 2019.
[3] ESPRESSIF SYSTEMS. Esp32 Resources. Disponível em: < https://www.espressif.com/en/products/hardware/esp32/resources>. Acesso em: 08 mar. 2019.
[4] GOIS, Adrian. Ionic Framework: Construa aplicativos para todas as plataformas mobile. Editora Casa do Código, 2017. 162 p.
[5] BENYON, David. Interação humano-computador.2ª ed. São Paulo: Pearson, 2010.
[6] Firebase. Firebase. Disponível em . Acesso em: 03 abr. 2019.
[7] AppNote 404. EM4095 Application Note. Disponível em . Acesso em: 24 jun. 2019.
[8] Luger, G. F. and Stubblefield, W. A. Artificial Intelligence: Structures and Strategies for Complex Problem Solving. Benjamin/Cummings, Redwood City, California, second edition, 1993.
-
52
ANEXO A - MODELO DE FICHA CLÍNICA
-
53
ANEXO B – CRONOGRAMA EM GRÁFICO DE GANTT (1 DE 2)
-
54
ANEXO C – CRONOGRAMA EM GRÁFICO DE GANTT (2 DE 2)
-
55
ANEXO D – ESQUEMÁTICO DO HARDWARE INTEGRADO
-
56
ANEXO E – FICHA CLÍNICA REMODELADA (1 DE 2)
-
57
ANEXO F – FICHA CLÍNICA REMODELADA (2 DE 2)