PONTIFÍCIA UNIVERSIDADE CATÓLICA DO PARANÁlaplima/ensino/tcc/concluidos/2019/...Figura 31 -...

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




de armazenamento

Software Cadastro de cavalo Cadastro de novo

cavalo

Verificação e




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


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


2 2 4 Médio

Ris

co n

º 3


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


1 3 3 Baixo

Ris

co n

º 4


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


1 2 2 Baixo

Ris

co n

º 5


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


2 2 4 Médio

Ris

co n

º 6


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


Contingência Troca de serviço de banco de dados


1 3 3 Baixo

Ris

co n

º 7


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


Contingência Substituição do método de gerar diagnóstico


2 2 4 Médio

Ris

co n

º 8


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


Contingência Substituição do método de calcular heurística para preenchimento


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)

PONTIFÍCIA UNIVERSIDADE CATÓLICA DO PARANÁlaplima/ensino/tcc/concluidos/2019/...Figura 31 -...

Documents

Transcript of PONTIFÍCIA UNIVERSIDADE CATÓLICA DO PARANÁlaplima/ensino/tcc/concluidos/2019/...Figura 31 -...