Assistant d'Analyse Personnalisée

Tal como é apresentado na secção 3.2, as especificações da base de dados são produzidas e geridas na subatividade A13 (representado na Figura 3-11) garantindo uma base de dados uniformizada e agregadora de todos os dados das ações de manutenção corretiva e preventiva, bem como dos dados de monitorização dos diversos equipamentos dos parceiros inseridos no sistema. No entanto, devido à enorme dificuldade em agregar diferentes parceiros num trabalho académico, numa fase em que se está a desenvolver um sistema num cenário inovador na área da manutenção industrial e a ser utilizado em ações de manutenção, optou-se por adequar a subatividade A13 ao parceiro existente em detrimento de o obrigar a esforços de adequação e normalização dos seus dados ao sistema conceptual. Assim, tendo em conta a necessidade premente de obtenção de dados de forma a testar o sistema efetuaram-se esforços no sentido contrário, isto é, adequou-se o sistema ao parceiro. A base de dados de suporte ao processo preditivo foi implementada de acordo com a base de dados já existente e utilizada pelo parceiro na sua atividade diária.

A Figura 4-6 apresenta a base de dados inicial do caso prático com ênfase nas chaves e relacionamentos e não nos registos, tornando mais evidente os relacionamentos entre as diversas tabelas.

Figura 4-6 - Esquema relacional da base de dados do caso prático.

Durante o procedimento de gestão de dados e consequente migração funcional para operacionalização da arquitetura proposta, capaz de traduzir uma melhoria do processo preditivo, foi criado um layer intermedio, procurando uma melhor operacionalização do modelo. Descartaram-se na sua estrutura alguns atributos face à estrutura inicial proposta, resultando uma base de dados de predição assente em duas tabelas contendo dados de monitorização e de intervenções.

De forma a explicitar a estrutura referente às duas tabelas focadas anteriormente, que servem de base ao trabalho efetuado e resultantes do processo de seleção e pré-processamento dos dados, são apresentadas seguidamente nas Tabelas 4-1 e 4-2.

Capítulo 4 | Desenvolvimento e implementação do módulo de predição 149 Tabela 4-1 - Estrutura da tabela de monitorização.

Campo Descrição

Id_registo Identificação de registo

Data_registo Data de registo dos valores monitorizados maq_id Identificação da máquina

param_id Identificação do parâmetro monitorizado value Valor monitorizado

Val_low_limit_w Valor limite baixo de alerta val_low_limit_cr Valor crítico baixo de alerta val_hi_limit_w Valor limite alto de alerta val_hi_limit_cr Valor crítico alto de alerta

A Tabela 4-1 apresenta nove campos e a respetiva descrição. Os quatro últimos campos apresentados dizem respeito a valores limites e críticos de alerta, inferiores e superiores, definidos pela empresa. Estes valores são parametrizados pelo responsável de manutenção da empresa, otimizando o momento em que serão efetuadas as intervenções preventivas condicionadas sobre o equipamento/item monitorizado visto este apresentar algum indício de falha. Basicamente estes intervalos servem para otimização do timing de intervenção sobre determinado equipamento, sendo estes valores de alerta refinados através do conhecimento empírico adquirido durante a tomada de decisão por parte do responsável de manutenção da empresa, encurtando os valores limite e críticos, e assim intervir com maior acuidade sobre determinado equipamento/item e com isto não afetar o normal funcionamento deste e da linha de produção onde está inserido. Basicamente a utilização destes limites têm um papel semelhante ao pretendido pelo modelo de predição gerado neste trabalho, i.e., indicar quando é que a falha está iminente, pelo que não representa qualquer interesse a sua integração no estudo.

No respeitante ao domínio de valores referentes ao campo “param_id”, estes estão relacionados com uma tabela denominada “livemonparams”, onde são registados diferentes parâmetros monitorizados e relativos a todas as máquinas existentes.

Ao nível do registo de intervenções, Tabela 4-2, salienta-se o campo “Avaria Tipo” que agrega registos de todas as intervenções corretivas efetuadas no equipamento/item, na sequência da ocorrência de avarias ou no âmbito da manutenção condicionada. Em termos conceptuais, o tipo de dados registados neste campo irá variar em função do detalhe da informação registada pelo parceiro.No caso concreto, o domínio de valores registados neste campo são: i) Elétrico, valor relacionado com intervenções levadas a cabo relativamente a anomalias de caracter elétrico; ii) Mecânico, identificação de intervenções de carácter mecânico; iii) Setup, relativas a afinações e parametrizações de funcionamento de um determinado equipamento/item e iv) Software, valor

relacionado com problemas de aplicações informáticas controladoras do equipamento/item. Relativamente a este ponto, a impossibilidade de uma identificação mais específica da falha é deve-se, mais uma vez, à falta de normalização de dados e a algumas incoerências no sistema de manutenção existente à data. Ultrapassada esta debilidade, poder-se-á evoluir para um patamar de funcionalidade mais conciso e uma consequente intervenção mais direcionada.

Tabela 4-2 - Estrutura da tabela de intervenções.

Campo Descrição

Intervençao Identificação de registo de intervenção

Avaria Tipo Identificação do tipo de intervenção registada (Elétrico, Mecânico, Setup e

Software)

ID Locais Identificação do local da máquina onde ocorre a intervenção ID componentes Identificação do item sujeito a intervenção

Avaria_motivos Registo do motivo da ocorrência da intervenção (Após intervenção externa, Após manutenção, Danificado, Desajustado, Desgaste, Erro, Erro de operação, Falha, Melhoria/Novos produtos, Partido e Sujidade)

Avaria_accoes Ação efetuada pela equipa de manutenção (Ajuste, Alteração, Calibração, Configuração, Limpeza, Restart, Sem ação e Substituição)

Data_registo Data de intervenção

Start_tec_id Registo do id do técnico que efetuou a intervenção maquina_id Identificação da máquina

Linha Identificação da linha de produção

Estado Registo do estado da intervenção (Fechada e Incompleta)

Estado_linha Identificação do estado da linha de produção (A 50%, A funcionar e Parada) num_perdas Registo do número de perdas com a intervenção

A base de dados de predição foi constituída através da agregação das duas tabelas apresentadas anteriormente e utilizando como campo agregador o campo “Data_registo”, resultando uma nova tabela agregadora de dados de monitorização e dados de ações de manutenção e destinada à criação e validação do modelo de predição, sendo os dados respetivamente designados por dados de treino (70%) e dados de teste (30%) prevenindo assim o sobreajustamento (overfitting), uma vez que um algoritmo treinado em demasia perde capacidade de generalização. O sobreajustamento acontece quando um modelo tem uma elevada capacidade de aprendizagem relativamente à complexidade inerente ao problema e/ou ao número de casos de treino. Esta tabela agrega os registos desde 1 de janeiro de 2012 até 31 de agosto de 2012. Para confrontação dos dados reais com os dados relativos às predições obtidas em todos os cenários validando desta forma o modelo gerado, foi utilizada uma segunda tabela contendo unicamente dados de monitorização relativos ao período de 1 de setembro de 2012 a 31 de dezembro de 2012.

Para provar a validade do sistema procedeu-se à confrontação dos resultados obtidos através dos dados da segunda tabela (dados de monitorização recolhidos entre 1 de setembro de 2012 e

Capítulo 4 | Desenvolvimento e implementação do módulo de predição 151

31 de dezembro de 2012) aplicando os diferentes cenários, com as ações de manutenção realmente levadas a cabo, no mesmo período (registo de intervenções desde 01 de setembro de 2012 a 31 de dezembro de 2012), pela empresa e assim validar o funcionamento do sistema, simulando um cenário real de ações de manutenção e monitorização continua. A Figura 4-7 apresenta uma representação gráfica da metodologia implementada para a realização do caso prático.

Figura 4-7 - Representação gráfica da metodologia seguida no caso de estudo.

Conhecida a explanação do processo de criação da base de dados e da definição da metodologia de validação dos resultados obtidos é importante salientar a forma de acesso à base de dados e consequentemente às tabelas geradas. O acesso é efetuado pelo RapidMiner instalado num sistema informático diferente do servidor onde está implementado o interface Web do sistema, no entanto na mesma Intranet 29, utilizando a mesma gama IP 30. No entanto o acesso à

base de dados poderá ser efetuado remotamente através da utilização de um repositório remoto implementado através da configuração de um acesso VPN, tecnologia referida na subsecção 3.3.1.2 deste documento.

29_{Rede de computadores privada que assenta sobre um determinado protocolo Internet, de uso exclusivo de um determinado local, como, por}

exemplo, a rede de uma empresa, podendo somente ser acedida por utilizadores internos.

30_{Identificação de um dispositivo (computador, impressora, etc) numa rede local ou pública. Cada computador na internet possui um IP (Internet}