Projeto da Disciplina - Especificação e Entrega Completa
Especificação do Projeto da Disciplina
Informações Iniciais
O
projeto da disciplina deve envolver uma solução funcional de aplicação
integrada (software e hardware) e a escrita de um relatório científico
no formato de um artigo no contexto de IoT. Para o desenvolvimento da
solução, a turma será dividida em grupos com até 4 integrantes.
Proposta
Apresentamos
uma arquitetura com a divisão de elementos de IoT em cinco etapas de
projeto (aplicação, broker, micro-serviço, armazenamento e segurança).
Os alunos devem por meio desta proposta realizar o desenvolvimento de
uma aplicação de IoT para o controle do ar condicionado e sensores de
temperatura e umidade localizados no LaSDPC. Além disso, deve ser
escrito um artigo sobre o trabalho desenvolvido explorando lacunas na
área e sugestões propostas.
Objetivo: Aprender a projetar, analisar e desenvolver soluções em IoT e ter conhecimento nas pesquisas realizadas na área de IoT.
Arquitetura: A
comunicação entre os componentes da arquitetura de IoT pode ser
visualizado conforme a sugestão abaixo. O grupo pode decidir não seguir
esta sugestão e implementar sua própria arquitetura, mas deve justificar
o porquê da decisão.
- A camada de aplicação deve se comunicar com o Micro-serviço.
- O Broker deve orquestrar a troca de mensagens utilizando o protocolo MQTT.
- A
camada de micro-serviço deve receber mensagens do Broker e da Aplicação
e realizar o tratamento adequado. É preciso gravar as ações realizadas
em um banco de dados, de preferência em uma base orientada a documentos.
- A camada de armazenamento é responsável por salvar os dados tratados pelo Micro-serviço.
- A
camada de segurança é responsável pela transição desses dados de forma
segura. Ela está em cada etapa da arquitetura proposta. Nos dispositivos
físicos instalados, na comunicação de dispositivos físicos com outros
dispositivos físicos, dos sistemas operacionais para os dispositivos, no
armazenamento e no processamento dos dados. Nesse ponto é importante se
atentar a confiabilidade, autenticidade e integridade dos dados.
O que deve ser entregue e como?
Um relatório científico descrevendo a solução completa
Todos os códigos da solução.
Todo
o desenvolvimento e os testes relativos ao projeto devem ser realizados
utilizando o material e recursos disponíveis para os grupos
Todo o ambiente da solução apresentada deve estar em containers dockers, devidamente separando a aplicação, a base de dados, gateways, etc.
Propostas para o Relatório
O
relatório final deve levar em conta as pesquisas realizadas na área e
descrever como essas pesquisas se encaixam com o trabalho técnico que
foi desenvolvido com base na arquitetura implementada. As principais
ideias para para a criação do relatório científico são:
- Investigar
os Logs e formas de gerenciamento para esses logs; Isso é, investigar
ferramentas e formas de aplicar métodos na infraestrutura para controle
de Log. Descrever as vantagens e desvantagens da aplicação dessas
ferramentas ou métodos;
- Utilização
de ferramentas de Data Stream Management System (DBMSs) para facilitar a
escalabilidade de uma aplicação em IoT de larga escala;
- Formas de aproveitar as threads do ESP32 para gerenciamento de Logs e outras demandas multithreads;
O que deve ser entregue e como?
Um relatório científico descrevendo a solução completa
Todos os códigos da solução.
Todo o desenvolvimento e os testes relativos ao projeto devem ser realizados utilizando o material e recursos disponíveis para os grupos
Todo o ambiente da solução apresentada deve estar em containers dockers, devidamente separando a aplicação, a base de dados, gateways, etc.
Propostas para o Relatório
Avaliação
A avaliação será realizada por grupo. Será avaliada a capacidade do grupo de desenvolver a etapa selecionada conforme os critérios abaixo:
A aplicação/sistema a ser desenvolvido deve considerar a idéia da arquitetura proposta, embora vocês possam organizá-las de outra forma.
O relatório deve conter um estudo da área de interesse e deve apresentar um estudo de caso
Será avaliada a capacidade de sintetizar o conteúdo, a apresentação do estudo de caso e a sintetização do estudo de caso
Sugestão de Ferramentas
Aplicação | Broker | Armazenamento | Micro-Serviço | Segurança |
Android (Java, Kotlin, Flutter, React Native, ...) | Mosquitto | MySQL | PHP | Segurança no protocolo MQTT |
IOS (Swift, Flutter, React Native, ...) | HiveMQ Community Edition | MongoDB | Java | Algoritmos de criptografia utilizados para seguranças de dispositivos físicos |
Interface WEB (HTML, CSS, JS, ...) | Moquette | PostgreSQL | C# | Segurança na troca de mensagens de dispositivos |
Desktop (Java, C#, ...) | ... | Cassandra | Python | ... |
... | ... |
O que será cobrado em cada Checkpoint?
- | Checkpoint 1 Dicussão presencial no dia da entrega | Checkpoint 2 Dicussão presencial no dia da entrega | Checkpoint 3 Dicussão presencial no dia da entrega | Checkpoint 4 Dicussão presencial no dia da entrega | Entrega Final |
Proposta do Projeto | Apresentação de no máximo 10 slides discutindo a proposta do projeto, incluindo no mínimo: Titulo do Projeto (Provisório) O problema a ser investigado 10 Referências Bibliográficas recentes entre 2018 e 2022 * | Apresentação de no máximo 10 slides discutindo a proposta do projeto, Seleção, instalação e das linguagens e tecnologias;* Seleção da ferramenta do servidor de broker;* Seleção da ferramenta do servidor de armazenamento; | Discussão sobre ambiente operacional da solução incluindo no mínimo: configurações, implatação, containers, e testes iniciiais da infra no LaSDC ou Azure, GCP e AWS Acrescentar novas Bibliografias ao relatório (as que julgarem necessárias e no escopo do projeto) | Entrega dos códigos do relatório no gitlab do grupo com todo o detalhamento da solução Apresentação dos resultaso e discussão | Entrega final do fluxograma; Apresentação descrevendo o que foi desenvolvido; |
Relatório | - | Resumo (Abstract), Resumo dos Trabalhos Relacionados | Descrição da Metodologia do projeto Entrega da estrutura incial do relatório com os campos os seguintes campos devidamente preenchidos: https://docs.google.com/document/d/1wQTB1h8f7HaeYSMBerMpiTnvY0jkL-daj0l08whcchE/edit?usp=sharing | Entrega dos resultados parciais. Códigos no Gitlab e link de acesso no Moodle no local indicado. Primeiro envio da versão do relatório no Moodle complementando o checkpoint anterior, com: Experimentos Realizados com métricas, Avaliação dos Resultados, Conclusão, Referências. | Entrega final do relatório; |
Da Estruturação do Relatório
- O relatório deve ter cunho científico e apresentar em sua estrutura no mínimo as seções: Resumo, Trabalhos Relacionados, Projeto, Metodologia, Experimentos Realizados com métricas, Avaliação dos Resultados, Conclusão, Referências. O relatório deve ter um número mínimo de 10 páginas e no máximo 20 páginas.
- Discuta as soluções, as dificuldades, os resultados obtidos, o hardware utilizado, a metodologia de execução dos experimentos/configurações, etc. Utilizar tabelas e/ou gráficos é muito bem vindo em qualquer relatório.
- Os relatórios devem incluir um link para o repositório do gitlab para que os experimentos possam ser facilmente reproduzidos
Do Envio do Relatório
- O relatório final dever ser submetido via Moodle na data final prevista
- O gitlab do grupo deve conter todo o manual de operação para instalar e configurar ferramentas, interagir com as nuvens da AWS, Azure e GCP e também do LaSDPC. Deve também conter manual explicando como executar os comandos/scripts, etc.
- Relatório postado depois do prazo não será corrigido, e invalidará o projeto do grupo.
- Para o envio do relatório final no Moodle, coloque o arquivo do mesmo em um .ZIP, com a seguinte estrutura:
Da Estruturação dos Códigos
- Os códigos precisam ser claros e estarem devidamente comentados lá no gitlab
- Todos os arquivos de configurações, etc., devem também estar presentes no gitlab de cada grupo.
- A URL para o repositório deve estar presente no relatório. Relatório sem a URL do repositório da solução, terão penalização na nota: (-5 pontos)
Do Envio dos Códigos
Como Será a Avaliação do Projeto
Das Notas e Pesos
- Peso: 50%
- Quem Avalia: Professor da disciplina ou Outro docente convidado
- Peso:50%
- Quem Avalia: Professor da disciplina ou Outro docente convidado