Solução de análise preditiva para gestão de tarefas e avarias

Universidade do Minho Escola de Engenharia Departamento de Inform´ atica Fl´ avia Daniela da Silva Soluc¸ ˜ ao de An´ alise Preditiva Para Gest˜ ao de Tarefas e Avarias Dezembro 2019 Universidade do Minho Escola de Engenharia Departamento de Inform´ atica Fl´ avia Daniela da Silva Soluc¸ ˜ ao de An´ alise Preditiva Para Gest˜ ao de Tarefas e Avarias Master dissertation Master Degree in Computer Science Dissertation supervised by Pedro Rangel Henriques Dezembro 2019 DIREITOS DE AUTOR E CONDIÇÕES DE UTILIZAÇÃO DO TRABALHO POR TERCEIROS Este é um trabalho académico que pode ser utilizado por terceiros desde que respeitadas as regras e boas práticas internacionalmente aceites, no que concerne aos direitos de autor e direitos conexos. Assim, o presente trabalho pode ser utilizado nos termos previstos na licença abaixo indicada. Caso o utilizador necessite de permissão para poder fazer um uso do trabalho em condições não previstas no licenciamento indicado, deverá contactar o autor, através do RepositóriUM da Universidade do Minho. Licença concedida aos utilizadores deste trabalho Atribuição-NãoComercial CC BY-NC https://creativecommons.org/licenses/by-nc/4.0/ DECLARAÇÃO DE INTEGRIDADE Declaro ter atuado com integridade na elaboração do presente trabalho académico e confirmo que não recorri à prática de plágio nem a qualquer forma de utilização indevida ou falsificação de informações ou resultados em nenhuma das etapas conducente à sua elaboração. Mais declaro que conheço e que respeitei o Código de Conduta Ética da Universidade do Minho. AGRADECIMENTOS Gostaria de expressar a minha gratid˜ ao ao professor Pedro Henriques pela orientac¸˜ ao e sugest˜ oes dadas ao longo do desenvolvimento desta dissertac¸˜ ao. Gostaria de agradecer ` a Mariana Gonc¸alves e ao Nuno Chambino, que me acompanharam mais de perto ajudando-me e apoiando-me durante a dissertac¸˜ ao. Gostaria tamb´ em de expressar minha gratid˜ ao a todos os meus amigos e colegas de trabalho que ouviram as minhas queixas quando as coisas n˜ ao corriam como planeado, por toda a ajuda e conselhos que me davam sempre que podiam. Finalmente, gostaria de agradecer aos meus pais pelo seu inestim´ avel apoio, incentivo e ajuda que me deram durante os anos de estudo. iii ABSTRACT This dissertation reports on a Masters’ Project in the field of Computing Engineering. The objective of this project is based on the forecast of possible shortages of goods and possible damage that the vending machines can have, optimizing the profitability of the devices, as well as the management of the tasks of the employees. For the execution of this project we intend to design and develop a support system of predictive analysis that allows to expand the functionalities provided by the existing application. The existing application meets all the requirements initially presented by the company’s customer, but does not take advantage of all the capabilities that the SAP Hana Cloud Platform (SAP HCP) has available. It is possible and intended in this phase to add new functionalities in order to monetize the devices including the predictive analytical capability. Keywords — predictive analysis, SAP HCP, R iv RESUMO Este documento descreve um projeto de tese do Mestrado Integrado em Engenharia Inform´ atica. O objetivo deste projeto ´ e o desenvolvimento de um sistema de previs˜ ao de eventuais faltas de mercadorias e poss´ ıveis avarias que as m´ aquinas de venda de produtos possam vir a ter, otimizando a rentabilidade dos dispositivos, assim como a gest˜ ao das tarefas dos funcion´ arios. Para a execuc¸˜ ao deste projeto estudou-se e planeou-se um sistema de suporte de an´ alise preditiva para ser integrado numa aplicac¸˜ ao de gest˜ ao de m´ aquinas de venda autom´ atica de produtos j´ a existente, permitindo expandir as suas funcionalidades originais. A aplicac¸˜ ao existente, implementada na plataforma Systems, Applications and Products in Data Processing (SAP) responde a todos os requisitos apresentados inicialmente pelo cliente da empresa, contudo n˜ ao tira proveito de todas as capacidades que a plataforma SAP HCP tem dispon´ ıveis, sendo poss´ ıvel adicionar novas funcionalidades com o objetivo de rentabilizar os dispositivos adicionando a capacidade de an´ alise preditiva. Palavras-Chave — an´ alise preditiva, SAP HCP, R v CONTE ´ UDO 1 introduc¸˜ ao 1 1.1Objetivos 2 1.2Estrutura do Documento 2 2 estado da arte e tecnologias relacionadas 3 2.1SAP - Systems, Applications and Products in Data Processing 3 2.2SAP Leonardo Machine Learning 4 2.3SAP HCP (Hana Cloud Platform) 7 2.4SAPUI5(SAP User Interface 5)9 3 proposta da abordagem 11 3.1Definic¸˜ ao da Arquitetura 12 4 algoritmos para an ´ alise preditiva 15 4.1Biblioteca de Algoritmos do SAP HANA 15 4.1.1Decis˜ oes 19 4.2O Sistema de Programac¸˜ ao R 20 4.2.1Algoritmos R Utilizados 21 5 previs ˜ ao em r:implementac¸˜ ao,testes e integrac¸˜ ao 23 5.1Preparac¸˜ ao e An´ alise dos Dados 23 5.1.1Testes e Resultados 27 5.2M´ etodo Seasonal Naive 28 5.3Modelo ETS 30 5.4Modelo ARIMA 32 5.5Implementac¸˜ ao do Algoritmo R no SAP HANA 39 5.5.1Procedimentos 40 5.6Alterac¸ ˜ oes na Aplicac¸˜ ao 43 5.6.1Front-End 43 6 conclus ˜ ao 47 6.1Trabalhos Futuros 48 a requisitos da aplicac¸˜ ao 52 vi LISTA DE FIGURAS Figura 1Aplicac¸ ˜ oes e servic¸os do SAP Leonardo Machine Learning 4 Figura 2Vis˜ ao geral dos componentes SAP Leonardo Machine Learning 4 Figura 3Diferentes servic¸os fornecidos pela SAP Leonardo Machine Learning Foundation 5 Figura 4Diagrama de Componentes da SAP 6 Figura 5SAP HCP 7 Figura 6Principais Cen´ arios Utilizados 7 Figura 7Arquitetura SAP HCP 8 Figura 8SAP User Interface 5(SAPUI5)9 Figura 9Conceito MVC 10 Figura 10 Arquitetura Antiga 13 Figura 11 Nova Arquitetura 14 Figura 12 Amostra da Tabela IOTSERVICE 21 Figura 13 Amostra do resultado da query 21 Figura 14 Gr´ afico de vendas 25 Figura 15 Gr´ afico de diferenc¸as de vendas 26 Figura 16 Gr´ afico gerado com a func¸˜ ao ggseasonplot 27 Figura 17 Resumo do M´ etodo snaive 29 Figura 18 Gr´ afico de Resumo do M´ etodo snaive 30 Figura 19 Resumo do Modelo ETS 31 Figura 20 Gr´ afico do Resumo do Modelo ETS 32 Figura 21 Modelos ARIMA experimentados 33 Figura 22 Resumo do Modelo ARIMA 34 Figura 23 Gr´ aficos ARIMA 35 Figura 24 Gr´ aficos com os resultados da previs˜ ao 36 Figura 25 Resumo da previs˜ ao 37 Figura 26 Tabela results 38 Figura 27 Componentes Principais da Soluc¸ ˜ ao 39 Figura 28 Dia de Previs˜ ao 44 Figura 29 Previs˜ ao de um Produto para Cinco Dias 45 Figura 30 Lista de Tarefas Ordenadas 46 vii 2.2. SAP Leonardo Machine Learning 4 Nas seguintes secc¸ ˜ oes ser˜ ao descritas com detalhe cada uma delas. 2.2 sap leonardo machine learning O SAP Leonardo Machine Learning inclui uma vasta gama de de aplicac¸ ˜ oes e servic¸os que v˜ ao desde IoT, Blockchain, Machine Learning, Big Data, Data Intelligence, Design Thinking e Analystics oferecidos pela SAP como podemos ver na Figura 1. Figura 1.: Aplicac¸ ˜ oes e servic¸os do SAP Leonardo Machine Learning O SAP Leonardo Machine Learning ´ e uma ferramenta do portf´ olio das aplicac¸ ˜ oes e servic¸os inteligentes da SAP. Podemos ter uma vis˜ ao geral dos seus componentes na Figura 2. Figura 2.: Vis˜ ao geral dos componentes SAP Leonardo Machine Learning Esta nova ferramenta inclui trˆ es componentes, sendo eles: •HANA (PAL) esta faz parte da biblioteca de func¸ ˜ oes de aplicac¸ ˜ oes (AFL) do HANA e define func¸ ˜ oes que podem ser chamadas dentro dos procedimentos SAP HANA SQLScript para executar algoritmos anal´ ıticos preditivos; 2.2. SAP Leonardo Machine Learning 5 •SAP Predictive Analytics esta aplicac¸˜ ao independente pode ser usada para criar modelos preditivos em conjunto com a HANA (PAL); •SAP Leonardo Machine Learning Foundation na cloud SAP, este consiste em API’s de Machine Learning dispon´ ıveis via API Business Hub podendo ser implementadas como Application Programming Interface (API’S) REST, como se pode ver na Figura 3. Figura 3.: Diferentes servic¸os fornecidos pela SAP Leonardo Machine Learning Foundation Com a SAP HANA ´ e poss´ ıvel competir estrategicamente no mercado de neg´ ocio de forma a tomar melhores decis˜ oes e mais r´ apidas. O software do sistema de gest˜ ao de base de dados para otimizar o armazenamento dos mesmos pode ajudar na tomada de decis˜ oes. ´ E poss´ ıvel executar an´ alises avanc¸adas em conjunto com transac¸ ˜ oes de alta velocidade para dados em tempo real de forma a obter respostas precisas e atualizadas numa frac¸˜ ao de segundos. A plataforma SAP HANA utiliza uma base de dados na mem´ oria que elimina agregados predefinidos, visualizac¸ ˜ oes materializadas e duplicac¸˜ ao de dados entre sistemas operacionais e de suporte ` a decis˜ ao podendo obter em tempo real o resultado. A PAL fornecida com o SAP HANA permite definir func¸ ˜ oes que podem ser definidas dentro de procedimentos, sendo o SQLScript do SAP HANA uma extens˜ ao do DomainSpecific Language (SQL), inclui recursos aprimorados de fluxo de controlo que permite executar algoritmos anal´ ıticos preditivos com toda a l´ ogica da aplicac¸˜ ao definida dentro dos procedimentos da base de dados. A SAP oferece servic¸os preditivos que ajudam a executar an´ alises de dados no SAP HANA Data Base. Com o servic¸o integrado do SAP Predictive Analytics ´ e poss´ ıvel utilizar algoritmos preditivos e Machine Learning para avaliar a probabilidade dos resultados futuros de forma a orientar as decis˜ oes. Este servic¸o integrado ´ e uma estrutura que permite que as aplicac¸ ˜ oes da SAP incorporem modelos preditivos nativamente. J´ a no que diz respeito ao SAP Leonardo Machine Learning Foundation ´ e um software inteligente de servic¸os de Machine Learning com o intuito de melhorar os processos de neg´ ocio com algoritmos inteligente usando recursos de aprendizagem da m´ aquina. Este software 2.2. SAP Leonardo Machine Learning 6 pode ser usado para desbloquear o conhecimento de dados estruturados ou n˜ ao estruturados usando a tecnologia de Machine Learning com a ajuda de API’S f´ aceis de usar. Em suma, na Figura 4´ e apresentado um diagrama com a combinac¸˜ ao de todos os componentes do SAP Machine Learning. Figura 4.: Diagrama de Componentes da SAP 2.3. SAP HCP (Hana Cloud Platform) 7 2.3SAP HCP (hana cloud platform) A SAP HCP ´ e uma plataforma de Cloud in-memory da SAP que oferece um conjunto de servic¸os de aplicac¸ ˜ ao (integrac¸˜ ao, portal, mobile, an´ alises, colaborac¸˜ ao, etc...), como podemos verificar na Figura 5. Estes permitem criar aplicac¸ ˜ oes modernas de forma flex´ ıvel e eficiente, sendo tamb´ em poss´ ıvel usar o SAP HCP como uma base de dados como servic¸o. Figura 5.: SAP HCP Esta plataforma ´ e uma oferta de plataforma como servic¸o Platform as a Service (PaaS) que oferece um ambiente de desenvolvimento e de tempo de execuc¸˜ ao para aplicac¸ ˜ oes na cloud n˜ ao havendo limitac¸ ˜ oes em relac¸˜ ao ao tipo de aplicac¸˜ ao que pode ser desenvolvido na plataforma. De seguida, s˜ ao apresentados e ilustrados na Figura 6, trˆ es dos principais cen´ arios utilizados. Figura 6.: Principais Cen´ arios Utilizados •Estende soluc¸ ˜ oes SAP existentes em execuc¸˜ ao na cloud, assim como, extens˜ oes personalizadas na mesma; •Estende soluc¸ ˜ oes SAP em execuc¸˜ ao no data center com extens˜ oes personalizadas em execuc¸˜ ao na cloud; •Cria novas soluc¸ ˜ oes personalizadas em execuc¸˜ ao na cloud. 2.3. SAP HCP (Hana Cloud Platform) 8 Como base na sua arquitetura, temos o SAP HANA, que ´ e uma base de dados em mem´ oria com uma plataforma de aplicac¸ ˜ oes completa, para al´ em de que, d´ a a possibilidade de persistir dados. Esta aplicac¸˜ ao fornece tamb´ em v´ arias bibliotecas para consultar ou manipular dados, como an´ alise preditiva, pesquisa difusa e extrac¸˜ ao de texto. A SAP HCP tem para tal dispon´ ıvel seguintes funcionalidades: •Transac¸ ˜ oes: armazena os dados transacionais em tempo real e disponibiliza dados quanto necess´ ario, como por exemplo, para an´ alise. •An´ alise: fornece an´ alises em tempo real de grandes quantidades de dados. Permite a operac¸˜ ao de analisar dados textuais se os dados estiverem estruturados em ficheiros. •Espacial: permite a visualizac¸˜ ao de dados e exibic¸˜ ao contendo elementos geogr´ aficos. Al´ em dos servic¸os de base de dados, a plataforma fornece recurso adicionais (AppServices), chamados de Enablement Services eApplication Services. Para facilitar o r´ apido desenvolvimento de aplicac¸ ˜ oes em cloud, a plataforma fornece um vasto conjunto de servic¸os e ativac¸ ˜ oes para o uso mais comum em engenharia de software, como persistˆ encia, conectividade, etc... A SAP al´ em dos servic¸os mencionados tamb´ em oferece um conjunto de servic¸o de alto n´ ıvel chamados servic¸os de aplicac¸ ˜ oes, como ilustrado na Figura 7, que fornecem recursos especializados e necess´ arios para os diversos cen´ arios. Figura 7.: Arquitetura SAP HCP 2.4. SAPUI5(SAP User Interface 5)9 2.4 sapui5 (sap user interface 5) SAPUI5´ e uma estrutura que inclui uma colec¸˜ ao de bibliotecas que podem ser usadas para construir aplicac¸ ˜ oes para serem executadas num browser de computador ou de mobile (smartphones, tablets). Os controlos da inteface do utilizador adaptam-se automaticamente ` as capacidades de cada dispositivo. Figura 8.: SAPUI5 Em s´ ıntese, a SAPUI5´ e uma tecnologia de interface do cliente e como podemos verificar na Figura 8´ e baseada em JavaScript, CSS, e HTML5, sendo que, os servidores entram em ac¸˜ ao para implementar as aplicac¸ ˜ oes, armazenando as biblioteca SAPUI5e ligando-se a uma base de dados. Esta framework suporta v´ arias func¸ ˜ oes para se adaptar aos sistemas operacionais e dispositivos. No que diz respeito ao desenvolvimento de aplicac¸ ˜ oes, os modelos de destas incorporam as recomendac¸ ˜ oes mais recentes do SAP e podem ser usadas como ponto de partida para o desenvolvimento de aplicac¸ ˜ oes, tendo os seus componentes independentes, podendo ser reutiliz´ aveis e usados nas aplicac¸ ˜ oes SAPUI5. Consoante o ambiente no qual se est´ a a usar o SAPUI5, as bibliotecas e as aplicac¸ ˜ oes s˜ ao armazenadas. Nesta aplicac¸˜ ao em particular ser´ a armazenada no SAP HCP sendo que poderia ser noutro servidor. Inicialmente ´ e necess´ ario entender o conceito b´ asico de desenvolvimento subjacente do SAPUI5. 2.4. SAPUI5(SAP User Interface 5)10 Este suporta o conceito Model View Controller (MVC), ilustrado na Figura 9, que ´ e um padr˜ ao de arquitetura frequentemente usado para desenvolver interfaces de utilizadores onde uma aplicac¸˜ ao ´ e dividida em trˆ es partes interconetadas. Figura 9.: Conceito MVC Omodelo ´ e respons´ avel por gerir, recuperar e atualizar os dados que est˜ ao a ser visualizados na aplicac¸˜ ao. A parte que ´ e encarregue por interpretar e renderizar a interface inicial ´ e a visualizac¸ ˜ ao, que no contexto do SAPUI5, gera a apresentac¸ ˜ ao para o utilizador com base nas mudanc¸as do modelo. Sendo o controlador uma das partes mais importantes ´ e respons´ avel por separar a l´ ogica de visualizac¸˜ ao da l´ ogica de dados. Este responde ` a comunicac¸˜ ao do utilizador e ”visualiza eventos”de forma a ajustar a vis˜ ao e o modelo, basicamente envia comandos ao modelo para atualiza-los. 3 PROPOSTA DA ABORDAGEM Na Accenture, recentemente, foi desenvolvida uma aproximac¸˜ ao ´ a soluc¸˜ ao de gest˜ ao de ”Point Of Sale” suportada pela plataforma SAP HCP. Com a nova ferramenta ser´ a poss´ ıvel prever a falta de consum´ ıveis para o bom funcionamento da m´ aquina, como por exemplo, copos, caf´ e e ac¸ ´ ucar. Para que, futuramente seja poss´ ıvel ter uma melhor gest˜ ao das rotas e das tarefas dos funcion´ arios, assim como, ter uma lista de tarefas que ser˜ ao ordenadas por ordem de distˆ ancia e prioridade. Visto que a soluc¸˜ ao j´ a implementada n˜ ao tira proveito de todas as funcionalidades que a SAP HCP (SAP,2018) tem dispon´ ıveis nem responde a todos os requisitos que o cliente apresentou, os objetivos para conceber uma soluc¸˜ ao adequada ser˜ ao: •Corrigir erros que a atual aplicac¸˜ ao tem. •Aumentar as funcionalidades j´ a disponibilizadas pela aplicac¸˜ ao de Gest˜ ao de Pontos de Venda existente. •Estudar e desenvolver um sistema de suporte ` a decis˜ ao com an´ alise preditiva. •Prever a necessidade de reposic¸˜ ao de consum´ ıveis, como por exemplo, reposic¸˜ ao de caf´ e. •Analisar a informac¸˜ ao do hist´ orico das tarefas realizadas pelos funcion´ arios de modo a fazer uma gest˜ ao otimizada que reduza o tempo por tarefa. •Antecipar a necessidade de manutenc¸˜ ao nos pontos de venda, como por exemplo, trocar a bomba da ´ agua. De modo a responder aos requisitos que o cliente propˆ os e de forma a atingir os objetivos descritos acima a abordagem ser´ a a seguinte: •Desenvolvimento do documento de requisitos; •Definic¸˜ ao da arquitetura do projeto; •Desenvolvimento de prot´ otipos com recurso ` as tecnologias propostas; 11 3.1. Definic¸˜ ao da Arquitetura 12 •Implementac¸˜ ao e configurac¸˜ ao da soluc¸˜ ao; •Teste da soluc¸˜ ao desenvolvida; •Disponibilizac¸˜ ao da aplicac¸˜ ao. Os requisitos da aplicac¸˜ ao encontram-se descritos no Anexo A. 3.1 definic¸˜ ao da arquitetura Inicialmente a arquitetura definida para a aplicac¸˜ ao ´ e a que se encontra ilustrada na Figura 10. Na gerac¸˜ ao de dados (Data Genaration) tinha-se como base um controlador com sensores instalados para a recolha de dados das m´ aquinas. O controlador faz a ligac¸˜ ao com a parte de agregac¸˜ ao de dados (Data Aggregation) de cada sensor por Message Queuing Telemetry Transport (MQTT), este ´ e um protocolo de mensagens para sensores otimizado para redes Protocolo de Controle de Transmiss˜ ao/Protocolo de Internet (TCP/IP) permitindo a troca de mensagens. ´ E nesta fase, agregac¸˜ ao de dados, que se verifica se o limite pr´ e-definido para cada um dos sensores foi ultrapassado ou n˜ ao para que seja ligada a luz do sensor correspondente no caso do limite definido anteriormente para cada sensor fosse ultrapassado sendo enviada uma mensagem. A comunicac¸˜ ao para a Plataforma SAP IoT (SAP IoT Platform) era feita atrav´ es de HTTPS com token para o envio dos dados conforme o tipo de autenticac¸˜ ao que foi executada, onde a rotina em Java, era utilizada para interagir com o servic¸o (Document Service) na Plataforma da Aplicac¸˜ ao SAP (SAP Application Platform). Existiam dois tipos de servic¸os na Plataforma SAP IoT, o IoT que servia para tratar da informac¸˜ ao recebida dos sensores fazendo a ligac¸˜ ao ` a rede, sendo tamb´ em, poss´ ıvel transmitir os dados. J´ a na o servic¸o OAuth 2.0Service era utilizado para fazer a autenticac¸˜ ao dos diferentes utilizadores. O SAP HCP era utilizado para armazenar a informac¸˜ ao recebida dos sensores. A ligac¸˜ ao desta para a Plataforma da Aplicac¸˜ ao SAP tamb´ em era feita atrav´ es de HTTPS com token e conforme o tipo de autenticac¸˜ ao executado o envio dos dados ser´ a diferente. Nesta plataforma existiam dois tipos de rotinas, a rotina Java que servia para fazer a ligac¸˜ ao entre as duas plataformas e a rotina HANA Extended Service que permite criar a aplicac¸˜ ao completamente independente do SAP HCP trazendo assim vantagens no desempenho devido ` a proximidade da l´ ogica de fluxo da aplicac¸˜ ao e controlo para a base de dados. Tendo s´ o um servic¸o nesta parte da aplicac¸˜ ao o Document Service servia para guardar os manuais de cada m´ aquina. 3.1. Definic¸˜ ao da Arquitetura 13 Aqui a base de dados na SAP HCP era onde se encontrava toda a l´ ogica da mesma e a aplicac¸˜ ao Field Service Management, utilizada para apresentar os dados recolhidos. Figura 10.: Arquitetura Antiga A proposta da nova arquitetura segue na Figura 11 onde est˜ ao representas as alterac¸ ˜ oes que est˜ ao a ser implementadas. Na gerac¸˜ ao de dados (Data Genaration) teremos uma m´ aquina com sensores instalados para a recolha dos dados a serem tratados, estes s˜ ao enviados por MQTT (como anteriormente) para, nesta nova arquitetura, IoT Edge Gateway onde v˜ ao ser agregados os dados recolhidos na gerac¸˜ ao de dados. Estes dados ser˜ ao envidados para o SAP IoT Platform por HTTPS, agora sem token, que ter´ a como servic¸o Internet of Things Service Leonardo Cloud Foundry 4.0que oferece trˆ es servic¸os ´ uteis para a continuac¸˜ ao do desenvolvimento da aplicac¸˜ ao, sendo eles: configurar, preencher, manter e armazenar dados de IoT e Big Data, assim como o acesso de autorizac¸˜ ao e gest˜ ao de eventos. No meio ambiente (Environment) temos os Cloud Foundry que integra os servic¸os de aplicac¸˜ ao estendidos ao SAP HCP que ´ e onde se encontram os dados recolhidos pelos sensores na base de dados. O Cloud Foundry permite desenvolver e implementar aplicac¸ ˜ oes de Web sendo este utilizado para o mesmo efeito. A comunicac¸˜ ao entre SAP IoT Platform e SAP Aplication Platform tamb´ em ser´ a feita por HTTS sem token. Esta tem como rotinas o SAP Hana Extended Service, que ser´ a mantida da arquitetura anterior e usada para o mesmo efeito, e HyperText Markup Language, Vers˜ ao 5 4.2. O Sistema de Programac¸˜ ao R 20 Este mecanismo eficiente de troca de dados faz com que seja suportada a transferˆ encia de tabelas intermedi´ arias directamente para as estrutura de dados do R, tendo por isso, uma vantagem de desempenho. 4.2 o sistema de programac¸˜ ao r R´ e uma linguagem criada na d´ ecada de 1990 por Ross Ihaka (1996)eRobert Gentleman concebida com o objetivo de ser usada para c´ alculo estat´ ıstico, an´ alise dados e representac¸˜ ao gr´ afica de dados. Esta linguagem de programac¸˜ ao possui uma extensa biblioteca de ferramentas para manipulac¸˜ ao de base de dados que tornam a an´ alise de dados mais f´ acil, mais acess´ ıvel e mais detalhada. Quanto ao que toca ` a aprendizagem m´ aquina o R fornece v´ arias ferramentas para treinar e avaliar modelos de classificac¸˜ ao e agrupamento (agregac¸˜ ao), bem como para prever eventos futuros. De modo geral existem trˆ es tipos de algoritmos de aprendizagem m´ aquina em R. •Aprendizagem Supervisionada - que consiste numa vari´ avel dependente que deve ser prevista a partir de um conjunto de vari´ aveis independentes. Utilizando esse conjunto ´ e gerada uma func¸˜ ao que mapeia as entradas para as sa´ ıdas desejadas, sendo que, o processo de treino continua at´ e que o modelo atinja um n´ ıvel desejado de precis˜ ao nos dados de treino. •Aprendizagem n˜ ao supervisionada - este algoritmo n˜ ao tem nenhuma vari´ avel para prever nem nenhuma como resultado. ´ E usado para agrupar a populac¸˜ ao em diferentes grupos para uma intervenc¸˜ ao espec´ ıfica. •Aprendizagem por reforc¸o - na aprendizagem por reforc¸o os algoritmos s˜ ao treinados para tomar decis˜ oes e com base nessas decis˜ oes este recebe um sinal para saber se a decis˜ ao tomada foi a certa ou a errada. Com base nesse conhecimento o algoritmo ajusta a estrat´ egia para tomar decis˜ oes certas. Feita uma pesquisa dos tipos de aprendizagem m´ aquina o tipo de algoritmos a utilizar para a resoluc¸˜ ao do problema foi selecionada a aprendizagem supervisionada, pois esta prevˆ e a vari´ avel atrav´ es da vari´ avel independente. Posto isto, foi feita uma an´ alise dos algoritmos de aprendizagem supervisionada que poderiam ser mais adequados para prever a quantidade de produtos para cada dia no futuro. Realizada essa an´ alise, os algoritmos utilizados para a resoluc¸˜ ao do problema ser˜ ao apresentados de seguida. 4.2. O Sistema de Programac¸˜ ao R 21 4.2.1Algoritmos R Utilizados Para a utilizac¸˜ ao dos algoritmos a seguir descritos, foi criada uma tabela nomeada de PREDICTION com a QUANTITY,DATE,PRODUCTID eMACHINEID da tabela IOTSERVICE para uma m´ aquina e para um produto. Na Figura 12 encontra-se uma pequena amostra da tabela IOTSERVICE. Figura 12.: Amostra da Tabela IOTSERVICE A quantidade do produto seleccionado foi agrupada por dia, pelo identificador do produto e da m´ aquina, para que, posteriormente se consiga prever a quantidade futura para cada dia. A query exemplo utilizada para inserir os dados na tabela PREDICTION foi a que se encontra no C´ odigo 4.1e o resultado da mesma ´ e apresentado na Figura 13. SELECT " QUANTITY " , TO_ VARCHAR (" DATEIOT " ,’DD -MM - YYYY ’) AS DATEIOT ," PRODUCTID " ," MACHINEID . MACHINEID " FROM ( SELECT TO_ DECIMAL ( SUM (" QUANTITY ")) AS " QUANTITY " , " DATEIOT " , " PRODUCTID ", " MACHINEID . MACHINEID " FROM " ACN _ PORTUGAL _ BRAGA _ IOT _ POS "." acn . Portugal _ Braga _ IoT _POS . acn .cg . iotposdemo .d. data :: CGSDB . IOTSERVICE " WHERE " PRODUCTID " = ’ 4504 ’ AND " MACHINEID . MACHINEID " = ’ 1100900 ’ GROUP BY " DATEIOT " , " PRODUCTID ", " MACHINEID . MACHINEID " ORDER BY " DATEIOT " asc ); Listing 4.1:Query exemplo Figura 13.: Amostra do resultado da query 4.2. O Sistema de Programac¸˜ ao R 22 Os Algoritmos estudados para a previs˜ ao da quantidade de cada produto da m´ aquina foram: •M´ etodo Seasonal Na¨ ıve - este m´ etodo usa os valores do ano anterior para prever os valores do pr´ oximo ano. Por exemplo, o valor das vendas do dia de hoje vai servir para a previs˜ ao do pr´ oximo ano. •M´ etodo Error, Tend, Seasonality (ETS) - as previs˜ oes deste m´ etodo s˜ ao calculadas com base nos valores existentes. Os valores previstos s˜ ao uma continuac¸˜ ao dos valores do hist´ orico na data especificada. •M´ etodo Autoregressive Integrated Moving Average (ARIMA) -om´ etodo ARIMA vaise ajustado aos valores j´ a existentes para que consiga prever dados futuros. No cap´ ıtulo seguinte ser˜ ao apresentadas e explicadas as raz˜ oes que levaram ` a escolha do algoritmo utilizado para a resoluc¸˜ ao do problema. 5 PREVIS ˜ AO EM R: IMPLEMENTAC¸ ˜ AO, TESTES E INTEGRAC¸ ˜ A O Neste cap´ ıtulo ser´ a apresentado o algoritmo R utilizado para a previs˜ ao dos produtos, assim como, os teste e os resultados obtidos. A implementac¸˜ ao e os procedimentos usados tamb´ em ser˜ ao mostrados neste cap´ ıtulo. 5.1 preparac¸˜ ao e an ´ alise dos dados Como foi dito no cap´ ıtulo anterior, criou-se a tabela referida na sub-secc¸˜ ao 4.2.1, selecionando uma m´ aquina e um produto para fazer a soma das quantidades do produto agrupadas por dia. Os valores dessa tabela, obtidos como se explicou, foram guardados num ficheiro Comma-Separated Values (CSV) para serem usados no algoritmos no R. Para o desenvolvimento da soluc¸˜ ao foram usados trˆ es packages do R, o fpp descrito por Hyndman and Athanasopoulos (2013) no livro ”Forecasting: Principles and Practice (fpp)”que se tornou um dos mais famosos para a previs˜ ao com s´ eries temporais mas que depende de algum trabalho de preparac¸˜ ao de dados (pr´ e-processamento), o qual pode ser assegurado pelo package ggplot2que foi criado por Wickham (2016)eopackage lubridate que foi criado por Grolemund and Wickham (2011) para facilitar as alterac¸ ˜ oes necess´ arias a datas e horas. O programa desenvolvido comec¸a por limpar todas as vari´ aveis do espac¸o de trabalho impedindo assim que se use vari´ aveis que j´ a foram definidas h´ a muito tempo, ou que, n˜ ao s˜ ao as que pretendemos usar. Assim, limpa-se as listas de vari´ aveis cada vez que se iniciar a previs˜ ao. Seguidamente o package de previs˜ ao fpp,´ e carregado usando a nova vers˜ ao do mesmo que ir´ a carregar, tamb´ em, o package ggplot2por tr´ as. Ser´ a carregado tamb´ em o package lubridate que vai ser usado para tratamento das datas, convertendo-as para o formato pretendido. Posto isto, foram carregados os dados do ficheiro CSV usando o comando: data <- read. csv("C :\\ Users \\R\\ data .csv ") Listing 5.1: Carregamento dos dados 23 5.1. Preparac¸˜ ao e An´ alise dos Dados 24 Estes dados, s˜ ao lidos para um quadro com o nome data, mas para a utilizac¸˜ ao correta dos mesmos como s´ erie temporal, ter˜ ao de ser carregados para uma vari´ avel declarada adequadamente como dados de s´ eries temporais. Assim ´ e aberto todo um universo de operac¸ ˜ oes que s˜ ao extremamente ´ uteis para a previs˜ ao. A vari´ avel utilizada para a declarac¸˜ ao dos dados da s´ erie temporal foi nomeada de Y utilizando-se depois a func¸˜ ao ts (time series) do R para converter o nosso data para uma s´ erie temporal (C´ odigo 5.2). Foi, ent˜ ao, seleccionada a primeira coluna dos dados como s´ erie temporal pois ´ e a que tem os valores das vendas das quantidades dos produtos, de seguida ´ e dito que a s´ erie temporal comec¸a em 2018 no dia 1do ano em quest˜ ao e como queremos ter uma previs˜ ao di´ aria, ou seja, sendo a durac¸˜ ao m´ edia de um ano 365.25 dias para serem permitidos os anos bissextos, foi ent˜ ao definida uma frequˆ encia de 365.25 vezes por ano. Y <- ts( data [ ,1], start =c (2018 ,1) , frequency = 365.25) Listing 5.2: Declarac¸˜ ao da S´ erie Temporal Para realizar uma an´ alise preliminar dos dados foi ent˜ ao feita uma an´ alise gr´ afica da s´ erie ao longo do tempo, pois ´ e importante para percebermos a sua sazonalidade. Usando a func¸˜ ao autoplot para gerar o gr´ afico da s´ erie temporal Y, de seguida foi dado um t´ ıtulo ao mesmo e no eixo dos y foi colocado um r´ otulo para ser mais f´ acil a sua interpretac¸˜ ao (C´ odigo 5.3). autoplot (Y) + ggtitle (" Time plot ") + ylab (" Quantity ") Listing 5.3: Func¸˜ ao autoplot para gerar o gr´ afico da S´ erie Temporal Seguidamente, na Figura 14, verificamos que as vendas ao logo do tempo tˆ em praticamente a mesma repetic¸˜ ao de vendas (tendˆ encia), parecendo haver alguns comportamentos similares (padr˜ oes sazonais), como por exemplo, no inicio do ano 2019 as vendas s˜ ao bastante parecidas com o inicio do ano 2018. Sendo dif´ ıcil de avaliar sem fazer mais algumas an´ alises e parecendo haver padr˜ oes regulares, foi feita outra an´ alise dos dados. Os dados tˆ em uma forte tendˆ encia, e por isso, alguns m´ etodos de previs˜ ao n˜ ao ser˜ ao capazes de utilizar os dados com essa mesma tendˆ encia, pois esta ´ e muito forte para a sazonalidade. 5.1. Preparac¸˜ ao e An´ alise dos Dados 25 Figura 14.: Gr´ afico de vendas Se a tendˆ encia for muito forte em relac¸˜ ao ` a sazonalidade pode-se tornar dif´ ıcil ver se s˜ ao padr˜ oes sazonais. Posto isto, foi feita uma transformac¸˜ ao nos dados, que consiste em de avaliar a quantidade vendas por mˆ es em vez de avaliar a quantidade bruta das vendas. Ou seja, construindo uma func¸˜ ao diff que resumidamente calcula a diferenc¸a entre as quantidades mensais vendidas, sendo esta nomeada de DY, D para a diferenc¸a e Y que ´ e o nome dos nossos dados. DY <- diff (Y) # Time plot the difference data autoplot ( DY) + ggtitle (" Time plot DY ") + ylab (" Quantity ") Listing 5.4: Transformac¸˜ ao dos dados e gr´ afico dos mesmos Constru´ ıda a func¸˜ ao com a diferenc¸a entre as quantidades mensais vendidas, foi elaborado outro gr´ afico para ter uma leitura mais f´ acil e r´ apida vendo a mudanc¸a dos dados. Como podemos verificar na Figura 15 existem flutuac¸ ˜ oes realmente grandes mas j´ a n˜ ao existe tendˆ encia, como no dito no exemplo anterior, verificasse que no in´ ıcio de 2019 j´ a n˜ ao ´ e t˜ ao semelhante ao in´ ıcio de 2018 como anteriormente. 5.1. Preparac¸˜ ao e An´ alise dos Dados 26 Figura 15.: Gr´ afico de diferenc¸as de vendas Posto isto, foi analisada a sazonalidade dos dados, pois ´ e importante perceber se estava a acontecer o mesmo todos os meses de cada ano ou se era irregular, sendo que, isso iria fazer diferenc¸a na forma como os dados ser˜ ao tratados para a previs˜ ao. Tendo em conta que a library de previs˜ ao do R tem uma func¸˜ ao bastante ´ util para investigar a sazonalidade, conseguimos ver a diferenc¸a das vendas nos diferentes dias e nos diferentes anos como ´ e ilustrado na Figura 16. Cada ano tem a sua pr´ opria linha e cor para que seja mais f´ acil identificar as vendas desse ano. A Figura 16 ilustra as vendas dos anos 2018 e2019 para o produto e m´ aquina referidos anteriormente, com uma relac¸˜ ao de quantidade por cada dia do ano. Com se pode verificar as vendas de 2018 e2019 s˜ ao bastante parecidas em termos de quantidade por dia, ent˜ ao isso sugere que temos per´ ıodos regulares e alguns padr˜ oes sazonais. 5.1. Preparac¸˜ ao e An´ alise dos Dados 27 Figura 16.: Gr´ afico gerado com a func¸˜ ao ggseasonplot Existem flutuac¸ ˜ oes ao longo do tempo e acontece ao longo de todo o ano e isso acaba por influenciar o tipo de modelo que ir´ a ser usado para a previs˜ ao. Aqui ´ e que a s´ erie tem tendˆ encia e sazonalidade, assim sendo, precisamos de considerar a tendˆ encia e a sazonalidade para a escolha do m´ etodo de previs˜ ao. 5.1.1Testes e Resultados Posteriormente ao carregamento, tratamento dos dados e a an´ alise dos mesmos, como explicado na secc¸˜ ao anterior, foram usados v´ arios m´ etodos de previs˜ ao para avaliar qual o mais adequado para prever a quantidade das vendas. Primeiramente foi usado o m´ etodo de benchmark pois este ´ e o mais simples poss´ ıvel. Este m´ etodo calcula a m´ edia dos dados e apenas prevˆ e que todos os dias no futuro ser˜ ao iguais ` a m´ edia da amostra. Pegando na diferenc¸a de dados calculada anteriormente este m´ etodo n˜ ao iria fazer a previs˜ ao pretendida, pois iria ter o mesmo valor nos dias futuros e claramente isso n˜ ao acontece nos dados analisados, sendo que tamb´ em iria perder as oscilac¸ ˜ oes, ou seja, padr˜ oes sazonais regulares que observamos na Figura 15. 5.2. M´ etodo Seasonal Naive 28 5.2 m ´ etodo seasonal naive Posto isto, foi testado outro m´ etodo de previs˜ ao o seasonal naive (snaive) que diz que o valor da previs˜ ao para o tempo T + h (tempo T e perspectiva de previs˜ ao h) ´ e dado por: b YT+h|T=YT+h−m(k+1) Esta formula diz que, por exemplo, o valor das vendas no dia 22 de Abril de 2018 ser´ a igual ao valor das vendas no dia 22 de Abril de 2019. Sendo que, o m´ e o per´ ıodo sazonal (de 2018-04-22 a2019-04-22) e k´ e a parte inteira do calculo de (h−1)/m onde h´ e o futuro da previs˜ ao e o Ycont´ em os dados da s´ erie temporal. Como observado na Figura 16 temos uma grande sazonalidade, ent˜ ao este m´ etodo ser´ a bom para usar, mas ´ e preciso ter em conta que os dados brutos tˆ em uma tendˆ encia que levaria a dizer que as vendas dos dias previstos no inicio do ano seriam semelhantes ´ as dos dias iniciais do ano anterior. Portanto, foram usados os dados da diferenc¸a definidos anteriormente e, desta forma, os erros poderiam ser muito alto como muito baixos, mas em m´ edia podem ser muito perto de zero. Visto que existe uma func¸˜ ao incorporada no package de previs˜ ao do R (snaive) foi ent˜ ao usada com o DY (nome dado ` a diferenc¸a de dados) e feito um resumo deste ajuste ao modelo para se poder verificar os res´ ıduos. fit <- snaive ( DY) print ( summary ( fit )) checkresiduals(fit) Listing 5.5: M´ etodo Seasonal Naive e visualizac¸˜ ao dos seus resultados Ao ajustar este modelo ´ e criado um novo objecto, sendo ele um container (vari´ avel que tem muitas sub-vari´ aveis). No C´ odigo 5.5existem algumas func¸ ˜ oes internas que utilizam a informac¸˜ ao criada pelo m´ etodo, tais como, summary echeckresiduals. Comec¸ando com a func¸˜ ao summary esta diz qual foi o m´ etodo usado e qual o desvio padr˜ ao residual e esta ser´ a a medida usada para saber o qu˜ ao bem os dados est˜ ao a ser utilizados pelo m´ etodo, sendo que, quanto mais pr´ oximo de zero este n´ umero for melhor ser´ a o modelo. 5.2. M´ etodo Seasonal Naive 29 Figura 17.: Resumo do M´ etodo snaive Este modelo ´ e relativamente simples, pois este diz que o valor do dia atual ´ e o mesmo que o valor h´ a exactamente um ano atr´ as e onde o desvio padr˜ ao residual ´ e de 33.5286 o que pode ser ou n˜ ao um valor muito grande pois depende dos dados. Posto isto, foram verificados os res´ ıduos para ent˜ ao ter uma melhor avaliac¸˜ ao do qu˜ ao bem os dados est˜ ao a ser ajustados neste modelo. Usando a func¸˜ ao checkresiduals com o resultado do m´ etodo snaive ´ e poss´ ıvel ver na Figura 18 um gr´ afico com os res´ ıduos, um gr´ afico com os Estimating the Autocorrelation Function (ACF) e um histograma dos res´ ıduos. 5.4. Modelo ARIMA 36 Esta func¸˜ ao recebe dois argumentos, sendo passado no primeiro parˆ ametro, o modelo a ser usado (fit arima) e no segundo o tempo que queremos prever, que neste caso, ´ e de 60 dias (h=60). Executada a func¸˜ ao forecast os resultados desta s˜ ao mostrados num gr´ afico, como ´ e poss´ ıvel ver na Figura 24. Figura 24.: Gr´ aficos com os resultados da previs˜ ao Para uma melhor observac¸˜ ao dos dados foi ent˜ ao limitada a visualizac¸˜ ao aos 100 ´ ultimos registos como o include = 100 e atribu´ ıda uma legenda para que se perceba melhor o gr´ afico. Posto isto, consegue-se ver que as melhores sugest˜ oes para os dados previstos, ou seja, os que est˜ ao representados pela linha azul, que s˜ ao bastante semelhantes aos dados da s´ erie temporal. A parte colorida a roxo significa os intervalos de previs˜ ao associados, tanto para o intervalo superior como para o inferior. Os valores da previs˜ ao tˆ em uma probabilidade de 80% e 95% de estarem na parte colorida a roxo. Na Figura 25 est˜ ao os dados que foram usados para a elaborac¸ ˜ ao do gr´ afico de previs˜ ao. Como se pode verificar tem uma coluna com os dados da previs˜ ao (forecast) e mais quatro colunas com os intervalos inferiores e superiores de 80% e 95% respectivamente. 5.4. Modelo ARIMA 37 Figura 25.: Resumo da previs˜ ao Adaptando os resultados dados apresentados na Figura 25, foram feitas algumas alterac¸ ˜ oes, para que no SAP HCP fosse mais f´ acil a sua leitura. # transform date _decimal to normal date date <- format ( date _ decimal ( as. numeric ( row . names ( as . data . frame ( forecasting _ output )) )) ,"%Y -%m -% d") Outputforecasting <- cbind ( date ,as . data . frame ( forecasting _ output )) Listing 5.9: Alterac¸˜ ao da formatac¸˜ ao da data. A primeira alterac¸˜ ao foi no campo da data, pois as datas estavam em formato decimal o que tornava um pouco complicado de se perceber qual era a data. 5.4. Modelo ARIMA 38 Como mostra o c´ odigo a cima, pegando na tabela resultado da previs˜ ao (forecasting output) e utilizando o package lubridate, que serve para trabalhar a data de v´ arias formas, a data foi ent˜ ao transformada para o formato ”%Y%m%d” (Y - ano, m - mˆ es, d - dia) e guardada numa nova tabela chamada Outputforecasting. Foi ent˜ ao seleccionada a primeira coluna, que ´ e onde est´ a a data guardada j´ a no formato correto, e a segunda coluna, que ´ e onde est˜ ao as melhores sugest˜ oes da previs˜ ao da tabela Outputforecasting, sendo estes dados guardados numa outra tabela chamada result. Seguidamente foram atribu´ ıdos nomes ` as colunas da nova tabela (result) como ´ e poss´ ıvel ver no C´ odigo 5.5.1. result <- data . frame ( Outputforecasting [ ,1] , Outputforecasting [ ,2]) colnames ( result ) <- c(" Date " , " Forecast ") results <- format ( result , digits =1) Listing 5.10: Guardar os resultados. O C´ odigo 5.10 demonstra que foram ent˜ ao atribu´ ıdos nomes ´ as duas colunas da tabela result, a primeira com o nome ”Date” e a segunda com o nome ”Forecast”. De seguida os dados foram guardados numa nova tabela mas com os dados da coluna forecast no formato de inteiro. Figura 26.: Tabela results 5.5. Implementac¸˜ ao do Algoritmo R no SAP HANA 39 5.5 implementac¸˜ ao do algoritmo r no SAP hana No contexto da base de dados do SAP HANA, ´ e poss´ ıvel processar c´ odigo R, incorporado no c´ odigo SQL do SAP HANA na forma de procedimento RLANG. Usando um ambiente R externo para executar o c´ odigo R, o SAP HANA f´ a-lo de maneira semelhante ` as operac¸ ˜ oes nativas da base de dados. Isto, permite que, sejam incorporadas definic¸ ˜ oes e chamadas ` as func¸ ˜ oes R no SQLScript e seja enviado todo o c´ odigo como parte de uma consulta na base de dados. O operador R consome v´ arios objectos de entrada (por exemplo tabelas) e retorna uma tabela de resultados, assim como, o faz qualquer outro operador do modelo de c´ alculo. Na Figura 27 ´ e poss´ ıvel ver os trˆ es principais componentes da soluc¸˜ ao integrada: a aplicac¸˜ ao baseada no SAP HANA, a base de dados SAP HANA e o ambiente R. Figura 27.: Componentes Principais da Soluc¸˜ ao Quando, durante a execuc¸˜ ao do plano de c´ alculo (programa), de atinge um operador R, o cliente R do mecanismo de c´ alculo lanc¸a uma solicitac¸˜ ao pelo mecanismo Rserver para ser criado um processo R dedicado. Posteriormente, o cliente R transfere de forma eficiente o c´ odigo da func¸˜ ao R, assim como as tabelas de entrada para esse processo R accionando a execuc¸˜ ao do R. Depois de conclu´ ıda a execuc¸˜ ao da func¸˜ ao, os dados produzidos do servidor R s˜ ao retornados ao Cliente R (incluido no processo de c´ alculo), sendo ent˜ ao feita uma convers˜ ao. 5.5. Implementac¸˜ ao do Algoritmo R no SAP HANA 40 Como a estrutura de dados, orientada a colunas, usada na base de dados do SAP HANA para resultados interm´ edios, ´ e portanto, muito semelhante ao data frame do R, orientado a vectores, essa convers˜ ao ´ e muito eficiente. Ter o controlo geral do fluxo situado no lado da base de dados ´ e um dos principais benef´ ıcios, pois os planos de execuc¸˜ ao da base de dados s˜ ao inerentemente paralelos e consequentemente v´ arios processos R podem ser accionados para serem executados em paralelo. 5.5.1Procedimentos Para que a implementac¸˜ ao do algoritmo R fosse poss´ ıvel na aplicac¸˜ ao, foi necess´ ario a criac¸˜ ao de dois procedimentos. Um procedimento para fazer a invocac¸˜ ao do algoritmo e outro para fazer a sua execuc¸˜ ao. Procedimento de Invocac¸ ˜ ao Com este procedimento ´ e poss´ ıvel fazer a invocac¸˜ ao do procedimento de execuc¸˜ ao, que ´ e onde se encontra o algoritmo R para a previs˜ ao da quantidade de produtos e onde s˜ ao guardados na tabela RDADOSOUTPUT os resultados do algoritmo. Neste procedimento ´ e definida a linguagem SQLScript e qual o esquema a ser usado. Seguidamente, no BEGIN, s˜ ao declaradas duas vari´ aveis, uma para o id da m´ aquina e outra para o id do produto. ´ E feita uma query onde o resultado ´ e a soma das quantidades agrupadas por data e por produto sendo este guardado no inputData. Posto isto, com os dados do inputData ´ e feita a chamada para o procedimento de execuc¸˜ ao, explicado posteriormente, tendo o resultado do procedimento os dados da tabela RDADOSOUTPUT s˜ ao apagados, evitando assim repetic¸ ˜ oes de dados, sendo de seguida feita a inserc¸˜ ao dos resultados. Na listagem abaixo, correspondente ao C´ odigo 5.11,´ e apresentado o conte´ udo do procedimento. PROCEDURE " ACN _ PORTUGAL _ BRAGA _ IOT _POS "." acn . Portugal _ Braga _ IoT _ POS . acn. cg . iotposdemo.d::RprocedureInvocation" () LANGUAGE SQLSCRIPT SQL SECURITY INVOKER DEFAULT SCHEMA " ACN _ PORTUGAL _ BRAGA _ IOT _POS " AS BEGIN DECLARE outputMachineID integer ; DECLARE outputProductID integer ; 5.5. Implementac¸˜ ao do Algoritmo R no SAP HANA 41 # QUERY DE EXEMPLO . inputData = SELECT " QUANTITY " , TO_ VARCHAR (" DATEIOT " ,’DD -MM - YYYY ’) as " DATEIOT " , " PRODUCTID " , " MACHINEID . MACHINEID " from ( SELECT TO_ DECIMAL ( SUM (" QUANTITY ")) AS " QUANTITY " , " DATEIOT ", " PRODUCTID ", " MACHINEID . MACHINEID " FROM " ACN _ PORTUGAL _ BRAGA _ IOT _ POS "." acn . Portugal _ Braga _ IoT _POS . acn .cg . iotposdemo .d. data :: CGSDB . IOTSERVICE " WHERE " PRODUCTID " = ’ 4504 ’ AND " MACHINEID . MACHINEID " = ’ 1100900 ’ GROUP BY " DATEIOT ", " PRODUCTID ", " MACHINEID . MACHINEID " ORDER BY " DATEIOT " asc ); CALL " ACN _ PORTUGAL _ BRAGA _ IOT _ POS "." acn . Portugal _ Braga _ IoT _POS . acn .cg . iotposdemo .d :: RprocedureExectution " (: inputData , output ); DELETE FROM " ACN _ PORTUGAL _ BRAGA _ IOT _ POS ". " RDADOS " WHERE " PRODUCTID " = ’ 4504 ’ AND " MACHINEID " = ’ 1100900 ’; INSERT INTO " ACN _ PORTUGAL _ BRAGA _ IOT _ POS ". "acn . Portugal _ Braga _ IoT _POS . acn .cg . iotposdemo .d. data :: RDADOSOUTPUT " SELECT "Date" , " Forecast ", " ProducId ", " MachineId " from : output as outputDados , : input as inputDados where output ." PRODUCTID " = inputData ." PRODUCTID "; commit; END; Listing 5.11: Procedimento de Invocac¸˜ ao. Procedimento de Execuc¸ ˜ ao Neste procedimento ´ e onde s˜ ao passadas as tabelas necess´ arias para a execuc¸˜ ao do c´ odigo R. Sendo que a tabela de entrada ´ e a PREDICTION e a de sa´ ıda ´ e a RDADOSOUTPUT. ´ E definida qual a linguagem a ser utiliza, neste caso RLANG, assim como o esquema a ser utilizado (ACN PORTUGAL BRAGA IOT POS). Posto isto ´ e inserido dentro do begin o c´ odigo R explicado na secc¸˜ ao anterior. Na listagem abaixo, correspondente ao C´ odigo 5.12,´ e apresentado o conte´ udo do procedimento. PROCEDURE " ACN _ PORTUGAL _ BRAGA _ IOT _POS "." acn . Portugal _ Braga _ IoT _ POS . acn. cg . iotposdemo.d::RprocedureExectution" ( IN input " ACN _ PORTUGAL _ BRAGA _ IOT _ POS ". " PREDICTION " , 5.5. Implementac¸˜ ao do Algoritmo R no SAP HANA 42 OUT output " ACN _ PORTUGAL _ BRAGA _ IOT _ POS "." RDADOSOUTPUT " ) LANGUAGE RLANG DEFAULT SCHEMA " ACN _ PORTUGAL _ BRAGA _ IOT _POS " AS BEGIN # load the forecasting package and lubridate package library ( fpp2 ) library ( lubridate ) quantity <- as . integer ( input $ QUANTITY ) # declare this as time series data Y <- ts( quantity , start =c (2018 ,1) , frequency = 365.25) # Fit ARIMA model fit _ arima <- auto . arima (Y ,d=1, D=1 , stepwise = FALSE , approximation = FALSE , trace = TRUE ) # Forecast with ARIMA fcst <- forecast ( fit _arima , h =60) # transform date _decimal to normal date date <- format ( date _ decimal ( as. numeric ( row . names ( as . data . frame ( forecasting _ output )))) ,"%Y -%m -% d") Outputforecasting <- cbind ( date ,as. data . frame ( forecasting _ output )) result <- data . frame ( Outputforecasting [ ,1] , Outputforecasting [ ,2]) colnames ( result ) <- c(" Date " , " Forecast ") output <- format ( result , digits =1) output $ PRODUCTID <- input $ PRODUCTID output $ MACHINEID <- input $ MACHINEID END; Listing 5.12: Procedimento de Execuc¸˜ ao. 5.6. Alterac¸ ˜ oes na Aplicac¸˜ ao 43 5.6 alterac¸˜ oes na aplicac¸˜ ao Para que as tarefas para reposic¸˜ ao de produtos fossem criadas de forma autom´ atica e com base na previs˜ ao dos produtos, foi criado um servic¸o que verifica se a quantidade prevista dos produtos para o dia posterior ao atual ´ e inferior ao threshold. Este servic¸o cria uma nova tarefa se isso se verificar, em que as instruc¸ ˜ oes da mesma, s˜ ao a reposic¸˜ ao do(s) produto(s) que v˜ ao ter quantidade inferior ao threshold com base na previs˜ ao. Este servic¸o ´ e executado ao abrir a aplicac¸˜ ao verificando se as tarefas necess´ arias para a necess´ aria reposic¸˜ ao dos produtos, no dia seguinte, j´ a foram criadas. Assim as tarefas de reposic¸˜ ao com base nos valores de previs˜ ao, para um determinado produto, s´ o ser˜ ao criadas uma vez por dia. Posto isto, quando o utilizador termina a tarefa de reposic¸˜ ao do(s) produto(s), os valores das quantidades vendidas na tabela IOTSERVICE ´ e alterada para zero, pois a m´ aquina n˜ ao vendeu nenhum produto no instante seguinte ` a reposic¸˜ ao, assim como, a tarefa ´ e dado por terminada, actualizando a barra de estado do produto no front-end. Com isto os valores das quantidades da tabela PREDICTION ser˜ ao alterados o que ir´ a fazer com que existam novos valores de previs˜ ao. 5.6.1Front-End Para que fosse mais f´ acil e intuitivo para o utilizador visualizar os dados de previs˜ ao, foram feitas alterac¸ ˜ oes na p´ agina de detalhes da m´ aquina na secc¸˜ ao supplies. Para que tal fosse poss´ ıvel foi implementado um datepicker onde o utilizador pode escolher o dia em que pretende ver o estado do stock dos produtos daquela m´ aquina, como se pode verificar no exemplo da Figura 28 sendo o resultado da escolha da data ´ e apresentado na mesma figura. 5.6. Alterac¸ ˜ oes na Aplicac¸˜ ao 44 Figura 28.: Dia de Previs˜ ao 5.6. Alterac¸ ˜ oes na Aplicac¸˜ ao 45 Outra novidade implementada na mesma secc¸˜ ao ´ e a possibilidade do utilizador carregar num produto e conseguir verificar o stock do mesmo nos cinco dias seguintes ao dia atual. Como se pode verificar no exemplo da Figura 29 ostock do caf´ e vai ter de ser reposto no dia 24 e com essa reposic¸˜ ao os n´ ıveis de caf´ e seguintes iram alterar sendo ent˜ ao poss´ ıvel verificar quando ter´ a de haver reposic¸˜ ao. Figura 29.: Previs˜ ao de um Produto para Cinco Dias No que diz respeito as tarefas das m´ aquinas, para tornar mais f´ acil para o utilizador saber qual a m´ aquina que est´ a mais pr´ oxima e com mais tarefas foi feita uma ordenac¸˜ ao das m´ aquinas pela menor distˆ ancia e de seguida pelo maior n´ umero de tarefas que cada m´ aquina tem. Por exemplo duas m´ aquinas que estejam ´ a mesma distˆ ancia do utilizador a m´ aquina que tem mais tarefas para executar vai aparecer em primeiro lugar. A REQUISITOS DA APLICAC¸ ˜ A O O objetivo da nova vers˜ ao desta aplicac¸˜ ao, ´ e a previs˜ ao de eventuais faltas de mercadorias e poss´ ıveis avarias que as m´ aquinas de venda de produtos possam vir a ter, otimizando a rentabilidade dos dispositivos, assim como a gest˜ ao das tarefas dos funcion´ arios. A vers˜ ao da aplicac¸˜ ao antes das alterac¸ ˜ oes para a previs˜ ao responde aos seguintes requisitos: 1. Ser poss´ ıvel visualizar todas as m´ aquinas: a) A localizac¸˜ ao; b) Identificador; c) Nome; d) Tipo; e) Estado. Ao executar a aplicac¸˜ ao, o utilizador consegue visualizar onde se encontram todas as m´ aquinas sendo poss´ ıvel escolher qual o tipo de m´ aquina, assim como, o pa´ ıs, regi˜ ao e m´ aquina. Ao escolher uma m´ aquina, o utilizador, pode visualizar o nome da m´ aquina, o seu identificador, o estado, a morada, as suas coordenadas e o contacto do cliente. 2. Ser poss´ ıvel ter uma vis˜ ao global da m´ aquina: a) Estado da localizac¸˜ ao; b) Estado dos suplementos; c) Estado da manutenc¸˜ ao d) Top de vendas; e) N´ umero de suplementos vendidos; f) Dinheiro da m´ aquina; g) Press˜ ao da ´ agua; 52 53 h) Temperatura ambiente; i) Documentac¸˜ ao. O utilizador pode ver os detalhes da m´ aquina escolhida, isto ´ e, ver ser a m´ aquina ainda est´ a no mesmo s´ ıtio da instalac¸˜ ao, a necessidade de mercadoria, manutenc¸˜ ao, assim como, o top de vendas da m´ aquina, n´ umero de produtos vendidos por dia, o dinheiro que actualmente a m´ aquina tem, a press˜ ao da ´ agua, temperatura e documentos da mesma. 3. Ver com detalhe a manutenc¸˜ ao necess´ aria da m´ aquina: a) Identificador da tarefa; b) Tipo de manutenc¸˜ ao necess´ aria; c) Descric¸˜ ao; d) Prioridade; e) Estado. ´ E poss´ ıvel ver quais as tarefas que s˜ ao necess´ arias na m´ aquina, qual a sua prioridade, o seu estado (se j´ a foram iniciada ou n˜ ao) e o identificador da tarefa, podendo assim iniciar ou terminar tarefas. 4. Ver quais os produtos da m´ aquina: a) Nome dos produtos; b) Identificador de cada produto; c) ´ Ultima reposic¸˜ ao; d) Quantidade. Como utilizador ´ e poss´ ıvel ver qual ´ e a quantidade de produtos que est˜ ao na m´ aquina sendo mostrado o nome, o identificador, quando foi a ultima reposic¸˜ ao do produto e a sua quantidade para que se possa ter uma melhor precess˜ ao das quantidades existentes na m´ aquina. 5. Ver relat´ orios (di´ ario, semanal, mensal, semestral) com detalhe: a) N´ umero de intervenc¸ ˜ oes; b) Taxa de uso; c) Tarefas; d) Temperatura m´ edia. J´ a na secc¸˜ ao dos relat´ orios ´ e poss´ ıvel ver o n´ umero de intervenc¸ ˜ oes realizadas na m´ aquina, a sua taxa de uso, as tarefas e a temperatura m´ edia por dia, semana, mˆ es ou nos ´ ultimos 6meses. 54 Com as novas alterac¸ ˜ oes, para al´ em dos requisitos descritos anteriormente, tem-se os seguintes requisitos: 1. Ver a previs˜ ao para um determinado dia: a) Nome dos produtos; b) Identificador de cada produto; c) Data da ´ ultima reposic¸˜ ao; d) Quantidade prevista de venda. O utilizador por escolher o dia em que quer ver a quantidade de produtos que se prevˆ e serem vendidos. 2. Ver a previs˜ ao de um produto para os pr´ oximos 5dias: a) Nome do produto; b) Datas dos pr´ oximos 5dias; c) N´ ıveis de quantidades previstas. Carregando num produto, o utilizador consegue visualizar as quantidades previstas, tendo por base o resultado do algoritmos de previs˜ ao, para os pr´ oximos cinco dias, podendo assim gerir as reposic¸ ˜ oes de melhor forma.