Download PDF
ads:
UFSC - UNIVERSIDADE FEDERAL DE SANTA CATARINA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
METODOLOGIA PARA IMPLANTAÇÃO DA MANUTENÇÃO CENTRADA NA
CONFIABILIDADE: uma abordagem fundamentada em Sistemas Baseados em
Conhecimento e Lógica
Fuzzy
EMERSON RIGONI
Florianópolis - SC, Fevereiro de 2009.
ads:
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
UFSC - UNIVERSIDADE FEDERAL DE SANTA CATARINA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
METODOLOGIA PARA IMPLANTAÇÃO DA MANUTENÇÃO CENTRADA NA
CONFIABILIDADE: uma abordagem fundamentada em Sistemas Baseados em
Conhecimento e Lógica
Fuzzy
Tese submetida à
UNIVERSIDADE FEDERAL DE SANTA CATARINA
para a obtenção do grau de
DOUTOR EM ENGENHARIA MECÂNICA
EMERSON RIGONI
Florianópolis - SC, Fevereiro de 2009.
ads:
UFSC - UNIVERSIDADE FEDERAL DE SANTA CATARINA
PROGRAMA DE PÓS-GRADUAÇÃO EM ENGENHARIA MECÂNICA
METODOLOGIA PARA IMPLANTAÇÃO DA MANUTENÇÃO CENTRADA NA
CONFIABILIDADE: uma abordagem fundamentada em Sistemas Baseados em
Conhecimento e Lógica
Fuzzy
EMERSON RIGONI
Esta tese foi julgada adequada para a obtenção do título de
DOUTOR EM ENGENHARIA
ESPECIALIDADE ENGENHARIA MECÂNICA
sendo aprovada em sua forma final.
BANCA EXAMINADORA
Prof. Nelson Back, Ph.D.
Universidade Federal da Santa Catarina - UFSC
Prof. Eduardo Alberto Fancello, D.Sc.
Coordenador do POSMEC - UFSC
Prof. Jorge Coelho, D.Sc.
Universidade Federal da Santa Catarina - UFSC
Prof. Enrique Andrés López Droguett, Ph.D.
Universidade Federal de Pernambuco - UFPE
Prof. Gilberto Francisco Martha de Souza, Dr. Eng.
Universidade de São Paulo - USP
Relator
Prof. Jonny Carlos da Silva, Dr. Eng.
Universidade Federal da Santa Catarina - UFSC
Presidente
Prof. Acires Dias, Dr. Eng.
Universidade Federal da Santa Catarina - UFSC
Co-Orientador
Prof. Jonny Carlos da Silva, Dr. Eng.
Universidade Federal da Santa Catarina - UFSC
Orientador
DEDICATÓRIA
Para meus pais, Reinaldo e Lindamir, pela educação, amor, exemplos e contra-exemplos
de vida que me fortalecem e orientam meus passos.
À minha avó Helena pelo amor e a sabedoria a mim concedidos nos momentos difíceis.
Ao meu irmão Cleverson pela parceria e apoio incondicional que me complementam e
encorajam.
Para Silvana pela nossa cumplicidade e amor, pelo incentivo e companhia nos momentos
em que a serenidade me estava distante, pela ajuda e participação importante nesta
caminhada e pela paciência comigo.
AGRADECIMENTOS
Este trabalho é a concretização de um desejo pessoal e resultado de um esforço substancial de
pesquisa, explicitado aqui de maneira formal. Nesta busca de conhecimento e realização me foi grata e
fundamental a ajuda daqueles que contribuíram com esta empreitada. A estes, o meu agradecimento
sincero:
Deus, pela proteção e inspiração em todos os momentos.
Aos meus Orientadores Professores Jonny Carlos da Silva, Dr. Eng. e Acires Dias, Dr. Eng. pela
orientação, incentivo, paciência e dedicação a mim concedidos.
Aos Membros da Banca Examinadora pela atenção, gentileza e disponibilidade em ler e acrescentar o
seu conhecimento e suas contribuições ao meu trabalho.
A CAPES e a UFSC por tornarem material e intelectualmente realizável o desenvolvimento desta tese.
A UTFPR e ao DAELT pela licença capacitação que tornou possível a consecução deste trabalho.
Aos meus pais e familiares que me proporcionaram as condições necessárias para alcançar este
objetivo.
A Silvana pela ajuda sincera e carinhosa com o texto, as traduções, formatações e o companheirismo
indispensável nos momentos difíceis.
Ao Luis Alberto Galaz Mamani pelos finais de semana, nos quais se dedicou a contribuir com sua
preciosa e indispensável ajuda com os softwares.
Ao professor Iony Patriota de Siqueira, especialista em MCC, que contribui com sua experiência
durante processo de aquisição de conhecimento e validação dos softwares desenvolvidos.
Aos colegas do NEDIP, em especial ao Luis Fernando Peres Calil pelo imprescindível
compartilhamento de conhecimento, ao Heitor Azuma Kagueiama pela ajuda indispensável em muitos
momentos desta empreitada, ao Eduardo Yuji Sakurada pela acessibilidade e disposição em me ajudar
sempre, ao Leonardo Mecabô pelo compartilhamento das dificuldades e desafios no projeto SECOMP,
ao Paulo Francisco do Carmo pela troca de experiências e informações e a todos os bolsistas e
estagiários que passaram pelo NEDIP e de alguma maneira contribuíram com este trabalho.
Aos colegas Luiz Amilton Pepplow, Paulo Rogério da Silveira e Walter Luis Mikos pelas trocas de
informações e ajuda nas agruras do caminho.
Ao Ivan Eidt Colling pela ajuda com o Esperanto.
Aos meus alunos Cristiano José Gober, Luís Carlos Santos da Silva e Rogério José dos Santos por
terem aceito o desafio da validação em campo dos softwares.
Aos colegas do DAELT que me substituíram durante meu afastamento e assim tornaram possível esta
empreitada.
RESUMO
RIGONI, Emerson. METODOLOGIA PARA IMPLANTAÇÃO DA MANUTENÇÃO
CENTRADA NA CONFIABILIDADE: uma abordagem fundamentada em Sistemas Baseados
em Conhecimento e Lógica
Fuzzy
. Tese de Doutorado apresentada ao Programa de Pós-Graduação
em Engenharia Mecânica (POSMEC) da Universidade Federal de Santa Catarina (UFSC), como
requisito parcial para obtenção do título de Doutor em Engenharia Mecânica, Florianópolis, 2008.
A implantação da Manutenção Centrada na Confiabilidade (MCC) nem sempre acontece
de maneira adequada, harmoniosa e consistente, resultando em baixo comprometimento dos
mantenedores e, em casos críticos, abandono do programa de MCC pela falta de sinergia com os
objetivos da empresa. Além dos aspectos técnicos, os aspectos gerenciais também influenciam no
successo de um programa de MCC.
Este trabalho propõe uma metodologia para auxiliar a implantação da MCC, ponderando
seus pré-requisitos e auditando cada etapa do processo de implementação, reduzindo assim os
fatores críticos para o successo do programa. Tais fatores estão, na maioria das vezes, relacionados
a baixa aderência da empresa/sistema aos pré-requisitos exigidos pela MCC e/ou etapas mal
executadas durante a sua implementação. A proposta deste trabalho é ponderar as características da
empresa/sistema e as necessidades da MCC e, após a implementação de cada etapa, auditá-la para
que as inconsistências ocorridas durante sua execução não se propagem para as demais. Em etapas
específicas propõe-se também ferramentas para auxiliar a sua implementação, apoiando a tomada
de decisão frente às incertezas que se interpõem ao processo decisório.
A metodologia proposta é orientada por um Sistema Baseado em Conhecimento
Fuzzy
(SBC-
Fuzzy
) que incorpora critérios para diagnóstico e tomada de decisão, levando em conta os
aspectos técnicos, gerenciais, a experiência de programas consolidados de MCC e o
conhecimento institucional. Com esta metodologia, é possível minimizar os riscos de insucesso
das metodologias tradicionais de implantação da MCC, considerando e tratando as incertezas por
imprecisão (léxicas) do processo com uma visão holística das interações e necessidades da MCC.
O SBC-
Fuzzy
desenvolvido, bem como as ferramentas sugeridas para implementação das
etapas críticas, foram testados e validados em campo por especialistas em implantação e gestão
de programas de MCC. Tal processo comprovou os benefícios e a acurácia da metodologia e das
ferramentas propostas.
Palavras Chave: Sistema Baseado em Conhecimento, Lógica
Fuzzy
, Manutenção Centrada na
Confiabilidade.
ABSTRACT
RIGONI, Emerson. METHODOLOGY FOR RELIABILITY CENTERED MAINTENANCE
IMPLEMENTATION: an approach grounded in Knowledge Based System and Fuzzy Logic.
Doctorate Thesis presented to the Graduate Program in Mechanical Engineering (POSMEC) of the
Federal University of Santa Catarina (UFSC), as a partial requisite for Doctorate in Mechanical
Engineering. Florianópolis, 2008
.
The Reliability Centered Maintenance (RCM) implementation does not always happen in
an appopriate, harmonious and consistent way, which results in low commitment from
maintainers and, in some critical cases, abandonment of the RCM program due to lack of sinergy
with the company´s goals. Along with technical aspects, some management ones also influence
the success of the RCM program.
This thesis proposes a methodology to assist RCM implementation, considering its pre-
requisites and auditing each implementation stage process in order to reduce critical factors to the
program´s success. These factors are, most of the time, related to the low adherence of the
company/system to the pre-requisites demanded by RCM, and/or bad executed steps, during its
implementation. It aims, therefore, to consider the company´s/system´s characteristics as well as
the RCM needs and, after the implementation of each step, audit them so that the inconsistencies
occured during its execution are not extended to further ones. In addition, some auxiliary tools
are also proposed for the implementation of specific steps to support decision making regarding
uncertantities that may be interposed to the decision-making process.
This methodology is based on a Knowledge Based System-Fuzzy (KBS-Fuzzy) which
incorporates criteria for diagnosis and decision-making, taking into account technical and
management aspects as well as the experience of RCM consolidated programs and institutional
knowledge. In this way, it is possible to minimize the unacomplished risks of traditional RCM
implementation methodologies, considering and treating inaccuracy (lexical) uncertanties of the
process within a holistic view of RCM interactions and needs.
The KBS-Fuzzy developed, as well as the suggested tools for critical steps
implementation, were field validated and tested by specialists in implementation and RCM
program management, verifying the benefits and accuracy of such methodology and tools.
Key-words: Knowledge Based System, Fuzzy Logic, Reliability Centrered Maintenance.
RESUMO
RIGONI, Emerson. METODOLOGIO POR EFEKTIVIGO DE VARTADO FOKUSIGITA
SUR FIDINDECO: aliro fundamentita sur Sciarbazitaj Sistemoj kaj Svaga Logiko. Doktora tezo
prezentita al la Postdiploma Programo pri Mekanika Inĝenierarto (POSMEC) de la Federacia
Universitato de Sankta Katarino (UFSC) kiel parta postulo por la havigo de la titolo de Doktoro pri
Mekanika Inĝenierarto, Florianopolo, 2008.
La efektivigo de la Vartado Fokusigita sur Fidindeco (VFF) ne ĉiam fariĝas en maniero
adekvata, harmonia kaj konsekvenca, el kio rezultas malalta devontiĝo de la prizorgistoj kaj, en
krizaj okazoj, forlaso de la VFF-programo pro manko de samcela kunagado rilate al la celoj de la
entrepreno. Krom teknikaj aspektoj, ankaŭ mastrumaj aspektoj influas la sukceson de
VFF-programo.
Tiu ĉi laboro proponas metodologion por helpi la efektivigon de VFF, konsiderante ties
antaŭpostulojn kaj postkontrolante ĉiun etapon de la efektivigproceso, tiel malpliigante la riskajn
faktorojn cele al la sukceso de la programo. Tiaj faktoroj koncernas, plejofte, la malaltan
alteniĝon de la entrepreno/sistemo al la antaŭpostuloj postulataj de VFF kaj/aŭ etapojn malbone
plenumitajn dum ties efektivigoj. La propono de tiu ĉi laboro estas konsideri la karakterizaĵojn de
la entrepreno/sistemo kaj la necesojn de VFF, kaj kontroli ĉiun etapon tuj post ties realigo, por ke
ties nekoheraĵoj ne sin propagu al la sekvontaj ŝtupoj. En specifaj etapoj oni proponas ankaŭ
efektivig-helpilojn, celante apogi la decid-ekprenon alfronte al necertaĵoj apereblaj dum la
decidproceso.
La proponita metodologio estas fundamentita sur Sciarbazita Sistemo kun Svaga Logiko
(SBS-Svaga), kiu enprenas kriteriojn por la diagnozo kaj decid-ekpreno, kunkalkulante aspektojn
teknikajn kaj mastrumajn, same kiel la spertojn el plensukcesaj VFF-programoj kaj la institucian
sciaron. Per ĉi tiu metodologio, eblas minimumigi la riskojn de malsukceso de la tradiciaj
VFF-efektivigaj metodologioj, konsiderante kaj pritraktante la necertaĵojn leksikonajn, aŭ tiujn
generatajn pro neprecizecoj en la proceso, per tuteca rigardo al la interagoj kaj necesoj de
Vartado Fokusigita sur Fidindeco.
La disvolvita SBS-Svaga, same kiel la sugestitaj iloj por efektivigo de la kritaj etapoj, estis
surterene elprovitaj kaj atestitaj fare de fakuloj pri efektivigo kaj mastrumado de VFF-programoj.
Tia proceso pruvis la avantaĝojn kaj la ekzaktecon de la proponitaj metodologio kaj iloj.
Ŝlosilvortoj: sciarbazita sistemo, svaga logiko, vartado fokusigita sur fidindeco.
LISTA DE FIGURAS
Figura 1.1 - Efetivo Próprio de Pessoal na Área de Manutenção........................................................ 20
Figura 1.2 - Qualificação do Pessoal da Manutenção. ........................................................................ 20
Figura 1.3 - Programação Anual de Treinamento para o Pessoal de Manutenção.............................. 21
Figura 1.4 - Indicadores de Disponibilidade ....................................................................................... 22
Figura 1.5 - Idade Média dos Equipamentos/Instalações em Operação..................................................... 22
Figura 1.6 - Monitoramento de Máquinas e Equipamentos Utilizados nas Empresas........................ 24
Figura 2.1 - Curva da Banheira ........................................................................................................... 35
Figura 2.2 - Padrões de Taxa Instantânea de Falhas ........................................................................... 36
Figura 2.3 - Estágios Evolutivos da Falha........................................................................................... 40
Figura 2.4 - Estrutura para Síntese das Metodologias Estudadas........................................................ 42
Figura 2.5 - Metodologia para Implantação da MCC proposta pela IEC 60300-3-11 ....................... 43
Figura 2.6 - Metodologia para Implantação da MCC proposta pela SAE JA1011/JA1012................ 45
Figura 2.7 - Metodologia para Implantação da MCC - ABS .............................................................. 46
Figura 2.8 - Metodologia para Implantação da MCC - NASA ........................................................... 47
Figura 2.9 - Metodologia para Implantação da MCC - NOWLAN E HEAP...................................... 48
Figura 2.10 - Metodologia para Implantação da MCC - MOUBRAY................................................ 49
Figura 2.11 - Metodologia para Implantação da MCC - SMITH........................................................ 50
Figura 2.12 - Metodologia para Implantação da MCC - SMITH E HINCHCLIFFE ........................ 51
Figura 3.1 - Hierarquia do Conhecimento........................................................................................... 54
Figura 3.2 - Espiral do Conhecimento ................................................................................................ 57
Figura 3.3 - Processo de Construção de um SBC................................................................................ 62
Figura 3.4 - Principais Atores do Processo de Construção de um SBC.............................................. 63
Figura 4.1 - Grau de Especialização do Pessoal da Manutenção ....................................................... 67
Figura 4.2 - Contextualização de SBC e SE dentro dos SI’s............................................................... 70
Figura 4.3 - Arquitetura de um Sistema Especialista (SE).................................................................. 70
Figura 4.4 - Etapas de Desenvolvimento de Software Utilizando o Modelo Incremental .................. 74
Figura 4.5 - Núcleo, Suporte e Limites de um Conjunto
Fuzzy
.......................................................... 88
Figura 4.6 - Operações: Complemento, Interseção e União de Conjuntos
Fuzzy
.............................. 90
Figura 4.7 - Partição de Conjuntos
Fuzzy
........................................................................................... 90
Figura 4.8 - Modificadores Lingüísticos do FuzzyCLIPS................................................................... 91
Figura 4.9 - Diagrama Típico de um Modelo de Inferência de Mandani............................................ 94
Figura 4.10 - Exemplo de um Processo de Inferência
Fuzzy
.............................................................. 97
Figura 5.1 - Procedimento de Referência para Implantação da MCC............................................... 100
Figura 5.2 - Aspectos do Procedimento de Referência para cada Etapa da MCC ........................... 101
Figura 5.3 - Planilha da FMECA adotada no Procedimento de Referência...................................... 105
Figura 5.4 - Seleção das Funções Significantes e Classificação dos seus Modos de Falha .............. 106
Figura 5.5 - Seleção das Tarefas de Manutenção.............................................................................. 107
Figura 5.6 - Avaliação dos Pré-requisitos e Auditoria
Fuzzy
das Etapas da MCC .......................... 111
Figura 5.7 - Processo de Avaliação dos Pré-Requisitos e Auditoria
Fuzzy
da MCC........................ 111
Figura 5.8 - Processo de Avaliação
Fuzzy
dos Pré-Requisitos das Etapas da MCC......................... 112
Figura 5.9 - Termos Primários para Avaliação de Pré-Requisitos e Auditoria................................. 112
Figura 5.10 - Processo de Auditoria
Fuzzy
das Etapas da Mcc ........................................................ 113
Figura 5.11 - Critérios para Julgamento do Êxito de um Programa de MCC ................................... 114
Figura 5.12 - Avaliação dos Pré-Requisitos da Etapa 0. ................................................................... 119
Figura 5.13 - Avaliação dos Pré-Requisitos da Etapa 1. ................................................................... 124
Figura 5.14 - Avaliação dos Pré-Requisitos da Etapa 2. ................................................................... 128
Figura 5.15 - Avaliação dos Pré-Requisitos da Etapa 3. ................................................................... 131
Figura 5.16 - Avaliação dos Pré-Requisitos da Etapa 4. ................................................................... 133
Figura 5.17 - Avaliação dos Pré-Requisitos da Etapa 5. ................................................................... 135
Figura 5.18 - Avaliação dos Pré-Requisitos da Etapa 6. ................................................................... 136
Figura 5.19 - Avaliação dos Pré-Requisitos da Etapa 7. ................................................................... 138
Figura 5.20 - Avaliação dos Pré-Requisitos da Etapa 8. ................................................................... 140
Figura 5.21 - Auditoria da Etapa 0.................................................................................................... 143
Figura 5.22 - Auditoria da Etapa 1.................................................................................................... 143
Figura 5.23 - Auditoria da Etapa 2.................................................................................................... 145
Figura 5.24 - Auditoria da Etapa 3.................................................................................................... 146
Figura 5.25 - Auditoria da Etapa 4.................................................................................................... 148
Figura 5.26 - Auditoria da Etapa 5.................................................................................................... 149
Figura 5.27 - Auditoria da Etapa 6.................................................................................................... 151
Figura 5.28 - Auditoria da Etapa 7.................................................................................................... 153
Figura 5.29 - Auditoria da Etapa 8.................................................................................................... 154
Figura 6.1 - Metodologia de Desenvolvimento do DALF-MCC ...................................................... 159
Figura 6.2 - Possíveis Configurações dos Termos Primários no DALF-MCC ................................ 160
Figura 6.3 - Tela de Ponderação dos Quesitos .................................................................................. 161
Figura 6.4 - Relatório de Avaliação da Etapa.................................................................................... 163
Figura 6.5 - Critério de Codificação da Base de Conhecimento do DALF-MCC............................. 163
Figura 6.6 - Processo de Inferência
Fuzzy
com Atribuição de Conceitos......................................... 165
Figura 6.7 - Processo de Inferência
Fuzzy
com Atribuição de Notas ............................................... 166
Figura 6.8 - Processo de Inferência
Fuzzy
com Atribuição de Nota e Conceito............................... 168
Figura 6.9 - Conjuntos
Fuzzy
Resultantes da Avaliação Simulada de C4 e C5 da Etapa 0.............. 169
Figura 6.10 - Processo de Inferência
Fuzzy
para Avaliação da Etapa 0. .......................................... 169
Figura 7.1 - Tela de Acesso aos Softwares de Apoio a Implementação da MCC............................. 171
Figura 7.2 - Matriz para Avaliação do Grau de Risco....................................................................... 182
Figura A.1 -Planilha FMECA adotada no Procedimento de Referência........................................... 215
Figura A.2 - Estágios Evolutivos da Falha........................................................................................ 216
Figura A.3 - Síntese: Causas, Modo de Falha e Efeitos.................................................................... 218
Figura A.4 - Identificação de Funções Significantes......................................................................... 219
Figura B.1 - Etapas de Desenvolvimento de Software Utilizando o Modelo Seqüencial................. 229
Figura B.2 - Etapas de Desenvolvimento de Software Utilizando o Modelo Espiral ....................... 230
Figura B.3 - Desenvolvimento de Software com Modelo Baseado em Componentes...................... 231
Figura B.4 - Processo de Desenvolvimento de um SBC................................................................... 232
Figura B.5 - Técnicas de Modelagem
Botton-up
e
Top-Down
......................................................... 236
Figura B.6 - AC no Paradigma Top Down........................................................................................ 237
Figura B.7 - O Processo KDD........................................................................................................... 243
Figura B.8 - Exemplos de Redes Semânticas: Tipo é um
e tem parte............................................... 245
Figura B.9 - Exemplo de Frames....................................................................................................... 246
Figura B.10 - Exemplos de Interfaces no wxCLIPS ......................................................................... 254
Figura C.1 - Procedimento de Referência para Implantação da MCC.............................................. 100
Figura G.1 - Possíveis Configurações dos Termos Primários no DALF-MCC ................................ 301
Figura G.2 - Exemplo de ponderação para Et_0_C_2_Q_1.............................................................. 301
Figura G.3 - Determinação da Área A
C1
da Equação G2 .................................................................. 303
Figura G.4 - Tela Inicial do DALF-MCC (Menu Início) .................................................................. 304
Figura G.5 - Tela de Identificação e Caracterização da Empresa (Menu Empresa).......................... 304
Figura G.6 - Tela de Parametrização (Menu Parametrização
Fuzzy
)................................................ 305
Figura G.7 - Tela de Ponderação dos Pré-Requisitos (Menu Pré-Requisitos) .................................. 306
Figura G.8 - Tela para Ponderação para Auditoria (Menu Auditoria) .............................................. 306
Figura G.9 - Relatório (Cabeçalho Pré-Requisitos e Auditoria) ....................................................... 307
Figura G.10 - Relatório (Avaliação da Etapa 0)................................................................................ 308
Figura G.11 - Relatório (Etapa 0 - Critério 3)................................................................................... 309
Figura G.12 - Tela de Apresentação do OpenFMECA ..................................................................... 310
Figura G.13 - Tela de Configurações do OpenFMECA .................................................................. 310
Figura G.14 - Tela de Inclusão de Participante na Base de Dados do OpenFMECA ....................... 311
Figura G.15 - Tela de Elaboração da FMECA (EXEMPLO DISJUNTOR).................................... 311
Figura G.16 - Tela de Avaliação de Índices ..................................................................................... 311
Figura G.17 - OpenFMECA: Gerenciamento de Ações e Controles Atuais..................................... 312
Figura G.18 - Tela de Reavaliação de Índice .................................................................................... 312
Figura G.19 - Relatórios OpenFMECA............................................................................................. 313
Figura G.20 - Tela de
Login
do FMECA-Delphi.............................................................................. 313
Figura G.21 - Tela do Formulário Sobre o Especialista.................................................................... 314
Figura G.22 - Tela da Primeira Iteração............................................................................................ 314
Figura G.23 - Tela do Relatório da Primeira Iteração....................................................................... 315
Figura G.24 - Tela de Coleta de Informações Adicionais................................................................. 315
Figura G.25 - Tela do Relatório das Informações Adicionais........................................................... 316
Figura G.26 - Tela da Segunda Iteração............................................................................................ 317
Figura G.27 - Tela do Relatório Individual do Especialista.............................................................. 317
Figura G.28 - Tela Inicial do NPR-Fuzzy ......................................................................................... 318
Figura G.29 - Tela de Parametrização e Ponderação do NPR-Fuzzy................................................ 319
Figura G.30 - Relatório de Avaliação do NPR-Fuzzy....................................................................... 320
Figura G.31 - Tela de Abertura do DALF-Diagramas ...................................................................... 321
Figura G.32 - Tela de Abertura do DALF-Diagramas - Etapa 4 - Parte 1 ........................................ 321
Figura G.33 - Tela de Identificação e Descrição da Função ............................................................. 322
Figura G.34 - Tela de Parametrização dos Termos Primários........................................................... 322
Figura G.35 - Tela de Ponderação dos Quesitos - Etapa 4 - Parte 1 ................................................. 324
Figura G.36 - Tela de Resultados do Processo de Inferência
Fuzzy
- Etapa 4.................................. 324
Figura G.37 - Tela de Ponderação dos Quesitos - Etapa 4 - Parte 2 ................................................. 236
Figura G.38 - Tela de Abertura do DALF-Diagramas - Etapa 5....................................................... 326
Figura G.39 - Tela de Ponderação dos Quesitos - Etapa 5................................................................ 329
Figura G.40 - Tela de Resultados do Processo de Inferência
Fuzzy
- Etapa 5.................................. 239
Figura G.41 - Cabeçalho e Parametrização
Fuzzy
. ............................................................................ 330
Figura G.42 - Diagramas da Decisão Resultantes. ............................................................................. 331
Figura G.43 - Ponderação dos Quesitos e Resultados do Processo de Inferência............................... 331
LISTA DE TABELAS
Tabela 1.1 - Principais Indicadores de Desempenho Utilizados ......................................................... 21
Tabela 4.1 - Diferenças entre os Sistemas Convencionais e os SBC’s .............................................. 72
Tabela 4.2 - Critérios para Seleção de SBC’s ..................................................................................... 75
Tabela 4.3 - Propriedades dos Conjuntos
Fuzzy
................................................................................. 89
Tabela 7.1 - Escala de Valores para Estimativa do Grau de Confiança ............................................ 177
Tabela 7.2 - Termos Lingüísticos (Primários) Utilizados no NPR-Fuzzy ........................................ 179
Tabela 7.3 - Graduação da Severidade das Conseqüências............................................................... 182
Tabela 7.4 - Freqüência de Ocorrência da Falha Funcional ou do Modo de Falha........................... 182
Tabela 7.5 - Categorias de Risco da Falha Funcional ou do Modo de Falha.................................... 183
Tabela 8.1 - Dados Estatísticos do DALF-MCC............................................................................... 186
Tabela 8.2 - Entradas Simuladas no DALF-MCC............................................................................. 187
Tabela 8.3 - Resultado do Questionário de Validação (Alunos - UTFPR) ....................................... 188
Tabela 8.4 - Resultado do Questionário de Validação (Especialistas - Congressos) ........................ 189
Tabela 8.5 - Resultado do Questionário de Validação (Aplicação em Campo)................................ 191
Tabela 8.6 - Resultado do Questionário de Validação (Especialistas em MCC) .............................. 193
Tabela A.1 - Sugestão de Critétrios para Avaliar a Severidade dos Modos de Falha....................... 220
Tabela A.2 - Sugestão de Critérios para Avaliar a Ocorrência da Causa da Falha ........................... 221
Tabela A.3 - Sugestão de Critérios para Avaliar a Ocorrência da Causa da Falha ........................... 222
Tabela A.4 - Sugestão de Critérios para Avaliar a Deteccção da Causa da Falha ............................ 223
Tabela A.5 - Ferramentas para Promoção da Qualidade................................................................... 224
Tabela B.1 - Vantagens e Desvantagens da AC Baseada em Análise de Protocolo ......................... 233
Tabela B.2 - Exemplo de Representação Objeto-Atributo-Valor (OAV) ......................................... 247
Tabela B.3 - Tipos de Regras no FuzzyCLIPS) ................................................................................ 252
LISTA DE SIGLAS E ACRÔNIMOS
ABNT → Associação Brasileira de Normas Técnicas
ABRAMAN → Associação Brasileira de Manutenção
ABS →
American Bureau of Shipping
Agência Americana Regulamentadora da Construção de Navios
AC → Aquisição do Conhecimento
AGR →
Análise de Grades de Repertório
Repertory Grid Analysis
ASME →
American Society of Mechanical Engineers
Sociedade Americana de Engenheiros Mecânicos
ATA MSG3 →
Air Transport Association of America
–
Maintenance Steering Group – Task Force
3
Associação do Transporte Aéreo Americano – Grupo Governamental “de Condução”
da Manutenção – Força Tarefa 3
C1, C2...C
n
→ Critérios Avaliados
CCQ → Círculos de Controle da Qualidade
CHESF → Companhia Hidrelétrica do São Francisco
COG → Centro de Gravidade
CNPq → Conselho Nacional de Desenvolvimento Científico e Tecnológico
CLIPS →
C Language Integrated Production System
Sistema de Produção Integrado de Linguagem C
CMMS →
Computer Maintenance Management Systems
Sistema Computadorizado de Gerenciamento da Manutenção
D → Detecção
DAELT → Departamento Acadêmico de Eletrotécnica
DALF-MCC → Diagnóstico Auxiliado por Lógica
Fuzzy
para a MCC
DIA → Detecção de Interação Automática
DOD →
Department of Defense
Departamento de Defesa
EC → Engenheiro de Conhecimento
ECM →
Experience Centered Maintenance
Manutenção Centrada na Experiência
ECOMP → Estação de Compressão de Gás Natural
EE → Estação de Entrega
EH → Especialista Humano
EMC → Sigla do Departamento de Engenharia Mecânica da UFSC
EEO → Evidente com efeito Econômico ou Operacional
EPRI →
Electric Power Research Institute
Instituto de Pesquisa em Energia Elétrica
ESA → ESA – Evidente com efeito na Segurança ou Ambiente
ETA →
Event Tree Analysis
Análise da Árvore de Eventos
FAA →
Federal Aviation Administration
Administração Federal da Aviação
FMEA →
Failure Modes and Effects Analysis
Análise dos Modos de Falha e seus Efeitos
FMECA →
Failure Modes, Effects and Criticality Analysis
Análise dos Modos de Falha seus Efeitos e sua Criticidade
FTA →
Fault Tree Analysis
Análise da Árvore de Falhas
GASBOL → Gasoduto Bolívia-Brasil
GC → Gestão de Conhecimento
IA → Inteligência Artificial
ICOM →
Input, Control, Output, Mechanism
Entrada, Controle, Saída e Mecanismo
IDEF →
Integration DEFinition
Definição Integrada
IEC →
International Electrotechnical Commission
Comissão Internacional de Eletrotécnica
ISO →
International Organization for Standardization
Organização Internacional para Padronização
JESS →
Java Expert System Shell
Shell
para desenvolvimento de Sistemas Especialistas em Java
KADS →
Knowledge Acquisition and Design Structure
Aquisição de Conhecimento e Projeto de Estrutura
KDD →
Knowledge Discovery in Data Base
Descoberta de Conhecimento em Banco de Dados
MCC → Manutenção Centrada na Confiabilidade
MF → Modos de Falha
MIT →
Massachusetts Institute of Technology
Instituto de Tecnologia de Massachusetts
MOM → Média dos Máximos
MSG-1 →
Maintenance Steering Group – Task Force
1
Grupo Governamental “de Condução” da Manutenção – Força Tarefa 1
MTBF →
Mean Time Between Failure
Tempo Médio Entre Falhas
MTTR →
Mean Time To Repair
Tempo Médio Para Reparo
NASA →
National Aeronautics and Space Administration
Agência Aero-Espacial Norte Americana
NBR → Norma Brasileira
NE → Número de Efeitos
NPR → Número de Prioridade de Risco
NeDIP → Núcleo de Desenvolvimento Integrado de Produtos
NIST →
National Institute of Standards and Technology
Instituto Nacional de Padronizações e Tecnologias
O → Ocorrência
OAV → Objeto - Atributo - Valor
OEO → Oculto com efeito Econômico ou Operacional
ONS → Operador Nacional do Sistema
OPAL →
Object, Process and Actor Modeling Language
Linguagem de Modelagem Agente, Objeto e Processo
OSA → Oculto com efeito na Segurança ou Ambiente
PF → Intervalo entre a Falha Potencial e a Falha Funcional
PMBOK →
Project Management Body of Knowledge
Conjunto de Conhecimentos em Gerenciamento de Projetos
PMI →
Project Management Institute
Instituto de Gerenciamento de Projetos
Q1, Q2...Q
n
→ Quesitos a serem Ponderados
QC → Quantidade de Causas
RC → Representação do Conhecimento
RCM →
Reliability Centered Maintenance
Manutenção Centrada na Confiabilidade
S → Severidade
SADT →
Structured Analysis and Design Technique
Técnica de Análise e Projetos Estruturados
SAE →
Society of Automotive Engineers
Sociedade de Engenheiros Automotivos
SBC → Sistema Baseado em Conhecimento
SCADA →
Supervisory Control And Data Acquisition
Supervisão Controle e Aquisição de Dados
SCGM → Sistema de Controle e Gestão da Manutenção
SE → Sistema Especialista
SI → Sistema Inteligente
SRCM →
Streamlined RCM
Processo Simplificado/Abreviado de Implantação da MCC
SSCM → Sistemática para Seleção da Concepção de Manutenção
TBG → Transportadora Brasileira Gasoduto Brasil Bolívia S.A.
TMDA →
Task / Method / Domain / Application
Tarefa / Método / Domínio / Aplicação
TPM →
Total Productive Maintenance
Manutenção Produtiva Total
UFSC → Universidade Federal de Santa Catarina
UML →
Unified Modeling Language
Linguagem de Modelagem Unificada
UTFPR → Universidade Tecnológica Federal do Paraná
SUMÁRIO
CAPÍTULO 1 - INTRODUÇÃO.............................................................................................................. 19
1.1 TEMA DE PESQUISA ......................................................................................................................... 19
1.1.1 Aspectos Gerais................................................................................................................................... 19
1.1.2 Aspectos Específicos .......................................................................................................................... 19
1.2 PREMISSAS E PROBLEMA DE PESQUISA.................................................................................... 23
1.3 TRABALHOS RELEVANTES ............................................................................................................ 25
1.4 OBJETIVOS .......................................................................................................................................... 28
1.4.1 Objetivo Geral..................................................................................................................................... 28
1.4.2 Objetivos Específicos ......................................................................................................................... 28
1.6 JUSTIFICATIVAS E CONTRIBUIÇÕES........................................................................................... 29
1.7 DELIMITAÇÃO DO TEMA................................................................................................................ 30
1.8 METODOLOGIA DA PESQUISA ...................................................................................................... 31
1.9 ESTRUTURA DO TRABALHO.......................................................................................................... 32
CAPÍTULO 2 - MANUTENÇÃO CENTRADA NA CONFIABILIDADE....................................... 33
2.1 INTRODUÇÃO..................................................................................................................................... 33
2.2 ASPECTOS GERAIS............................................................................................................................ 33
2.2.1 Evolução Histórica da MCC............................................................................................................... 35
2.2.2 Considerações sobre os Mecanismos de Falha .................................................................................. 35
2.2.3 Considerações Bibliográficas e Normativas ...................................................................................... 35
2.2.4 Atributos e Critérios de um Processo de MCC .................................................................................. 38
2.3 CONCEITOS INERENTES A IMPLANTAÇÃO DA MCC.............................................................. 39
2.4 METODOLOGIAS PARA IMPLANTAÇÃO DA MCC.................................................................... 42
2.4.1 Metodologia Proposta pela IEC 60300-3-11...................................................................................... 42
2.4.2 Metodologia Proposta pela SAE JA1011/JA1012............................................................................. 44
2.4.3 Metodologia Proposta pela ABS (American Bureau of Shipping) ................................................... 44
2.4.4 Metodologia Proposta pela NASA (National Aeronautics and Space Administration) ................... 44
2.4.5 Metodologia Proposta por Nowlan e Heap ........................................................................................ 46
2.4.6 Metodologia Proposta por Moubray................................................................................................... 47
2.4.7 Metodologia Proposta por Smith........................................................................................................ 48
2.4.8 Metodologia Proposta por Smith e Hinchcliffe ................................................................................. 50
2.5 CONSIDERAÇÕES E SÍNTESE DO CAPÍTULO ............................................................................. 52
CAPÍTULO 3 - GESTÃO DO CONHECIMENTO.............................................................................. 53
3.1 INTRODUÇÃO..................................................................................................................................... 53
3.2 DEFINIÇÕES E CONCEITOS............................................................................................................. 53
3.3 CRIAÇÃO DO CONHECIMENTO..................................................................................................... 56
3.4 A IMPORTÂNCIA DA GESTÃO DO CONHECIMENTO (GC) ..................................................... 59
3.5 A FUNÇÃO DA ENGENHARIA DO CONHECIMENTO NA GC.................................................. 61
3.6 A GESTÃO DO CONHECIMENTO E O PROCESSO DE MCC ..................................................... 63
3.7 CONSIDERAÇÕES E SÍNTESE DO CAPÍTULO ............................................................................. 66
CAPÍTULO 4 - SISTEMAS BASEADOS EM CONHECIMENTO .................................................. 67
4.1 INTRODUÇÃO..................................................................................................................................... 67
4.2 DEFINIÇÕES E CONCEITOS............................................................................................................. 68
4.3 DIFERENÇAS ENTRE A ABORDAGEM ALGORÍTMICA E A HEURÍSTICA........................... 71
4.4 PROCESSO DE DESENVOLVIMENTO DE UM SBC .................................................................... 73
4.5 AQUISIÇÃO E ELICITAÇÃO DO CONHECIMENTO.................................................................... 76
4.5.1 Técnicas Manuais para Elicitação do Conhecimento ........................................................................ 77
4.5.2 Técnicas Automatizadas para Elicitação de Conhecimento .............................................................. 79
4.5.3 Considerações sobre Aquisição de Conhecimento (AC)................................................................... 80
4.6 REPRESENTAÇÃO DO CONHECIMENTO (RC) ........................................................................... 80
4.6.1 Considerações sobre Representação de Conhecimento (RC)............................................................ 83
4.7 VERIFICAÇÃO E VALIDAÇÃO DE SBC ........................................................................................ 84
4.8 TRATAMENTO DE INCERTEZAS ................................................................................................... 85
4.8.1 Tratamento das Incertezas do Processo de Implantação da MCC..................................................... 86
4.9 LÓGICA FUZZY .................................................................................................................................. 87
4.9.1 Conjuntos Fuzzy – Definições............................................................................................................ 87
4.9.2 Propriedades dos Conjuntos Fuzzy .................................................................................................... 88
4.9.3 Operações Fuzzy................................................................................................................................. 89
4.9.4 Variáveis Lingüísticas......................................................................................................................... 90
4.9.5 Modificadores Lingüísticos Fuzzy ..................................................................................................... 91
4.9.6 Regras de Produção Fuzzy ................................................................................................................. 91
4.9.7 O Processo de Inferência Fuzzy ......................................................................................................... 93
4.10 A SHELL FUZZYCLIPS.................................................................................................................... 97
4.11 CONSIDERAÇÕES E SÍNTESE DO CAPÍTULO........................................................................... 97
CAPÍTULO 5 - METODOLOGIA DESENVOLVIDA PARA IMPLEMENTAÇÃO DA MCC .. 99
5.1 INTRODUÇÃO..................................................................................................................................... 99
5.2 PROCEDIMENTOS DE REFERÊNCIA PARA IMPLANTAÇÃO DA MCC................................. 99
5.3 ASPECTOS DE CADA ETAPA DO PROCEDIMENTO DE REFERÊNCIA ............................... 100
5.3.1 Etapa 0 – Adequação da MCC ......................................................................................................... 101
5.3.2 Etapa 1 – Preparação......................................................................................................................... 102
5.3.3 Etapa 2 – Seleção do Sistema e Coleta de Informações .................................................................. 103
5.3.4 Etapa 3 – Análise dos Modos de Falha, seus Efeitos e sua Criticidade (FMECA) ........................ 104
5.3.5 Etapa 4 – Seleção das Funções Significantes e Classificação de seus Modos de Falha................. 105
5.3.6 Etapa 5 – Seleção das Tarefas de Manutenção Aplicáveis e Efetivas............................................. 106
5.3.7 Etapa 6 – Definição dos Intervalos Iniciais e Agrupamento das Tarefas de Manutenção.............. 108
5.3.8 Etapa 7 – Redação do Manual e Implementação ............................................................................. 109
5.3.9 Etapa 8 – Acompanhamento e Realimentação................................................................................. 109
5.4 METODOLOGIA PARA DIAGNÓSTICO DA MCC...................................................................... 110
5.5 SUCESSOS E FRACASSOS NA CONDUÇÃO DE UM PROGRAMA DE MCC........................ 114
5.6 ESTRATÉGIA PARA AVALIAÇÃO DOS PRÉ-REQUISITOS DAS ETAPAS DA MCC.......... 117
5.6.1 Avaliação dos Pré-Requisitos da Etapa 0......................................................................................... 118
5.6.2 Avaliação dos Pré-Requisitos da Etapa 1......................................................................................... 123
5.6.3 Avaliação dos Pré-Requisitos da Etapa 2......................................................................................... 128
5.6.4 Avaliação dos Pré-Requisitos da Etapa 3......................................................................................... 130
5.6.5 Avaliação dos Pré-Requisitos da Etapa 4......................................................................................... 133
5.6.6 Avaliação dos Pré-Requisitos da Etapa 5......................................................................................... 134
5.6.7 Avaliação dos Pré-Requisitos da Etapa 6......................................................................................... 136
5.6.8 Avaliação dos Pré-Requisitos da Etapa 7......................................................................................... 137
5.6.9 Avaliação dos Pré-Requisitos da Etapa 8......................................................................................... 139
5.7 ESTRATÉGIA PARA AUDITORIA DAS ETAPAS DA MCC ...................................................... 141
5.7.1 Auditoria da Etapa 0 ......................................................................................................................... 142
5.7.2 Auditoria da Etapa 1 ......................................................................................................................... 143
5.7.3 Auditoria da Etapa 2 ......................................................................................................................... 144
5.7.4 Auditoria da Etapa 3 ......................................................................................................................... 145
5.7.5 Auditoria da Etapa 4 ......................................................................................................................... 147
5.7.6 Auditoria da Etapa 5 ......................................................................................................................... 148
5.7.7 Auditoria da Etapa 6 ......................................................................................................................... 151
5.7.8 Auditoria da Etapa 7 ......................................................................................................................... 152
5.7.9 Auditoria da Etapa 8 ......................................................................................................................... 153
5.8 AVALIAÇÃO DOS FATORES CRÍTICOS PARA A IMPLANTAÇÃO DA MCC...................... 155
5.9 CONSIDERAÇÕES E SÍNTESE DO CAPÍTULO........................................................................... 155
CAPÍTULO 6 - IMPLEMENTAÇÃO COMPUTACIONAL............................................................ 157
6.1 INTRODUÇÃO................................................................................................................................... 157
6.2 ASPECTOS GERAIS DA IMPLEMENTAÇÃO COMPUTACIONAL.......................................... 157
6.3 METODOLOGIA DE DESENVOLVIMENTO................................................................................ 158
6.4 ORGANIZAÇÃO DAS REGRAS NO DALF-MCC ........................................................................ 160
6.5 POSSÍVEIS CONFIGURAÇÕES DO PROCESSO DE INFERÊNCIA FUZZY............................ 163
6.6 CONSIDERAÇÕES E SÍNTESE DO CAPÍTULO........................................................................... 170
CAPÍTULO 7 - FERRAMENTAS COMPUTACIONAIS DE APOIO À MCC............................. 171
7.1 INTRODUÇÃO................................................................................................................................... 171
7.2 PROPOSTAS PARA IMPLEMENTAÇÃO DA ETAPA 3 .............................................................. 172
7.2.1 OpenFMECA – Suporte à Implementação da FMECA .................................................................. 173
7.2.2 FMECA-Delphi – Técnica Delphi para Elicitação do NPR............................................................ 174
7.2.3 NPR-Fuzzy – Lógica Fuzzy para Avaliação do NPR...................................................................... 177
7.3 PROPOSTAS PARA IMPLEMENTAÇÃO DA ETAPA 4 .............................................................. 180
7.3.1 Análise de Risco nos Diagramas de Decisão da Etapa 4 da MCC.................................................. 180
7.4 PROPOSTAS PARA IMPLEMENTAÇÃO DA ETAPA 5 .............................................................. 183
7.5 CONSIDERAÇÕES E SÍNTESE DO CAPÍTULO........................................................................... 184
CAPÍTULO 8 - VERIFICAÇÃO E VALIDAÇÃO DO PROTÓTIPO............................................ 185
8.1 INTRODUÇÃO................................................................................................................................... 185
8.2 VERIFICAÇÃO................................................................................................................................... 185
8.3 VALIDAÇÃO...................................................................................................................................... 187
8.4 CONSIDERAÇÕES E SÍNTESE DO CAPÍTULO........................................................................... 195
CAPÍTULO 9 - CONSIDERAÇÕES FINAIS ..................................................................................... 197
9.1 INTRODUÇÃO................................................................................................................................... 197
9.2 SOBRE OS OBJETIVOS E QUESTÕES DE PESQUISA PROPOSTOS....................................... 197
9.3 SOBRE AS CONTRIBUIÇÕES TÉCNICO-CIENTÍFICAS DA PESQUISA................................ 199
9.4 SUGESTÕES PARA TRABALHOS FUTUROS.............................................................................. 200
APÊNDICE A - MANUTENÇÃO CENTRADA NA CONFIABILIDADE .................................... 215
A.1 GUIA PARA PREENCHIMENTO DA PLANILHA DE FMECA ................................................. 215
A.1.1 Função .............................................................................................................................................. 215
A.1.2 Falha Funcional................................................................................................................................ 216
A.1.3 Modo de Falha ................................................................................................................................. 217
A.1.4 Efeitos do Modo de Falha................................................................................................................ 218
A.1.5 Severidade (S) .................................................................................................................................. 220
A.1.6 Causas............................................................................................................................................... 221
A.1.7 Ocorrência (O) ................................................................................................................................. 221
A.1.8 Controles Atuais............................................................................................................................... 222
A.1.9 Detecção (D) .................................................................................................................................... 222
A.1.10 NPR (S.D.O) .................................................................................................................................. 223
A.2 MCC APLICADA AO GASODUTO BOLÍVIA BRASIL (GASBOL) .......................................... 223
APÊNDICE B - SISTEMAS BASEADOS EM CONHECIMENTO................................................ 229
B.1 MODELOS PARA DESENVOLVIMENTO DE SOFTWARE ...................................................... 229
B.2 AQUISIÇÃO E ELICITAÇÃO DO CONHECIMENTO – TÉCNICAS MANUAIS..................... 232
B.3 AQUISIÇÃO E ELICITAÇÃO DO CONHECIMENTO – TÉCNICAS AUTOMATIZADAS .... 239
B.4 REPRESENTAÇÃO DO CONHECIMENTO (RC) – TÉCNICAS................................................. 244
B.5 VERIFICAÇÃO E VALIDAÇÃO DE SBC...................................................................................... 248
B.6 MODELAGEM DO CONHECIMENTO.......................................................................................... 249
B.7 CONFIABILIDADE DE SBC............................................................................................................ 250
B.8 FUZZYCLIPS COMO FERRAMENTA PARA DESENVOLVIMENTO DE SBC-FUZZY ....... 251
APÊNDICE C – QUESTIONÁRIOS DE AQUISIÇÃO E VALIDAÇÃO....................................... 255
APÊNDICE D – MANUAL DE INSTALAÇÃO E EXECUÇÃO DO DALF-MCC ...................... 265
APÊNDICE E – PUBLICAÇÕES ......................................................................................................... 273
E.1 CONGRESSOS E REVISTAS........................................................................................................... 275
E.2 ORIENTAÇÃO DE TRABALHO DE CONCLUSÃO DE CURSO ............................................... 275
APÊNDICE F - QUESITOS E CRITÉRIOS DO SBC-FUZZY DESENVOLVIDO ..................... 277
F.1 ANÁLISE DOS PRÉ-REQUISITOS DA MCC ................................................................................ 279
F1.1 Pré-Requisitos_Etapa 0...................................................................................................................... 279
F.1.2 Pré-Requisitos_Etapa 1..................................................................................................................... 280
F.1.3 Pré-Requisitos_Etapa 2..................................................................................................................... 281
F.1.4 Pré-Requisitos_Etapa 3..................................................................................................................... 282
F.1.5 Pré-Requisitos_Etapa 4..................................................................................................................... 283
F.1.6 Pré-Requisitos_Etapa 5..................................................................................................................... 284
F.1.7 Pré-Requisitos_Etapa 6..................................................................................................................... 284
F.1.8 Pré-Requisitos_Etapa 7..................................................................................................................... 285
F.1.9 Pré-Requisitos_Etapa 8..................................................................................................................... 286
F.2 AUDITORIA da MCC ........................................................................................................................ 286
F.2.1 Auditoria_Etapa 0............................................................................................................................. 286
F.2.2 Auditoria_Etapa 1............................................................................................................................. 287
F.2.3 Auditoria_Etapa 2............................................................................................................................. 288
F.2.4 Auditoria_Etapa 3............................................................................................................................. 289
F.2.5 Auditoria_Etapa 4............................................................................................................................. 291
F.2.6 Auditoria_Etapa 5............................................................................................................................. 291
F.2.7 Auditoria_Etapa 6............................................................................................................................. 294
F.2.8 Auditoria_Etapa 7............................................................................................................................. 295
F.2.9 Auditoria da Etapa 8 ......................................................................................................................... 296
APÊNDICE G - IMPLEMENTAÇÃO COMPUTACIONAL........................................................... 299
G.1 DALF-MCC........................................................................................................................................ 301
G.1.1 Processo de Fuzzyficação e Desfuzzyficação ................................................................................. 301
G.1.2 Interface com o Usuário................................................................................................................... 303
G.1.3 Resultados e Conclusões do Processo de Inferência....................................................................... 307
G.2 OPEN-FMECA................................................................................................................................... 309
G.2.1 Interface e Estrutura do OpenFMECA............................................................................................ 310
G.3 FMECA-Delphi................................................................................................................................... 313
G.3.1 Interface e Estrutura do FMECA-Delphi ........................................................................................ 313
G.4 NPR-FUZZY....................................................................................................................................... 318
G.4.1 Interface e Estrutura do NPR-Fuzzy................................................................................................ 318
G.5 DALF-DIAGRAMAS (ETAPA 4) .................................................................................................... 320
G.5.1 Interface e Estrutura do DALF-Diagramas para a Etapa 4............................................................. 321
G.6 DALF-DIAGRAMAS (ETAPA 5) .................................................................................................... 326
G.6.1 Interface e Estrutura do DALF-Diagramas para a Etapa 5............................................................. 326
G.7 RELATÓRIO DE RESULTADOS E CONCLUSÕES DO DALF-DIAGRAMAS ....................... 330
APÊNDICE H – ÍNDICES ..................................................................................................................... 333
ÍNDICE ONOMÁSTICO.......................................................................................................................... 335
ÍNDICE REMISSIVO ............................................................................................................................... 339
19
CAPÍTULO 1
INTRODUÇÃO
1.1 TEMA DE PESQUISA
1.1.1 Aspectos Gerais
A habilidade das empresas contemporâneas de gerir, com a necessária competência e
eficiência, seus ativos em busca de um diferencial competitivo está fortemente vinculada a sua
política de gestão da manutenção. Neste contexto a Manutenção Centrada na Confiabilidade (MCC)
apresenta-se como uma alternativa consolidada e que preserva, na sua metodologia, o capital
intelectual das empresas.
Vale ressaltar que independente da política de gestão da manutenção, não há diferencial
competitivo sustentável, senão através do que a empresa sabe, como utiliza o que sabe e a
velocidade com que aprende. Por esta razão, a Gestão do Conhecimento (GC), associada à
Inteligência Artificial (IA), em especial os Sistemas Baseados em Conhecimento (SBC’s), estão se
consolidando como ferramentas fundamentais de auxílio às políticas de gestão da manutenção.
1.1.2 Aspectos Específicos
A implantação e a gestão da MCC nem sempre acontecem de maneira adequada, harmoniosa
e consistente, resultando em falta de comprometimento e, em casos críticos, em abandono do
programa de MCC pela falta de sinergia com os objetivos da empresa. Além dos aspectos técnicos, os
aspectos gerenciais e organizacionais também influenciam o sucesso de um programa de MCC
(MOUBRAY, 2001). Alguns dos principais problemas relacionados ao insucesso da MCC são
(SIQUEIRA, 2005): equívocos na previsão e gerenciamento de custos tanto de horas/homem como de
equipamentos, resultando em aumento do tempo de retorno dos investimentos; falta de apoio da alta
gerência, o que pode ter como conseqüência baixo comprometimento, limitações ou abandono do
programa de MCC; e falta das condições prévias necessárias para cumprimento do programa de MCC
(históricos de falha, conhecimento profundo da planta ou equipamento e cultura da equipe de
manutenção e operação). Outro aspecto a ser analisado é a diferença de abordagem dos processos
tradicionais de implantação e gestão da MCC, originalmente concebidos para a indústria de aviação, e
os aspectos peculiares de outros ramos industriais, como por exemplo: o petroquímico e o de energia
elétrica. Um dos exemplos desta diferença é o conhecimento sobre o histórico de falhas dos ativos. Na
indústria de aviação este conhecimento, por força de regulamentações, é minuciosamente explicitado,
porém, em outros ramos industriais, grande parte deste conhecimento é de natureza tácita, o que
ratifica a necessidade da GC.
A política de gestão da manutenção, no contexto deste trabalho a MCC, desempenha, segundo
Teixeira (2001) e Kardec e Xavier (2003), um papel importante para manter a logística da empresa
20
afetando diretamente sua competitividade. Assim, a metodologia de gestão da manutenção deve ser
parte de uma estratégia para a efetividade da excelência empresarial o que, segundo Tsang (1998),
extrapola a visão de um setor de manutenção exclusivamente com função tática e operacional. Para
ratificar a importância crescente e a função estratégica da manutenção nas empresas brasileiras é
relevante uma consulta ao Documento Nacional de 2007, uma pesquisa elaborada e conduzida pela
Associação Brasileira de Manutenção (ABRAMAN) publicada no 22° Congresso Brasileiro de
Manutenção realizado em Florianópolis – SC em Setembro de 2007. Os próximos parágrafos
apresentam alguns dados constantes deste documento e as respectivas conclusões inerentes.
No ano de 2007 a atividade de manutenção demandou das empresas pesquisadas 37.921
empregados próprios, o que corresponde a 23,24% (valor médio) do total de empregados de cada
empresa (Figura 1.1). Ao longo dos últimos anos se observa uma tendência de crescimento do pessoal
próprio, o que em tese fortalece o comprometimento das equipes de manutenção.
Figura 1.1 – Efetivo Próprio de Pessoal na Área de Manutenção.
Fonte: ada
p
tado de ABRAMAN, 2007.
18
20
22
24
26
28
30
1995 1997 1999 2001 2003 2005 2007
Ano
TM / TE (%)
Empregados Próprios na Manutenção
Ano
Total de
Funcionários das
Empresas (TE)
Total de
Funcionários na
Manutenção (TM)
TM / TE
(%)
2007 163.146 37.921 23
,
24
2005 108.784 23.651 21
,
74
2003 109.794 31.504 28
,
69
2001 159.454 33.015 20
,
71
1999 133.650 26.257 19
,
65
1997 154.250 30.750 19
,
94
1995 320.650 67.375 21
,
01
Tendência
Quanto ao perfil do pessoal próprio de manutenção, observa-se de acordo com a Figura 1.2,
que: de 2003 para 2005 houve um leve decréscimo da presença de pessoal de nível superior e da
mão-de-obra qualificada nas atividades de manutenção, indicadores estes que obtiveram um
acréscimo de 2005 para 2007 impulsionados, em parte, pelo vigor experimentado pela economia do
país, no mesmo período; é crescente a presença de pessoal técnico de nível médio nas atividades de
manutenção durante os últimos anos; e a mão de obra não qualificada vêm se mantendo abaixo dos
8% desde 1999. Isso ratifica a constatação de que, de um modo geral, as empresas estão mantendo
ou melhorando o nível de qualificação do pessoal da área de manutenção.
Figura 1.2 – Qualificação do Pessoal da Manutenção.
Fonte: adaptado de ABRAMAN, 2007.
4,5
5
5,5
6
6,5
7
7,5
8
8,5
9
9,5
1995 1997 1999 2001 2003 2005 2007
Ano
Mão de Obra Não Qualificada (%)
Qualificação do Pessoal da Manutenção (%)
Nível
Superior
Técnico de
Nível
Médio
Mão de
Obra
Qualificada
Mão de
Obra Não
Qualificada
Não
Classificada
Ano
2007 8
,
70 18
,
25 40
,
46 6
,
72 25
,
87
2005 7
,
06 16
,
07 36
,
05 7
,
91 32
,
91
2003 7
,
20 14
,
85 40
,
62 4
,
94 32
,
39
2001 7
,
64 14
,
81 38
,
72 7
,
63 31
,
20
1999 7
,
08 13
,
35 38
,
06 6
,
77 34
,
74
1997 6
,
18 14
,
78 40
,
63 8
,
07 30
,
34
1995 6
,
65 13
,
52 17
,
15 8
,
81 53
,
87
Tendência
21
A Tabela 1.1 mostra que nos últimos anos houve uma utilização crescente de indicadores de
desempenho da manutenção. Isto demonstra a preocupação das empresas em criar subsídios para a
tomada de decisão, almejando uma gestão eficaz da manutenção, o que enfatiza a necessidade de
ferramentas para auxílio à tomada de decisão e tratamento das incertezas do processo decisório.
Tabela 1.1 – Principais Indicadores de Desempenho Utilizados.
Fonte: adaptado de ABRAMAN, 2007.
Principais Indicadores de Desempenho Utilizados (%)
Tipos 1995 1997 1999 2001 2003 2005 2007
Grau de
Importância
em 2007
Custos 26,21 26,49 26,32 25,91 21,45 21,96 20,33 1
Disponibilidade Operacional 25,20 24,70 22,60 23,24 19,58 19,81 18,51 2
TMEF (Tempo Médio Entre Falhas) - - - - 11,89 11,69 14,21 3
TMPR (Tempo Médio Para Reparo) - - - - 9,56 11,46 11,74 4
Backlog
(Trabalho Acumulado) 8,07 6,55 8,98 10,41 9,32 6,92 11,57 5
Freqüência de Falhas 17,54 12,20 14,24 16,22 11,66 12,17 9,75 6
Satisfação do Cliente 13,91 11,01 11,76 11,86 8,62 8,11 8,93 7
Retrabalho 9,07 5,65 8,36 8,96 6,06 6,68 3,97 8
Utiliza Outros Indicadores - 11,31 4,95 2,18 0,23 0,48 0,66 9
Não Utiliza Indicadores - 2,09 2,79 1,22 1,63 0,72 0,33 10
Outra evidência do empenho das empresas na busca pela excelência na manutenção é o
aumento dos programas de treinamento para os mantenedores, visando equipes mais preparadas e
ações de manutenção mais efetivas (Figura 1.3). Este aumento do conhecimento institucional torna
imperativo o uso de técnicas computacionais para seu tratamento e explicitação, objetivando
facilitar sua apropriação por toda a empresa.
Figura 1.3 – Programação Anual de Treinamento para o Pessoal de Manutenção.
Fonte: adaptado de ABRAMAN, 2007.
70
75
80
85
90
95
100
1995 1997 1999 2001 2003 2005 2007
Ano
Programação Anual de Treinamento para o Pessoal de Manutenção (%)
Programação Anual de Treinamento para o
Pessoal de Manutenção (% de Empresas)
Ano 1995 1997 1999 2001 2003 2005 2007
Sim 74,11 81,51 73,04 85,92 76,19 96,77 87,97
Não 25,89 18,49 26,96 14,18 23,81 3,23 12,03
Tendência
Respeitando a diversidade das fontes de dados do relatório apresentado pelo Documento
Nacional de 2007 (ABRAMAN, 2007), os aspectos positivos relacionados até aqui, com base
culminaram com uma inversão na curva da Disponibilidade Operacional que vinha decrescendo
entre 2001 e 2005 e voltou a crescer em 2007. Por outro lado a Indisponibilidade Devido a
Manutenção foi a mais baixa desde 2003 (Figura 1.4). Segundo o Documento Nacional, em 2007
os 8 (oito) melhores indicadores (acima de 90%) apresentaram uma média de 94,37% para a
Disponibilidade Operacional. Estes aspectos estão relacionados com políticas inovadoras de
gestão da manutenção aliadas a aspectos macro econômicos do país, os quais contribuíram para o
crescimento das empresas/indústrias e com a necessidade de investimento em máquinas e
equipamentos e conseqüentemente no suporte a sua manutenção.
22
Indicadores de Disponibilidade (%)
Tipos 1997 1999 2001 2003 2005 2007
Disponibilidade Operacional 85,82 89,30 91,36 89,48 87,90 90,82
Indisponibilidade Devido à Manutenção 4,74 5,63 5,15 5,82 5,80 5,30
Figura 1.4 – Indicadores de Disponibilidade.
Fonte: adaptado de ABRAMAN, 2007.
85
86
87
88
89
90
91
92
1997 1999 2001 2003 2005 2007
a) Disponibilidade Operacional (%)
Ano
4,6
4,8
5
5,2
5,4
5,6
5,8
6
1997 1999 2001 2003 2005 2007
b) Indisponibilidade Devido à Manutenção (%)
Ano
Tendência
Tendência
A preocupação com a gestão da manutenção é crescente, uma vez que a idade média dos
equipamentos e/ou instalações é alta (65,81 % acima de 11 anos – Figura 1.5) e as demandas estão
aumentando, o que exige aumento equivalente da disponibilidade operacional.
Idade Média dos Equipamentos e/ou
Instalações em Operação (%)
Ano
0 a 5
anos
6 a 10
anos
11 a 20
anos
21 a 40
anos
Acima
de 40
anos
Idade
Média
(Anos)
2007 10,32 23,87 33,55 31,61 0,65 17,27
2005 4,50 26,13 45,05 20,72 3,60 16,95
2003 13,49 21,43 37,30 26,98 0,79 16,38
2001 7,75 16,90 45,07 28,17 2,11 17,97
1999 6,90 21,55 50,86 20,69 0,00 15,96
1997 6,96 22,61 53,04 17,39 0,00 15,51
1995 6,77 21,88 50,52 19,79 1,04 16,20
Média (%) 8,10 22,05 45,06 23,62 1,17 -
Desvio Padrão 2,93 2,81 7,30 5,26 1,29 -
0
5
10
15
20
25
30
35
40
45
50
0 a 5 anos 6 a 10 anos 11 a 20 anos 21 a 40 anos Acima de 40
anos
Média 1995 a 2007 Ano de 2007
Idade Média dos Equipamentos/Instalações em Operação (%)
Figura 1.5 – Idade Média dos Equipamentos/Instalações em Operação
Fonte: adaptado de ABRAMAN, 2007.
A conjuntura revelada pelo Documento Nacional em 2007 (ABRAMAN, 2007), ressalta a
importância da GC atrelada a metodologias consistentes de gestão da manutenção, a qual, não
pode ser definida apenas com base em questões mercadológicas ou decisões intuitivas dos
tomadores de decisão.
As questões mercadológicas estão relacionadas, principalmente, com a aquisição de
softwares proprietários de gestão da manutenção (CMMS –
Computer Maintenance Management
Systems
) os quais nem sempre atendem às necessidades específicas de uma determinada empresa
ou sistema. Já as decisões intuitivas são, invariavelmente, parciais e não avaliam todo o contexto
da aplicação e/ou empresa, resultando em falta de comprometimento e descrédito do programa de
gestão da manutenção (FUENTES, 2006).
23
1.2 PREMISSAS E PROBLEMA DE PESQUISA
Cada metodologia de gestão da manutenção possui requisitos e necessidades cuja adequação
da empresa/sistema deve ser previamente avaliada para que a sua aplicação resulte nos efeitos
desejados. Além disto, ao se adotar uma metodologia de gestão da manutenção, seu ciclo de vida
deve ser acompanhado a fim de que os desvios de conduta sejam rapidamente corrigidos,
maximizando seus benefícios.
A MCC possui atributos de uma das melhores práticas de GC, somada à finalidade original
de se promover a confiabilidade dos ativos pela manutenção. A prática de MCC constitui uma forma
potencial de GC, embora os seus praticantes não percebam esta associação. Na MCC as pessoas são
produtoras de conhecimento e ao mesmo tempo consumidoras pela troca de informações entre
equipes multidisciplinares. O processo de MCC, desde a aquisição de informações até o
estabelecimento das tarefas adequadas de manutenção, está inteiramente centrado no ser humano
assim como a GC (ALKAIM, 2003).
Além dos aspectos gerais relacionados até aqui, há outros inerentes ao contexto atual de
gestão dos ativos que, presume-se, corroboram para a utilização da MCC como metodologia de
gestão da manutenção, dentre os quais citam-se:
• Os equipamentos e sistemas estão cada vez mais complexos e com modos de falha ocultos
ao operador e/ou mantenedor, o que sugere atividades de manutenção preditivas ou de
inspeção funcional. Moubray (2001) afirma que 40% dos modos de falha dos ativos são
ocultos e destes 80% requerem inspeção funcional. Blanco (2007), após comparar diversos
programas de MCC, concluiu que ao final da sua implementação 60% das atividades de
manutenção, sugeridas pelos Diagramas de Decisão da MCC, são preditivas ou de
inspeção funcional. Isto ratifica a MCC como apta a tratar os modos de falha inerentes aos
ativos em seu contexto operacional atual;
• Por conscientização ou por imposição legal, além das questões econômicas, os gestores dos
ativos estão, cada vez mais, sensibilizados com as questões ambientais e de segurança que
permeiam a gestão da manutenção. Moubray (2001), Siqueira (2005), Smith e Hinchcliffe
(2004) além de outros autores e normas pesquisadas demonstram que o tratamento das
questões ambientais e de segurança é um dos atributos dos Diagramas de Decisão da MCC;
• A automatização dos sistemas, aliada ao aumento do monitoramento automático das
máquinas/equipamentos, conforme apontado pelo Documento Nacional de 2007
(ABRAMAN, 2007) mostrado na Figura 1.6, corrobora a utilização de dados/conceitos
relacionados à confiabilidade. Tais sistemas, cada vez mais desassistidos pelo operador,
privilegiam a MCC frente a outras metodologias de gestão da manutenção, por exemplo, a
Manutenção Produtiva Total (TPM –
Total Productive Maintenance
), a qual é por princípio
dependente das decisões dos operadores e mantenedores.
24
Principais Tipos de Monitoramento de Máquinas e
Equipamentos Utilizados nas Empresas (%)
Não Utiliza
Monitoramento
Manual
Coletores de
Dados e
Programas
Específicos
Automático
Os fatores supracitados somados ao contexto atual da manutenção evidenciam, por sua vez, os
seguintes aspectos: a manutenção assumiu importância estratégica para a gestão dos ativos nas
empresas contemporâneas; a política de gestão da manutenção deve ser condizente com o contexto
operacional da empresa/sistema; a necessidade de técnicas de GC é premente, principalmente como
aliadas da política de gestão da manutenção, para explicitação do conhecimento tácito dos operadores
e mantenedores; ferramentas para tratamento das incertezas do processo decisório, frente a dados
qualitativos, podem auxiliar a condução do processo de implantação das políticas de gestão da
manutenção; a MCC possui requisitos desejáveis à gestão de ativos cuja aderência da empresa/sistema
deve ser ratificada para maximizar seus resultados. Tais aspectos ensejam as seguintes premissas:
• A implantação da MCC como metodologia de gestão da manutenção depende da sua
aderência ao contexto da empresa/sistema;
• Os benefícios de um programa de MCC são maximizados a partir de sua correta implantação e
condução, o que pressupõe ações de auditoria ao longo de todo o seu ciclo de vida;
• Para consolidação dos pré-requisitos anteriores, entende-se ser importante a utilização de
técnicas de GC vinculadas a ferramentas para tratamento das incertezas do processo decisório;
• O sucesso da implantação da MCC é dependente da correta tomada de decisão frente a
dados invariavelmente qualitativos (ALKAIN, 2003). Portanto, o tratamento das incertezas
inerentes a este processo decisório pode ser facilitado com o uso de técnicas de IA, mais
precisamente a lógica
Fuzzy
(CAMPOS, 2004 e GARCIA, 2006).
As dificuldades e, por vezes, insucessos na implantação de MCC, e/ou na sua gestão,
ocorrem por não se dispor de ferramentas de diagnóstico e de decisão que facilitem avaliar o
conjunto de incertezas no ambiente corporativo, no campo técnico, na formação de recursos
humanos, na gestão e na identificação do nível de maturidade da corporação. Neste contexto,
acredita-se que a condução do processo de implantação e auditoria, utilizando um SBC-
Fuzzy
que
trate as incertezas inerentes ao processo decisório, pode trazer benefícios e aumentar a aderência da
empresa/sistema ao programa de MCC. Dessa hipótese emerge a questão principal, norteadora deste
trabalho: Como conduzir e orientar a implantação e a auditoria de um programa de MCC
tratando as incertezas por imprecisão ou de natureza léxica do processo decisório?
Ano
2007 2,23 36,16 41,97 19,64
2005 6,99 35,66 38,46 18,89
2003 11,45 33,13 36,75 18,67
2001 8,15 29,89 45,65 16,31
1999 6,08 37,17 44,59 12,16
1997 8,47 30,51 50,85 10,17
1995 12,70 47,62 29,10 10,58
8
10
12
14
16
18
20
22
1995 1997 1999 2001 2003 2005 2007
Monitoramento Automático (%)
Ano
Figura 1.6 – Monitoramento de Máquinas e Equipamentos Utilizados nas Empresas.
Fonte: adaptado de ABRAMAN, 2007.
Tendência
25
Decorrentes desta questão norteadora para guiar o processo de desenvolvimento deste
trabalho, fundamentar seus diagnósticos e orientar a coleta de informação, surgem alguns
questionamentos subjacentes, a saber:
• O que caracteriza um bom programa de MCC ao longo de todo o seu ciclo de vida?
• Para que tipo de empresa/sistema a MCC é mais aderente? Quais os pré-requisitos e
necessidades de um programa de MCC que corroboram com tal aderência?
• Quais são e de que maneira os fatores gerenciais e técnicos afetam positiva ou negativamente
a implantação e a gestão de um programa de MCC? Como tratar e incluir tais fatores no
processo decisório de implantação e auditoria da MCC?
• Como as metodologias tradicionais de implantação e gestão da MCC podem ser conduzidas
para reforçar os fatores de sucesso e minimizar o impacto dos fatores de insucesso?
• Quais os indicadores institucionais e técnicos que aferem a performance de um programa de
MCC? Como estes indicadores podem realimentar o processo de implantação da MCC?
Ao responder e confrontar as respostas destas questões com as metodologias tradicionais
de implantação e gestão da MCC (NOWLAN e HEAP, 1978; SMITH, 1993; SMITH e
HINCHCLIFFE, 2004; MOUBRAY, 2001; NASA, 2000; IEC 60300-3-11, 1999; SAE JA 1011,
1999; SAE JA 1012, 2002; ABS, 2004) formula-se a tese de que é possível conceber uma
metodologia operacionalizada por um SBC-
Fuzzy
para, em conjuntos com tais metodologias e
softwares comerciais, orientar o processo de implantação e auditoria da MCC, a fim de
maximizar seus fatores de sucesso.
1.3 TRABALHOS RELEVANTES
A partir da pesquisa bibliográfica e com a intenção de fundamentar o presente trabalho e
vislumbrar as possíveis contribuições para o domínio do conhecimento proposto, foram selecionados
alguns artigos, resumidos nos próximos parágrafos. Os autores destes artigos trazem exemplos de
aplicações que fundamentam esta proposta de tese e foram motivadoras para o foco deste trabalho.
Rajotte e Jolicoeur (2000) propuseram mudanças na metodologia da MCC para adequá-la às
necessidades da concessionária de Energia Elétrica de Quebec. As principais mudanças foram:
• Aplicação da MCC abordando/tratando o equipamento (Disjuntor, Seccionadoras,
Transformadores, etc...) ao invés do sistema (Linhas de Transmissão, Subestações, etc...). Isto
permitiu a concepção de padrões para outros equipamentos similares (
templates
), o que seria
mais difícil na abordagem sistêmica;
• Mudança da noção de criticidade, a qual normalmente envolve a probabilidade de falha e as
conseqüências para o sistema, passou a ser entendida, por limitação dos dados disponíveis,
como sendo resultado do custo de reparo do equipamento, da probabilidade de falha e das
26
conseqüências para a segurança e o meio ambiente. Esta mudança foi devida a presença de
equipamentos similares, porém em posição estratégica diferenciada com custos de
manutenção e conseqüências distintas para o sistema/empresa e de difícil ponderação devido à
configuração do sistema.
Além das adaptações sugeridas os autores ressaltam a importância do envolvimento de todo o
pessoal da manutenção e o fato de o programa de MCC ser um processo contínuo dependente das
demandas do sistema e dos avanços tecnológicos.
Johnston (2002) propõe uma metodologia para medir os benefícios de um programa de MCC,
para a empresa. O autor argumenta que além das pessoas normalmente resistirem às mudanças, o
período de tempo entre a análise da MCC e a obtenção de benefícios mensuráveis é longo, o que pode
suscitar dúvidas quanto à eficiência da MCC, principalmente em programas consolidados de
manutenção. Sendo assim, o autor propõe métricas em função do progresso da MCC, qualidade e
benefícios para a empresa.
Backlund (2003) defende em seu trabalho de doutorado, junto a empresas de geração de
energia elétrica, algumas pré-condições para implantação da MCC. O autor enfatiza a necessidade de
uma visão holística para implantação da MCC e demonstra, com estudos de caso, que as falhas dos
programas de MCC não são somente de natureza técnica, mas também gerenciais e organizacionais.
Raposo (2004), por sua vez, propõe uma metodologia para incorporar a análise de risco nos
diagramas de decisão da MCC. A análise proposta pelo autor se aplica na definição das funções
significantes e a classificação de seus modos de falha. Este mesmo tema foi objeto de estudo
apresentado por Hauge e Johnston (2001).
Siqueira (2005a), por outro lado, sugere uma metodologia para avaliar o impacto de um
programa de MCC no desempenho do sistema elétrico. O autor relata sua experiência na implantação
da MCC na Companhia Hidrelétrica do São Francisco (CHESF) e propõe diversos índices para avaliar
o desempenho do sistema elétrico após a implantação da MCC. Estudo semelhante foi apresentado
por Bertling
et al
(2003).
Waltrich e Tondello (2007) estabelecem uma relação entre a MCC e a GC. Os autores
apresentam a experiência da Eletrosul em MCC, e enfatizam o fato da mesma ser uma prática potencial
de GC. Aspectos semelhantes da relação entre a MCC e a GC são discutidos por Alkaim (2003).
Além das questões metodológicas, as ferramentas utilizadas na implantação também têm uma
influência direta na eficácia dos programas de MCC. É o caso da Análise dos Modos de Falha e seus
Efeitos (FMEA), principal ferramenta da MCC, abordada em Antonietti (2002) e Garcia (2006).
Antonietti (2002) relata as dificuldades encontradas durante a aplicação da FMEA em uma indústria
automobilística e aponta algumas pré-condições para sua aplicação. Garcia (2006) apresenta uma
abordagem
Fuzzy
para classificação dos Modos de Falha no FMEA para assim priorizar as ações de
melhoria/manutenção.
27
A partir da pesquisa bibliográfica sintetizada nos parágrafos anteriores, pode-se inferir que:
• Nem sempre as metodologias existentes para implantação e gestão da MCC, concebidas
para a indústria de aviação, atendem às necessidades específicas de uma determinada
empresa e/ou sistema;
• Os benefícios de um programa de MCC para a empresa são de longo prazo e, portanto podem
causar desmotivação, culminando em abandono do programa ou falta de comprometimento
dos envolvidos;
• Muitas empresas não estão aptas a adotar a MCC como política de gestão da manutenção,
dado que, a MCC pressupõe a existência de pré-requisitos que não são comuns a todas as
empresas, estando, em geral, restritos a grupos de empresas em setores específicos;
• Os procedimentos para implantação da MCC necessitam de uma metodologia para verificação
de pré-requisitos e auditoria das etapas implementadas do programa de MCC. Esta metodologia
deve incorporar mecanismos para tratamento das incertezas do processo decisório;
• Falta uma metodologia clara para mensurar a relação entre o desempenho do programa de
MCC e o desempenho do sistema. A falta de um procedimento atrelado a dados concretos,
para avaliar o programa de MCC, pode esconder desvios de conduta que podem inviabilizar a
implementação do programa;
• As ferramentas utilizadas pela MCC nem sempre apresentam resultados satisfatórios para
aplicações específicas. Ferramentas que dificultam a organização da informação e das ações
de manutenção, associadas a reuniões tediosas, podem desmotivar a equipe ou produzir
resultados duvidosos;
• Faltam ferramentas para implementação das etapas da MCC que tratem as incertezas inerentes
aos dados qualitativos que influenciam o processo decisório.
Os aspectos motivadores dos trabalhos precedentes, bem como suas relativas conclusões
sugerem a necessidade de melhorias nos procedimentos de implantação da MCC como metodologia
de gestão da manutenção. Sendo assim, nos próximos itens, serão apresentados os objetivos deste
trabalho, buscando uma contribuição científica original que fundamente a tese proposta e ajude a
consolidar os procedimentos para implantação da MCC e tratar as incertezas do processo decisório.
1.4 OBJETIVOS
1.4.1 Objetivo Geral
O objetivo geral deste trabalho é propor e desenvolver um SBC-
Fuzzy
que incorpore uma
metodologia para auxiliar a implantação da MCC que pondere seus pré-requisitos e audite, após
implementação, cada uma de suas etapas para aumentar a probabilidade de sucesso dos programas
de MCC.
28
Assim sendo, propõe-se ponderar as características da empresa/sistema e as necessidades da
MCC e, após a implementação de cada etapa, auditá-la para que as inconsistências ocorridas durante
sua execução não se propagem para as demais etapas.
Para concretizar a proposição desenvolve-se uma metodologia, a qual está inserida e é
operacionalizada por um SBC-
Fuzzy
, o qual incorpora critérios para diagnóstico e tomada de decisão,
ponderando os aspectos técnicos, os aspectos gerenciais, a experiência de programas consolidados de
MCC e o conhecimento institucional. Assim, entende-se ser possível tratar as incertezas por
imprecisão, decorrentes de variáveis qualitativas do processo decisório, e aumentar a chance de
sucesso dos programas de MCC com uma visão holística de suas interações e necessidades. Desta
forma a equipe de implantação poderá antever suas necessidades e interpor adequações e regras de
conduta que aumentem as chances de sucesso do programa de MCC.
1.4.2 Objetivos Específicos
Este trabalho deverá também atender aos seguintes objetivos específicos, para cumprimento
de seu objetivo geral:
• Investigar as metodologias existentes para implantação da MCC, resgatando seus conceitos,
estratégias, ferramentas e necessidades. De forma concomitante identificar os fatores críticos
de sucesso de um programa de MCC (planejamento, implantação e gestão) almejando
possíveis contribuições;
• Desenvolver uma estratégia para identificar os atributos da empresa relacionados com as
necessidades e pré-requisitos da MCC;
• Propor uma metodologia de análise qualitativa que confronte os atributos da empresa com as
necessidades e fatores críticos de sucesso da MCC. Assim será possível verificar se a empresa
possui os atributos necessários para aderir a um programa de MCC com riscos de insucesso
minimizados. As incertezas por imprecisão inerentes deverão ser equacionadas;
• Desenvolver mecanismos de explicitação do conhecimento tácito, o qual deve compor o
processo de inferência que irá avaliar a consistência dos pré-requisitos e a consolidação das
etapas na auditoria do programa de MCC;
• Definir as variáveis de análise que irão compor a metodologia, a partir das quais serão
prescritos os diagnósticos e conclusões que, por sua vez, irão apoiar a tomada de decisão. Com
estas definições será possível desenvolver um SBC-
Fuzzy
que contemple tais variáveis;
• Criar indicadores de validação do SBC-
Fuzzy
proposto e da metodologia a ele incorporada e
selecionar os especialistas que irão validá-lo;
• Ajustar as entradas e saídas do SBC-
Fuzzy
desenvolvido em função dos resultados do
processo de validação com os especialistas;
• Testar em campo o SBC-
Fuzzy
e a metodologia proposta para ratificar os resultados do
processo de validação com os especialistas.
29
1.6 JUSTIFICATIVAS E CONTRIBUIÇÕES
Muitos programas de MCC, quando não abandonados no todo ou parcialmente, têm
desempenho insatisfatório Blanco (2007). As metodologias existentes não possuem mecanismos
suficientemente eficazes para diagnosticar e se resguardar dos fatores responsáveis por esses
insucessos dos programas de MCC. Nesse sentido esse trabalho se justifica e contribui nos
seguintes aspectos:
• A proposição de uma metodologia para verificar a aderência das características da empresa
aos requisitos de um programa de MCC, possibilita a adequação do procedimento de
implantação, ou, mudanças nos aspectos internos da empresa que afetam a MCC,
vislumbrando uma implementação futura;
• A investigação dos fatores críticos que podem afetar o sucesso de um programa de MCC ao
longo de todo o seu ciclo de vida, torna possível criar barreiras para resguardar o programa de
MCC dos efeitos dos fatores técnicos e gerenciais que o afetam negativamente;
• O desenvolvimento de uma metodologia para facilitar à implantação da MCC focada nos
fatores críticos, relacionados tanto com os aspectos técnicos quanto gerenciais, agregará valor
aos procedimentos existentes de implantação da MCC, e o SBC-
Fuzzy
, associado à
metodologia proposta, permitirá diagnosticar e orientar o processo decisório de forma a
minimizar os riscos de insucesso;
• O procedimento de análise de pré-requisitos e auditoria, proposto neste trabalho, pode servir
como indicador para o acompanhamento do desempenho do processo de implantação da
MCC, focado nos fatores relevantes para o seu sucesso. A partir destes indicadores é possível
realimentar o processo de implantação e promover as correções necessárias.
A implantação e a gestão da MCC envolvem decisões com base em dados qualitativos e
quantitativos. Destaca-se, neste processo, a importância da experiência e conhecimento técnico dos
administradores do programa de MCC. Para gerir este conhecimento e tratar as incertezas inerentes ao
processo decisório e de diagnóstico dos fatores que são críticos para o sucesso de um programa de
MCC, mencionados em itens anteriores, este trabalho se justifica e contribui nos seguintes aspectos:
• Proposição de uma técnica baseada em IA (SBC-
Fuzzy
) para: tratamento e estruturação das
incertezas por imprecisão ou léxicas do processo decisório; diagnóstico qualitativo dos fatores
que impactam na implantação da MCC; e proposição de regras de conduta que minimizem os
riscos de insucesso do programa de MCC;
• Criação de um repositório de conhecimento heurístico referente ao processo de implantação da
MCC. Esse conhecimento é particularmente importante para criar de barreiras que
minimizarão os fatores de insucesso, revertendo na melhoria do desempenho do programa de
MCC.
30
1.7 DELIMITAÇÃO DO TEMA
O estudo realizado e as proposições apresentadas nesse trabalho estão delimitados, em termos
contextuais, pelos seguintes aspectos:
• Os aspectos normativos e conceituais têm como referência:
→ As normas: IEC-60300-3-11, 1999; SAE JA 1011, 1999; SAE JA 1012, 2002;
→ Especialistas em implantação e gestão de MCC;
→ Programas consolidados de MCC, em diferentes estágios de evolução. Assim será
possível identificar, fatores de insucesso da MCC ao longo de todo o seu ciclo de vida,
incluindo planejamento, implantação e gestão.
• A GC fundamenta a consecução de mecanismos para explicitação do conhecimento tácito dos
operadores, mantenedores e especialistas em MCC para assim, avaliar os pré-requisitos e
auditar a implantação da MCC;
• O conhecimento tratado neste trabalho é, em sua maioria, de natureza qualitativa com uma
incerteza por imprecisão intrínseca. Para tratar essas incertezas e estruturar a coleta de
informações, diagnóstico e apoio à decisão é desenvolvido um SBC-
Fuzzy
;
• O SBC-
Fuzzy
desenvolvido não trata dos procedimentos metodológicos e documentais para
implementação das etapas do processo de implantação da MCC, mas sim da análise de seus
pré-requisitos e sua auditoria. Para as etapas mais expressivas do procedimento de
implantação da MCC softwares complementares são desenvolvidos para sanar problemas
específicos de cada etapa, evidenciados ao longo do processo de aquisição do conhecimento.
Portanto a consolidação dos objetivos deste trabalho estará delimitada pela utilização da lógica
Fuzzy
devido às suas vantagens inerentes, citadas por Fernandes (2004, p. 28), as quais são detalhadas
no Capítulo 4, e pela GC como elemento estruturante para explicitação do conhecimento tácito
valendo-se dos benefícios citados por Alkaim (2003).
1.8 METODOLOGIA DA PESQUISA
Silva e Menezes (2005) classificam uma pesquisa de quatro maneiras: quanto aos
procedimentos adotados, quanto à natureza, quanto à forma de abordagem e quanto aos objetivos.
Conforme a classificação sugerida por Silva e Menezes (2005) quanto aos procedimentos
metodológicos utilizados neste trabalho tem-se: pesquisa bibliográfica, levantamento, pesquisa
participante e pesquisa-ação. O material bibliográfico abrange os aspectos norteadores deste
trabalho (GC, IA e MCC), os quais são explicitados em capítulos específicos. Os levantamentos
ocorreram junto aos especialistas que participaram da elicitação do conhecimento, os quais também
de modo participante contribuíram para composição do SBC-
Fuzzy
e das ferramentas
31
complementares, propostas para as etapas mais expressivas do processo de implantação da MCC.
As técnicas para aquisição e representação do conhecimento são mostradas no Capítulo 4. O
problema coletivo e a participação cooperativa que evidencia a pesquisa-ação estão caracterizados
de seguinte forma: o problema coletivo diz respeito à implantação e auditoria da MCC como forma
de gestão da manutenção, em seus diversos domínios de aplicação; e os envolvidos de modo
cooperativo foram especialistas em MCC, participantes do processo de elicitação do conhecimento
para consolidação do SBC-
Fuzzy
desenvolvido.
Quanto à sua natureza, esta pesquisa se caracteriza como aplicada o que, segundo Silva e
Menezes (2005), gera conhecimento para aplicações práticas e dirigidas à solução de problemas
específicos. A aplicação prática está caracterizada na implantação de programas de MCC. O
problema específico que se quer resolver é a análise dos pré-requisitos e a auditoria das etapas de
implantação da MCC, com uma visão holística de seus pré-requisitos e das características e
necessidades organizacionais, tratando as incertezas do processo decisório.
Em relação à forma de abordagem, proposta por Silva e Menezes (2005), este trabalho se
classifica como qualitativo. Deste modo, as dinâmicas da MCC foram analisadas de forma indutiva,
focando no processo e em seus pontos críticos com o objetivo de inferir uma metodologia genérica
que minimize os fatores de insucesso.
Quanto aos objetivos, seguindo a definição de Gil (1996), este trabalho se classifica como
exploratório, pois visa proporcionar maior familiaridade com as etapas de implantação da MCC com
o objetivo de tornar explícitos seus conceitos e requisitos, corroborando com a construção das
hipóteses e concepção da metodologia proposta. Envolve ainda, levantamento bibliográfico,
entrevista com especialistas e estudo e análise de casos.
Quanto ao desenvolvimento do SBC-
Fuzzy
, foi adotado o modelo incremental. Neste
modelo é possível que as etapas do ciclo de desenvolvimento sejam seguidas utilizando apenas
pequenas partes de conhecimento em relação à totalidade do domínio do conhecimento. Esse
procedimento permite retornos às etapas anteriores, caso seja constatado algum tipo de erro ou
inadequação em alguma tomada de decisão ao longo do processo, seguindo assim os conceitos de
Engenharia Simultânea propostos por Silva (1998).
A formatação deste trabalho segue as normas e recomendação da Universidade Federal de
Santa Catarina (UFSC) para trabalhos acadêmicos. As figuras cuja fonte não esteja citada
subentende-se como sendo do autor.
1.9 ESTRUTURA DO TRABALHO
Os capítulos iniciais tratam cada um dos temas envolvidos como um assunto específico focado
nos objetivos deste trabalho. Nos capítulos finais é explicitada a inter-relação entre os diversos temas
abordados e o modo como este relacionamento é implementado para cumprir os objetivos desta tese.
Sendo assim, excluindo-se o presente Capítulo, os demais, possuem o seguinte conteúdo:
32
•
O Capítulo 2 apresenta os tópicos principais referentes à MCC e às metodologias tradicionais
para sua implantação e gestão. Este capítulo norteia as inovações propostas e serve de apoio
para o planejamento da etapa de aquisição do conhecimento;
• O Capítulo 3 trata dos conceitos e definições relativas à gestão do conhecimento e sua
importância para a criação e a disseminação sistematizada do conhecimento institucional,
particularmente aquele aplicado à implantação da MCC e sua auditoria. As necessidades e
aspirações apontadas neste capítulo ratificam a concepção do SBC-
Fuzzy
proposto;
• O Capítulo 4 mostra o ciclo de desenvolvimento de um SBC-
Fuzzy
, evidenciando as etapas
mais relevantes, as definições e os conceitos. Este capítulo oferece suporte à gestão do
conhecimento tratada no Capítulo 3, fundamentando a criação de um repositório de
conhecimento que serve de apoio à tomada de decisão e diagnóstico das características da
empresa e/ou sistema, frente aos requisitos da MCC, auxiliando também em sua auditoria;
• O Capítulo 5 explicita a metodologia proposta para auxiliar a implantação da MCC de modo a
ponderar as características e objetivos da empresa/sistema e os requisitos de um programa de
MCC, incluindo sua auditoria;
• O Capítulo 6 apresenta os detalhes do desenvolvimento do SBC-
Fuzzy
proposto para apoio à
decisão e diagnóstico dos fatores inerentes a implantação e auditoria da MCC. A aplicação
computacional tratada neste capítulo segue os preceitos do Capítulo 5 aliado à fundamentação
teórica dos Capítulos 2, 3 e 4;
• O Capítulo 7 mostra as ferramentas computacionais sugeridas para auxiliar a implementação
das Etapas 3, 4 e 5, do procedimento de referência adotado neste trabalho, explicitado no
Capítulo 5;
• O Capítulo 8 apresenta a validação da metodologia a partir das opiniões e considerações dos
especialistas, além de demonstrar os resultados de uma aplicação em campo da metodologia
proposta e das ferramentas computacionais associadas;
• O Capítulo 9 finaliza o trabalho apresentando a análise dos resultados alcançados bem como
os desdobramentos que podem culminar com trabalhos futuros em temas correlatos.
33
CAPÍTULO 2
MANUTENÇÃO CENTRADA NA CONFIABILIDADE
2.1 INTRODUÇÃO
Este capítulo apresenta os conceitos inerentes a Manutenção Centrada na Confiabilidade
(MCC) com interesse e/ou relacionados aos objetivos deste trabalho. Além dos aspectos teóricos,
também são apresentados os procedimentos para implantação da MCC à luz das bibliografias e
normas de referência. A partir desta abordagem tem-se o arcabouço teórico para vislumbrar: os pré-
requisitos necessários para a implementação das etapas, que compõem o procedimento de
implantação da MCC; as etapas mais expressivas do processo de implantação da MCC; e os
aspectos mais relevantes que devem compor o processo de auditoria de um programa de MCC.
Os itens abordados neste capítulo fundamentam os questionamentos e a base de conhecimento do
SBC-
Fuzzy
(Sistema Baseado em Conhecimento –
Fuzzy
) desenvolvido, para avaliação dos pré-requisitos
e auditoria da MCC. Também procura-se elucidar os fundamentos para compreender as necessidades do
procedimento de implementação das etapas, visando interpor soluções que possam minimizar as
dificuldades comumente experimentadas pela equipe de implantação de um programa de MCC.
2.2 ASPECTOS GERAIS
A norma NBR-5462 (ABNT, 1994) define manutenção como sendo “a combinação de
todas as ações técnicas e administrativas, incluindo as de supervisão, destinadas a manter ou
recolocar um item em um estado no qual possa desempenhar uma função requerida”. A mesma
norma define item como sendo “qualquer parte, subsistema, sistema ou equipamento que possa
ser considerado individualmente e ensaiado separadamente”.
Para Moubray (2001), ‘manter’ significa continuar em um estado existente, ou seja, a
manutenção é o conjunto de técnicas de atuação para que os ativos físicos (equipamentos,
sistemas, instalações) cumpram ou preservem sua função. O mesmo autor atribui à manutenção a
função de “assegurar que os itens físicos continuem a fazer o que os seus usuários querem que
eles façam”. Essa mudança de enfoque proposta, de atenção não ao item, mas à função que ele
possui, representa a ruptura do paradigma de manutenção proposto pela MCC. De acordo com
Rausand (2003), o objetivo principal da MCC é reduzir o custo de manutenção, focalizando as
funções mais importantes do sistema, evitando ou removendo ações de manutenção que não são
absolutamente necessárias.
A MCC é, portanto, uma metodologia para analisar as funções do sistema e o modo como
estas funções podem falhar para, então, aplicar um critério de priorização explícito baseado em
fatores ambientais, econômicos, operacionais e de segurança, a fim de identificar as tarefas de
34
manutenção aplicáveis e efetivas (MOUBRAY, 2001; SIQUEIRA, 2005; SMITH, 1993; SMITH
e HINCHCLIFFE, 2003).
2.2.1 Evolução Histórica da MCC
A MCC teve suas origens na década de 50 como resultado de vários estudos de
confiabilidade desenvolvidos pela indústria da aviação civil americana. Entretanto, foi na década de
60 que os conceitos da MCC foram desenvolvidos pela indústria aérea americana como resposta a
um novo cenário que surgia, ou seja, um crescente aumento dos custos de manutenção e baixa
confiabilidade na manutenção preventiva tradicional, baseada no tempo. Além destes, outros fatores
também contribuíram tais como o aumento da quantidade e diversidade dos ativos físicos a serem
mantidos, projetos cada vez mais complexos e otimizados, novas metodologias de manutenção e o
crescente reconhecimento da responsabilidade da manutenção dentro de uma organização.
Em 1967, representantes das linhas aéreas, fabricantes e o governo americano apresentaram
o MSG-1 (
Maintenance Steering Group
– Grupo Governamental “de Condução” da Manutenção),
cujo objetivo era estabelecer um procedimento adequado de manutenção, de modo a reduzir o
tempo de paralisação, os custos associados e melhorar a segurança de vôo para o Boeing 747. Em
1970, um segundo grupo foi formado, o MSG-2, que gerou o
Airline Manufacturer Maintenance
Program Planning Document
(Documento de Planejamento do Programa de Manutenção dos
Fabricantes de Aeronaves). Este documento generalizava os procedimentos específicos de
manutenção do MSG-1, de modo a torná-lo aplicável para todas as aeronaves. A partir dos
documentos MSG-1 e MSG-2, Nowlan e Heap (1978) desenvolveram um estudo mais detalhado,
encomendado pelo Departamento de Defesa dos Estados Unidos, para a determinação de normas e
procedimentos de manutenção com base em uma ampla análise estatística. Este documento,
conhecido como MSG-3, tornou-se um marco para a manutenção da indústria aeronáutica, no qual
os autores denominaram a metodologia de manutenção proposta de
Reliability Centered
Maintenance
(RCM – MCC). Os estudos de Nowlan e Heap (1978) consolidaram e proporcionaram
a base teórica para o desenvolvimento da MCC. Desses estudos, duas conclusões se destacaram:
1) Revisões programadas têm pouco efeito na confiabilidade total de um equipamento
complexo, a menos que exista um modo de falha dominante;
2) Existem muitos equipamentos para os quais não há forma efetiva de manutenção
programada.
A partir dos estudos iniciais de Nowlan e Heap (1978), vários autores e instituições
propuseram metodologias ligeiramente diferentes para a implantação da MCC (NOWLAN e
HEAP, 1978; SMITH, 1993; SMITH e HINCHCLIFFE, 2003; MOUBRAY, 2001; NASA, 2000;
IEC 60300-3-11, 1999; SAE JA 1011, 1999; SAE JA 1012, 2002; ABS, 2004), as quais serão
abordadas em um item específico deste capítulo.
35
2.2.2 Considerações sobre os Mecanismos de Falha
De acordo com a NBR-5462/1994, falha é o “término da capacidade de um item em
desempenhar a função para o qual foi projetado”. A falha pode ser tanto o colapso total do sistema,
quando este deixa de operar por completo, como o desvio do ponto ou faixa desejada de operação.
Neste último caso, se a resposta do sistema está fora da faixa tolerada, o sistema está deixando de
cumprir a sua função e, por conseguinte, falhou. Em um equipamento complexo, composto de
muitos componentes, cada qual com um mecanismo de falha diferente, a curva da probabilidade
condicional de falhas por unidade de tempo ou taxa instantânea de falha λ(t) ao longo do período de
vida do equipamento será uma combinação dos mecanismos de falha de cada componente,
ponderada pela sua participação e influência temporal na função principal do equipamento. Esta
curva, conhecida como a Curva da Banheira (Figura 2.1), é utilizada, quando aplicável, para
representar o comportamento típico do mecanismo de falha agregado destes componentes. Na fase
inicial, região 1 da Figura 2.1,
ocorrem as denominadas falhas de juventude, normalmente
associadas a erros de projeto ou de fabricação. Durante a vida operacional, região 2, as falhas
ocorrem com uma probabilidade aproximadamente constante (falhas aleatórias). O final da vida do
componente, região 3, caracteriza-se por forte influência da degradação e a probabilidade
condicional de falhas aumenta significativamente (MONCHY, 1989).
Região 1 Região 2 Região 3
Curva Global
Falhas Prematuras
Falhas
p
or Des
g
aste
Falhas Aleatórias
λ(t)
Taxa de Falhas
Tempo (t)
Figura 2.1 – Curva da Banheira.
Fonte: adaptado de MOUBRAY, 2001.
O estudo dos mecanismos de falha busca identificar as características peculiares das
diversas formas como as falhas acontecem e assim escolher a melhor estratégia de manutenção
(SIQUEIRA, 2005). A constatação de que diferentes mecanismos de falhas provocam diferentes
comportamentos nos equipamentos, ao longo da sua vida útil, constituiu o ponto de partida da
metodologia MCC. Os estudos originais de Nowlan e Heap (1978) conduziram à identificação de
três comportamentos básicos dos componentes (não estruturais de aeronaves comerciais) ao longo
da sua vida útil, com relação à taxa instantânea de falha:
1) Alguns componentes mostram uma idade bem definida de desgaste, onde ocorre um
aumento rápido na taxa instantânea de falha, λ(t);
36
2) Outros componentes podem apresentar uma taxa instantânea de falha λ(t) constante;
3) Outros componentes podem não apresentar qualquer degradação funcional ao longo da
vida útil.
Estes comportamentos deram origem às seis curvas básicas de taxas instantâneas de falhas,
observadas ao longo da vida útil dos componentes (MOUBRAY, 2001; SMITH e HINCHCLIFFE,
2003; SEIXAS, 2004; SIQUEIRA, 2005). A Figura 2.2 mostra em quatro estudos (UAL –
United
Air Lines
, Bromberg,
United States Navy
– Navio e Submarino) o percentual de componentes, dos
sistemas avaliados, com suas relativas taxas instantâneas de falha (identificadas de A a F).
Da Figura 2.2, pode-se concluir que:
Taxa Instantânea de Falhas
A
λ(t)
(t)
λ(t)
λ(t)
λ(t)
λ(t)
λ(t)
(t)
(t)
(t)
(t)
(t)
B
C
D
E
F
2%
10%
17%
9%
56%
6%
1 2 3
A
λ(t)
(t)
λ(t)
λ(t)
λ(t)
λ(t)
λ(t)
(t)
(t)
(t)
(t)
(t)
B
C
D
E
F
3%
17%
3%
6%
42%
29%
1 2 3
A
λ(t)
(t)
λ(t)
λ(t)
λ(t)
λ(t)
λ(t)
(t)
(t)
(t)
(t)
(t)
B
C
D
E
F
3%
1%
4%
11%
15%
66%
1 2 3
A
λ(t)
(t)
λ(t)
λ(t)
λ(t)
λ(t)
λ(t)
B
C
D
E
F
(t)
(t)
(t)
(t)
(t)
4%
2%
5%
7%
14%
68%
1 2 3
UAL
1968
Bromberg
1973
U.S. Navy
1982 (Navio)
U.S. Navy
2001 (Submarino)
Figura 2.2 – Padrões de Taxa Instantânea de Falhas.
Fonte: adaptado de SEIXAS, 2004.
a) O padrão A é muito semelhante ao apresentado na Figura 2.1, referente à Curva da Banheira;
b) O padrão B mostra uma etapa de taxa instantânea de falha constante ou lentamente crescente,
terminando num período que é fortemente influenciada pela degradação;
c) O padrão C mostra um leve aumento da taxa instantânea de falha, mas sem a identificação do
período de degradação;
d) O padrão D mostra uma baixa taxa instantânea de falha quando o sistema é novo, depois um
rápido crescimento até se chegar a um nível constante;
e) O padrão E mostra uma taxa instantânea de falhas constante ao longo de todo o período de
vida do sistema;
f) O padrão F começa com uma alta taxa instantânea de falhas quando o sistema é novo, para
logo depois cair para uma taxa de falhas constante.
37
Para SMITH e HINCHCLIFFE (2003) estes resultados contradizem a crença de que sempre
há uma conexão entre confiabilidade e idade do sistema em operação. Com relação às falhas, Seixas
(2004) lembra que não se deve descartar o fator humano como causador de tais falhas, citando dois
tipos de erros que podem culminar com uma falha: erros ativos e erros latentes. Os erros ativos são
aqueles em que o efeito é prontamente observado, enquanto o erro latente é aquele onde a
conseqüência leva um determinado tempo para ser observada. O erro latente é, na verdade, uma
combinação de diversos fatores ao longo do tempo que culminam com uma falha.
2.2.3 Considerações Bibliográficas e Normativas
Segundo Siqueira (2005), devido às similaridades dos requisitos de segurança com a
indústria aeronáutica, a MCC foi também inserida na indústria elétrica e nuclear. Em 1981, dez
anos após as interações iniciais da
United Airlines
com a Marinha Americana, a RCM foi adotada
na manutenção de submarinos nucleares. Nesse mesmo ano, Anthony M. Smith, então na
General
Electric
, e Tom Matteson da
United Airlines
, iniciaram, através do EPRI (
Electric Power Research
Institute
), os estudos de viabilidade de aplicação da MCC em usinas elétricas nucleares, os quais
motivaram o EPRI, em 1984, a recomendar sua aplicação na geração nuclear. Isso motivou a
empresa
Florida Power & Light
, em 1985, a testar sua efetividade através de um projeto piloto na
Usina
Turkey Point
, sob o patrocínio do EPRI e liderança de Anthony M. Smith e Tom Matteson.
Este projeto foi seguido, em 1986, por outro projeto piloto na Usina Nuclear
McGuire
da Duke
Power. Estas experiências consolidaram a metodologia hoje adotada em mais de 400 usinas
nucleares e regulamentada pela NRC (
National Regulatory Commission
) nos Estados Unidos.
A rápida disseminação da MCC motivou o desenvolvimento de versões ligeiramente
diferentes da versão original de Nowlan e Heap (1978). Sua adaptação ao chão de fábrica, além da
introdução de questões ambientais motivou Moubray (2001) a propor modificações na lógica MCC,
chamando esta versão de RCM2. Visando reduzir o esforço despendido na implementação de
programas de MCC, o EPRI propôs uma versão simplificada, denominada de SRCM (
Streamlined
RCM
). Mais recentemente, Smith e Hinchcliffe (2003) propuseram novas versões baseadas,
respectivamente, no método clássico (
Abbreviated Classical RCM
) e na experiência (
ECM –
Experience Centered Maintenance
). Tais propostas revelam uma disputa comercial por marcas
registradas, motivando a necessidade de normatização da metodologia.
O esforço internacional de normatização da MCC iniciou-se com a publicação, em março
de 1999, da norma IEC 60.300-3-11(
Dependability Management – Part 3-11: Application Guide –
Reliability Centred Maintenance
). Já em agosto de 1999, foi publicada a norma internacional SAE
JA 1011, (
Evaluation Criteria for Reliability Centered Maintenance (RCM) Processes
), contendo
os critérios mínimos que uma metodologia de gestão da manutenção deve apresentar para que seja
chamada de MCC, na visão da SAE (
Society of Automotive Engineers
). Esta norma decorreu de
uma solicitação do governo americano à SAE, em 1995, para substituição da norma
correspondente da força aérea (
ATA MSG3 – Air Transport Association of America –
38
Maintenance Steering Group – Task Force 3 – Operator/Manufacturer Scheduled Maintenance
Development
). Em janeiro de 2002, estes critérios foram detalhados com a publicação da norma
SAE JA 1012, (
A Guide to the Reliability Centered Maintenance (RCM) Standard
), que interpreta
cada um dos itens da norma SAE JA 1011. Simultaneamente, o relatório ATA MSG-3 continua
sendo referência na elaboração dos programas de manutenção da indústria aeronáutica, tendo sido
revisado em 2007 pela FAA (
Federal Aviation Administration
).
2.2.4 Atributos e Critérios de um Processo de MCC
Existem quatro atributos, segundo Moubray (2001), que definem e caracterizam a MCC,
tendo relação direta com seus objetivos:
a) Preservação da função do sistema;
b) Identificação das falhas funcionais e aplicação da FMEA (
Failure Modes and Effects Analysis
– Análise dos Modos de Falha e seus Efeitos);
c) Classificação e priorização das falhas funcionais segundo suas conseqüências;
d) Elaboração das atividades de manutenção segundo sua viabilidade técnica e seu
custo/benefício, utilizando um diagrama de decisão.
O processo de implantação da MCC consiste em sistematizar ações, normalmente
orientadas por uma lista de verificação na forma de perguntas sobre os ativos ou sistemas a serem
analisados. Tais ações devem ser documentadas. Os questionamentos que orientam as ações são:
1) Quais são as funções associadas e os padrões de desempenho associados ao ativo no seu
contexto operacional atual (Funções)?
2) De que forma o ativo falha em cumprir suas funções (Falhas Funcionais)?
3) O que causa cada falha funcional (Modos de Falha)?
4) O que acontece quando ocorre cada falha (Efeitos da Falha)?
5) Qual o impacto dos efeitos do modo de falha na operação do sistema, no meio ambiente,
na segurança e na economia do processo (Conseqüências da Falha)?
6) O que pode ser feito para prevenir cada falha (Tarefas Aplicáveis e Efetivas)?
7) O que deve ser feito se não for encontrada uma tarefa aplicável e efetiva adequada (Ações
Default
)?
Na prática, e de acordo com Siqueira (2005), costuma-se acrescentar mais uma questão
com o objetivo de definir qual a melhor freqüência para as tarefas de manutenção aplicáveis e
efetivas. Tal questão é:
8) Qual a freqüência ideal para as tarefas de manutenção aplicáveis e efetivas?
Uma norma ou procedimento de implantação da MCC deve, portanto, responder e
documentar, de forma auditável, as respostas aos questionamentos supracitados. Para este
processo, por sua vez, pode-se utilizar diversas ferramentas e métodos. Neste trabalho, adota-se
39
um procedimento de referência para implantação da MCC, o qual será explicitado no Capítulo 5,
que se aplica somente à consecução dos objetivos deste trabalho.
2.3 CONCEITOS INERENTES A IMPLANTAÇÃO DA MCC
O objetivo deste item é apresentar os principais conceitos inerentes ao processo de
implantação da MCC, particularmente aqueles relativos à análise e tomada de decisão. Tais
conceitos são intrínsecos e necessários para compreensão das metodologias e normas referentes à
implantação da MCC, a serem abordados em itens subseqüentes, sendo que também servirão de
base para a aquisição de conhecimento e desenvolvimento do SBC-
Fuzzy
proposto.
Função, Falha Potencial, Falha Funcional e Modo de Falha
A função é aquilo que se deseja que o item/ativo/sistema faça, dentro de um padrão de
desempenho especificado (MOUBRAY, 2001; SMITH e HINCHCLIFFE, 2003; SIQUEIRA,
2005). As seguintes considerações normatizadas e bibliográficas elucidam o conceito de função:
● IEC 60300-3-11/1999 (Pg. 17 item 3.1.15) → Ação característica normal de um item;
● SAE JA1011/1999 (Pg. 04 item 3.13) e SAE JA1012/2002 (Pg. 06 item 3.13) → Aquilo
que o proprietário ou usuário do ativo físico ou sistema deseja que o mesmo faça;
● SAE J1739/2002 (Pg. 31 item 5.2.9) → A descrição da função deve levar em conta
normas aplicáveis de desempenho, de material, de processo, ambientais e de segurança;
● Moubray, 2001 (Pg. 22 item 2.1) → A descrição da função deve consistir de um verbo,
um objeto e um padrão desejado de desempenho.
As funções de cada item/ativo/sistema, em seu contexto operacional, podem ser divididas
em duas categorias:
● Funções Primárias: estão relacionadas ao motivo pelo qual o item/ativo/sistema foi
projetado e cobrem questões como velocidade, quantidade, capacidade de transporte ou
armazenagem, qualidade do produto e serviços ao cliente;
● Funções Secundárias: são aquelas esperadas, e que vão além do cumprimento das funções
primárias. Estão relacionadas às expectativas do usuário com relação à segurança,
controle, conforto, proteção, contenção, integridade estrutural, economia, conformidade
com os regulamentos ambientais e até a aparência do ativo.
Uma falha potencial é uma condição identificável e mensurável que indica uma falha
funcional pendente ou em processo de ocorrência. A falha funcional é caracterizada pelo
descumprimento da função e é definida como a incapacidade de um item/ativo/sistema
executar uma função específica dentro dos padrões desejados de desempenho (MOUBRAY,
40
2001; SMITH e HINCHCLIFFE, 2003; SIQUEIRA, 2005). As seguintes considerações
normatizadas elucidam o conceito de falha funcional:
● IEC 60300-3-11/1999 (Pg. 17 item 3.1.17) → Falha na qual um item não consegue
desempenhar uma ou mais de suas funções requeridas;
● SAE JA1011/1999 (Pg. 04 item 3.14) e SAE JA1012/2002 (Pg. 06 item 3.14) → Um
estado no qual um ativo físico ou sistema é incapaz de desempenhar uma função
específica com o desejável nível de desempenho.
A falha funcional é provocada por um modo de falha, definido como um evento ou
fenômeno físico que provoca a transição do estado “cumprindo a função” para o estado “não
cumprindo a função” (Figura 2.3). Netherton (2002
apud
ALKAIM, 2003) faz uma extensa
análise das possíveis interpretações de modo de falha. As seguintes considerações normativas e
bibliográficas elucidam o conceito de modo de falha:
● MIL-STD-1629A/1980 → É a maneira a partir da qual a falha é observada;
● IEC 60300-3-11/1999 (Pg. 17 item 3.1.12) → Um dos possíveis estados de falha de um
item, para uma dada função requerida;
● SAE JA1011/1999 (Pg. 04 item 3.12) e SAE JA1012/2002 (Pg. 06 item 3.12 e Pg. 14 item
8) → Um evento ou condição física, que causa uma falha funcional;
● SAE J1739/2002 (Pg. 31 item 5.2.10) → Maneira como uma máquina/equipamento falha
ao executar sua função;
● Moubray, 2001 (Pg. 53 item 4.1) → Qualquer evento que cause uma falha funcional.
Para a análise da função, da falha funcional e do modo de falha, além das causas do modo de
falha e os efeitos provocados no sistema, a MCC utiliza a FMEA ou a FMECA (
Failure Modes,
Figura 2.3 – Estágios Evolutivos da Falha.
Fonte: adaptado de SIQUEIRA, 2005.
P (Falha Potencial)
F (Falha Funcional)
Margem de
Deterioração
Normal
Degradação
da Função
Função
Defeito
Falha
Desempenho
Ciclo Vida
Modo de Falha
Intervalo de Inspeção
Intervalo PF
41
Effects and Criticality Analysis
– Análise dos Modos de Falha seus Efeitos e sua Criticidade) caso a
criticidade também necessite ser avaliada (SIQUEIRA, 2005). Segundo a norma SAE J1739 (2002)
a FMEA/FMECA pode ser descrita como um conjunto de atividades sistemáticas que visa:
reconhecer e avaliar a falha de um produto/processo e os efeitos dessa falha; identificar ações que
possam eliminar ou reduzir a chance de uma falha ocorrer; e documentar o processo.Para os estudos
da MCC é comum acrescentar-se uma coluna à planilha de FMEA/FMECA proposta pela SAE
J1739, destinada a análise da falha funcional. Para o preenchimento desta coluna, a MCC utiliza
uma abordagem funcional, caracterizando a falha como a perda da função (parcial ou total) ou
desvio funcional. Já para o preenchimento da coluna modo de falha a MCC utiliza uma abordagem
estrutural, o que enseja a necessidade de informações/especificações mais detalhadas de engenharia
para evidenciar o que causou a falha funcional. Segundo Siqueira (2005) cabe à manutenção tratar
os modos de falha, assim como, cabe ao projeto/engenharia do item/ativo/sistema tratar as causas do
modo de falha. Mais detalhes do preenchimento da FMEA/FMECA, com base nas diversas normas
e bibliografias pesquisadas, são mostrados no Apêndice A deste trabalho.
Funções Significantes e Classificação de seus Modos de Falha
Das funções analisadas na FMEA/FMECA são significantes, do ponto de vista da MCC,
aquelas com algum impacto sobre os seguintes aspectos: segurança, meio ambiente, operação e
economia do processo. Tais funções terão seus modos de falha classificados e serão submetidas às
etapas seguintes do processo decisório da MCC. Esta classificação se dá, primeiramente, pela
evidência ou não do modo de falha e/ou seus efeitos e, em seguida, pelo impacto nos aspectos
anteriormente citados. Dessa forma, os modos de falha das funções significantes podem ser
classificados em: ESA – Evidente com efeito na Segurança ou Ambiente; EEO – Evidente com
efeito Econômico ou Operacional; OSA – Oculto com efeito na Segurança ou Ambiente e OEO –
Oculto com efeito Econômico ou Operacional (IEC 60300-3-11, 1999; SIQUEIRA, 2005). A
identificação das funções significantes e a classificação de seus modos de falha é operacionalizada
a partir de diagramas de decisão, os quais variam em termos de formatação conforme as normas e
bibliografias pesquisadas. Mais detalhes dos aspectos supracitados serão tratados no Capítulo 5,
quando da abordagem do procedimento de referência adotado neste trabalho.
Tarefas de Manutenção Aplicáveis e Efetivas
Com os modos de falha classificados, determinam-se quais tarefas de manutenção deverão
ser adotadas para prevenir ou corrigir cada modo de falha das funções significantes ou,
alternativamente, reduzir seus efeitos e conseqüências para níveis aceitáveis. Cabe salientar que,
para a MCC, tais tarefas devem ser aplicáveis e efetivas. Serão aplicáveis se: prevenirem os
42
modos de falha; reduzirem a taxa de deterioração; detectarem a evolução da falha; descobrirem as
falhas ocultas; suprirem necessidade e consumíveis do processo e/ou repararem o item após a
falha. E serão efetivas se: forem aplicáveis tecnicamente; viáveis com os recursos disponíveis; se
produzirem os resultados esperados; e forem executáveis a um intervalo razoável do ponto de
vista do proprietário/usuário. Quando não é possível identificar uma tarefa preventiva, aplicável e
efetiva, a MCC sugere a utilização de tarefas
default
(padrão), as quais incluem reprojeto e
operação até a falha com reparo funcional posterior (SIQUEIRA, 2005). Mais detalhes dos
aspectos relacionados às tarefas de manutenção serão tratados no Capítulo 5, na abordagem do
procedimento de referência adotado neste trabalho.
2.4 METODOLOGIAS PARA IMPLANTAÇÃO DA MCC
Este item apresenta as principais metodologias para implantação da MCC, a partir das
quais será possível propor um procedimento de referência, o qual servirá de base para os
desenvolvimentos deste trabalho. As metodologias tratadas neste item seguem a estrutura
mostrada na Figura 2.4, a qual enfatiza as entradas/pré-requisitos de cada etapa do processo de
implantação, bem como suas atividades inerentes e saídas esperadas de cada etapa.
Saídas da Etapa.
Atividades a serem desenvolvidas na Etapa.
ETAPA Nº: NOME DA ETAPA
• Entradas / Pré-Requisitos da Etapa.
Figura 2.4 – Estrutura para Síntese das Metodologias Estudadas.
Todas as metodologias apresentadas nos próximos itens pressupõem a documentação, de
maneira auditável, das decisões tomadas em cada etapa e a incorporação de tais decisões no
sistema de planejamento e controle da manutenção.
2.4.1 Metodologia Proposta pela IEC 60300-3-11
A IEC 60300-3-11 (1999) fornece as orientações para o desenvolvimento de um programa
inicial de manutenção preventiva para equipamentos e estruturas, utilizando as técnicas de análise
propostas pela MCC. Este guia de aplicação é uma extensão do guia IEC 60706-4 (1992), o qual
descreve as tarefas requeridas para o planejamento e suporte à manutenção e as interfaces entre a
confiabilidade, mantenabilidade e o plano de suporte a manutenção. A metodologia proposta pela
IEC 60300-3-11 é mostrada na Figura 2.5.
43
Figura 2.5 – Metodologia para Implantação da MCC proposta pela IEC 60300-3-11.
Fonte: IEC 60300-3-11, 1999.
Programa de MCC
Informações devidamente detalhadas e padronizadas, para alimentar as
etapas seguintes.
As informações devem ser coletadas antes do início da análise e
disponibilizadas conforme a necessidade aumenta.
ETAPA 1: COLETA DE INFORMAÇÃO
• Projetos, normas, requisitos de equipamentos e
sistemas associados e outros documentos;
• Conhecimento sobre os requisitos dos
equipamentos e sistemas;
• Especialistas na operação e manutenção.
Sistemas e fronteiras devidamente identificados e detalhados.
Dividir o equipamento em sistemas; Organizar os componentes em grupos
funcionais; Identificar as fronteiras.
ETAPA 2: IDENTIFICAÇÃO DOS SISTEMAS
• Projetos, normas e requisitos de equipamentos e
sistemas associados e outros documentos;
• Conhecimentos sobre os requisitos dos
equipamentos e sistemas;
• Especialistas na operação e manutenção.
Funções devidamente identificadas e detalhadas
Identificar as funções principais e auxiliares desempenhadas pelos sistemas e
subsistemas.
ETAPA 3: IDENTIFICAÇÃO DAS FUNÇÕES DOS SISTEMAS
• Projetos, normas e requisitos de equipamentos e
sistemas associados e outros documentos;
• Conhecimentos sobre os requisitos dos
equipamentos e sistemas;
• Especialistas na operação e manutenção.
Sistemas selecionados e priorizados.
Selecionar e priorizar os sistemas; Avaliar de acordo com a segurança,
disponibilidade e fatores econômicos.
ETAPA 4: SELEÇÃO DOS SISTEMAS
• Normas, leis, projetos, banco de dados, históricos
de manutenção e outros documentos;
• Conhecimento sobre os equipamentos;
• Especialistas como fonte de informação e uso das
ferramentas.
Lista de falhas funcionais, caracterizadas e priorizadas.
Identificar as falhas/degradação das funções (falhas funcionais); Classificar
as falhas pela criticidade.
ETAPA 5: IDENTIFICAÇÃO E CLASSIFICAÇÃO DAS FALHAS
• Informações sobre custo-benefício das tarefas,
sobre os modos de falha, histórico de falha, etc...;
• Conhecimento para identificar e classificar falhas;
• Especialistas para avaliações qualitativas.
Lista de itens funcionalmente significantes para orientar a seleção das
tarefas de manutenção.
Identificar, listar e detalhar os itens funcionalmente significantes.
ETAPA 6: ITENS FUNCIONALMENTE SIGNIFICANTES
• Descrição das funções, falhas funcionais e efeitos,
para identificação dos itens significantes;
• Conhecimento sobre os requisitos dos sistemas para
identificar os itens;
• Especialistas para avaliar os itens.
Tarefas de manutenção selecionadas.
Aplicar o diagrama lógico tratando de cada falha funcional; Analisar pelos
efeitos e categorias dos efeitos.
ETAPA 7: SELEÇÃO DAS TAREFAS DE MANUTENÇÃO
• Itens funcionalmente significantes, funções, falhas
funcionais, tarefas de manutenção etc...;
• Conhecimento para seleção de tarefas e uso das
ferramentas;
• Especialistas para avaliação das informações.
Resultados obtidos para realimentação do programa.
Organizar um plano inicial de manutenção baseado na MCC a partir dos
resultados obtidos.
ETAPA 8: PROGRAMA INICIAL
• Procedimentos de manutenção documentados e
detalhados, manuais etc...;
• Conhecimento para execução das tarefas;
• Especialistas para execução das tarefas e registro de
resultados.
Informações para realimentar o programa e avaliar o programa inicial.
Com as novas informações obtidas, através do programa inicial, avaliar os
resultados e realimentar o programa.
ETAPA 9: AVALIAÇÃO E REALIMENTAÇÃO
• Resultados obtidos no programa inicial,
formalizados e padronizados;
• Conhecimento para avaliar os resultados;
• Especialistas para avaliar os resultados.
44
2.4.2 Metodologia Proposta pela SAE JA1011/JA1012
A metodologia proposta pelas normas SAE JA1011 (1999) e SAE JA1012 (2002) foi
criada para atender a demanda internacional por um padrão que definisse quais os requisitos que
um programa de gestão da manutenção deve cumprir, para que possa ser chamado de MCC. Os
critérios estabelecidos pelas normas da SAE são baseados em processos e conceitos de MCC
contidos em normas publicadas pela marinha americana MIL-STD-2173(AS) (
Reliability
Centered Maintenance Requirements of Naval Aircraft, Weapons Systems and Support
Equipment
) e sua sucessora a NAVAIR 00-25-403 (
Guidelines for the Naval Aviation Reliability
Centered Maintenance Process
– Versão de 1996), no documento original de Nowlan e Heap
(1978) e na versão (publicada em 1997) de Moubray (2001).
A metodologia proposta pelas normas SAE JA1011 (1999) e SAE JA1012 (2002) segue a
seqüência mostrada na Figura 2.6.
2.4.3 Metodologia Proposta pela ABS (
American Bureau of Shipping
)
O guia da ABS (2004) fornece um resumo das várias técnicas de manutenção utilizadas na
indústria, para sistemas e máquinas e, também, como essas técnicas podem ser aplicadas dentro da
filosofia da MCC. Segundo este guia, com a aplicação dos princípios da MCC, a manutenção é
avaliada e aplicada de maneira mais racional, fornecendo resultados mais positivos para o
proprietário/operador das embarcações e instalações em terra. Além disso, o guia apresenta a
MCC como uma parte do gerenciamento de risco, permitindo o entendimento das perdas
associadas às falhas dos equipamentos e propiciando um programa de manutenção mais
otimizado.
A metodologia proposta pela ABS (2004), para implantação da MCC segue a seqüência
mostrada na Figura 2.7.
2.4.4 Metodologia Proposta pela NASA (
National Aeronautics and Space Administration
)
A metodologia proposta pela NASA (2000) está incorporada em um guia criado para
fornecer informações detalhadas, auxiliar na implementação dos conceitos e dar suporte aos
programas de MCC, dentro das suas instalações. O objetivo foi ter à disposição, em um único
documento de referência, a identificação de requisitos da MCC durante o ciclo de vida das
instalações, os requisitos de desempenho em projetos e contratos e os requisitos de projeto para
mantenabilidade. Essa metodologia segue a seqüência mostrada na Figura 2.8.
45
Figura 2.6 – Metodologia para Implantação da MCC – SAE JA1011/JA1012.
Fonte: SAE JA1011, 1999 e SAE JA1012, 2002.
Programa de MCC
Falhas das funções identificadas e detalhadas;
Identificar como um Sistema pode deixar de cumprir suas funções (Falhas
Funcionais).
ETAPA 2: FALHAS FUNCIONAIS
• Projetos, normas, histórico de manutenção, etc...;
• Conhecimento sobre os requisitos dos equipamentos
e sistemas;
• Especialistas na operação e manutenção.
Modos de Falha identificados, relacionados a cada falha Funcional;
Identificar detalhadamente as causas para as Falhas Funcionais (Modos de
Falha).
ETAPA 3: MODOS DE FALHA
• Projetos, normas, histórico de manutenção, etc.;
• Conhecimento para decidir pela inclusão ou
exclusão de um Modo de Falha da análise;
• Especialistas na operação e manutenção.
Efeitos identificados, relacionados a cada Falha Funcional.
Identificar as conseqüências caso ocorra um determinado Modo de Falha
(Efeitos).
ETAPA 4: EFEITOS DAS FALHAS
• Projetos, normas, requisitos de equipamentos e
sistemas e outros documentos para identificar os
efeitos;
• Conhecimento sobre os equipamentos e sistemas;
• Especialistas na operação e manutenção.
Conseqüências das Falhas categorizadas.
Categorizar as conseqüências de cada falha, separando modos de falha
ocultos e evidentes.
ETAPA 5: CONSEQÜÊNCIAS DAS FALHAS
• Projetos, normas, histórico de manutenção, etc.;
• Conhecimento sobre os equipamentos e Sistemas;
• Especialistas na operação e manutenção.
Políticas de gerenciamento de falhas, selecionadas e detalhadas.
Selecionar as políticas de gerenciamento da falha de acordo com o ciclo de
vida, probabilidade de ocorrência, custos, facilidade, viabilidade etc...
ETAPA 6: GERENCIAMENTO DA FALHA
• Projetos, normas, histórico de manutenção, planilhas
de custos, etc.;
• Conhecimento para avaliar e selecionar políticas;
• Especialistas na operação e manutenção.
Informações detalhadas para o gerenciamento das conseqüências das
falhas.
Levantar as informações sobre as conseqüências da falha para permitir o
correto gerenciamento.
ETAPA 7: GERENCIAMENTO DAS CONSEQÜÊNCIAS
• Conseqüências das Falhas e informações
probabilísticas;
• Conhecimento para avaliação de riscos;
• Especialistas na operação e manutenção.
Políticas de manutenção aplicáveis, avaliadas para cada sistema.
Selecionar uma ou mais políticas de manutenção para a implementação da
MCC, avaliadas e organizadas de acordo com cada sistema.
ETAPA 8: PROGRAMAÇÃO DAS TAREFAS
• Informações sobre as condições no ciclo de vida,
ocorrência em relação à idade; históricos de falhas,
etc...;
• Conhecimento sobre os equipamentos e sistemas;
• Especialistas na operação e manutenção.
Modos de Falhas identificados, relacionados a cada falha das funções.
Identificar os sistemas onde apenas um reprojeto garante a confiabilidade e
aqueles cuja política de manutenção será a corretiva.
ETAPA 9: REPROJETO E MANUTENÇÃO CORRETIVA
• Informações sobre as falhas, conseqüências,
ocorrência, custos, etc.;
• Conhecimento sobre as falhas e as políticas;
• Especialistas na operação e manutenção.
Políticas de gerenciamento para cada Modo de Falha identificado e
suas respectivas tarefas;
Selecionar as políticas de gerenciamento para cada falha, por abordagem
rigorosa ou diagramas de decisão.
ETAPA 10: SELEÇÃO DAS TAREFAS
• Informações sobre as falhas, conseqüências,
ocorrência, custos, etc...;
• Conhecimento sobre as falhas e as políticas de
manutenção;
• Especialistas na operação e manutenção.
Funções devidamente identificadas e descritas;
Definir as funções e padrões de desempenho dentro do contexto de
operação.
ETAPA 1: FUNÇÕES
• Projetos, normas, requisitos de equipamentos e
sistemas, questionários e outros documentos;
• Conhecimento sobre os equipamentos e sistemas;
• Especialistas na operação e manutenção.
46
Figura 2.7 – Metodologia para Implantação da MCC – ABS.
Fonte: ABS, 2004.
Programa de MCC
Descrição dos modos operacionais; Sistemas funcionais com as fronteiras;
Priorização dos grupos funcionais; Contexto operacional.
Características operacionais dos navios e de cada sistema; Separação em
grupos funcionais, sistemas específicos e em itens dos equipamentos.
ETAPA 1: DEFINIR OS SISTEMAS
• Descr
•
•
dos
ição dos sistemas, históricos, normas, Modos
de Falhas etc.;
Conhecimento sobre o funcionamento e manutenção
dos equipamentos;
Especialistas na operação
e manutenção para descrição
equipamentos.
Funções e suas falhas devidamente identificadas, detalhadas e
documentadas.
Identificar as funções; Identificar as falhas funcionais que resultam em
perda total ou parcial da função;
ETAPA 2: FUNÇÕES E FALHAS FUNCIONAIS
• Pr
inform
com
com
•
ojetos e outros documentos que contenham
ações sobre os equipamentos ou instalações,
o as entradas e saídas, interação entre
ponentes etc...;
Especialistas na operação e manutenção
Detalhamento das funções, falhas, modos de falhas, causas, efeitos, etc...
Estabelecer as relações entre causa e efeito; Relacionar efeito final e falha
funcional; Avaliar a criticidade do Modo de Falha.
ETAPA 3: CONDUZIR A FMECA
•
norm
• Conheci
• Es
ferra
Descrição dos sistemas, históricos de falhas,
as, listas de Modos de Falhas, etc.;
mento para utilizar as ferramentas e
conduzir a FMECA;
pecialistas nos equipamentos e uso das
mentas.
Modos de Falha, estratégias, processo de análise seguido, equipes de
trabalho, considerações e exclusões.
Selecionar e organizar estratégias de gerenciamento de falhas e tarefas de
manutenção; Reprojeto; Avaliar condição (preditiva).
ETAPA 4: SELECIONAR ESTRATÉGIAS DE GERENCIAMENTO DA FALHA
• In
•
dos M
•
formações coletadas na FMECA;
Conhecimento para uso das ferramentas e análise
odos de Falha;
Especialista para seleção de estratégias.
2.4.5 Metodologia Proposta por Nowlan e Heap
Nowlan e Heap (1978) apresentaram a primeira abordagem da MCC como uma disciplina
lógica para o desenvolvimento de um programa de manutenção programada. Tendo como
referência a manutenção de aeronaves e equipamentos militares, o objetivo da metodologia
proposta era explorar a confiabilidade dos equipamentos e, assim, minimizar seus custos de
manutenção. Cada tarefa de manutenção programada é gerada com uma razão explícita e
identificada: garantir que os equipamentos cumpram com suas funções. A metodologia proposta
por Nowlan e Heap (1978) é mais rigorosa do que as adotadas na época por tratar,
detalhadamente, das conseqüências das falhas das funções e avaliar os modos de falhas e suas
causas. Tal metodologia foi baseada na experiência dos autores no desenvolvimento de
abordagens de manutenção dentro da
United Airlines
, servindo como referência para os
programas de manutenção de aeronaves comerciais, submetidos à FAA, e equipamentos militares.
Segundo a proposta de Nowlan e Heap (1978), um programa de manutenção tem quatro objetivos
básicos: assegurar que os níveis de segurança e confiabilidade dos equipamentos sejam
alcançados; recuperar os níveis de segurança e confiabilidade quando ocorre a deterioração dos
equipamentos; obter as informações necessárias para a melhoria de projeto dos itens com
confiabilidade insatisfatória; e alcançar esses objetivos com o mínimo custo.
47
A metodologia proposta por Nowlan e Heap (1978) segue a seqüência mostrada na
Figura 2.9.
Figura 2.8 – Metodologia para Implantação da MCC – NASA.
Fonte: NASA, 2000.
Programa de MCC
Sistemas e suas fronteiras devidamente identificados.
Divisão dos sistemas complexos em subsistemas; Identificar os sistemas;
Definir as fronteiras dos sistemas.
ETAPA 1: SISTEMAS E FRONTEIRAS
• Projetos e outros documentos que contenham
informações sobre os equipamentos e instalações;
• Conhecimento sobre o funcionamento dos
equipamentos a serem mantidos;
• Especialistas na operação e manutenção.
Funções e suas falhas devidamente identificadas e detalhadas.
Identificar as funções que definem as expectativas de desempenho;
Identificar as Falhas Funcionais.
ETAPA 2: FUNÇÕES E FALHAS
• Projetos e outros documentos que contenham
informações sobre os equipamentos e instalações;
• Conhecimento sobre o funcionamento dos
equipamentos a serem mantidos;
• Especialistas na operação e manutenção.
Modos de Falhas, relacionados a cada Falha Funcional, identificados.
Identificar os Modos de Falha.
ETAPA 3: MODOS DE FALHA
• Documentação dos Sistemas, para identificação dos
Modos de Falha;
• Conhecimento necessário para estabelecer os Modos
de Falha;
• Especialistas como fontes de informação sobre os
Modos de Falha.
Confiabilidade relacionada a cada Sistema e Modo de Falha
identificados.
Avaliar a confiabilidade dos sistemas; Obter informações sobre o
comportamento dos componentes com a idade.
ETAPA 4: CONFIABILIDADE
• Histórico de falhas, dados confiabilísticos dos
componentes, descrição dos sistemas, etc...;
• Conhecimento para avaliação da confiabilidade e
uso das ferramentas;
• Especialista para avaliação da confiabilidade.
Falhas Funcionais caracterizadas.
Caracterizar as falhas, quanto à relação entre a Ocorrência das Falhas, o
tempo de operação e o ciclo de funcionamento dos sistemas.
ETAPA 5: CARACTERÍSTICAS DAS FALHAS
• Descrições dos Efeitos das falhas, sua probabilidade
de Ocorrência, etc...;
• Conhecimento necessário para identificar as
conseqüências das falhas, sua Criticidade, etc...;
• Especialistas na manutenção e operação do sistema.
Listagem e descrição de: Funções, Falhas Funcionais, Modos de
Falha, Causas e Efeitos.
Desenvolver a análise de FMEA do ponto de vista da missão ou operação.
ETAPA 6: FMEA
• Descrições dos Efeitos das falhas, sua probabilidade
de Ocorrência, etc...;
• Conhecimento necessário para identificar as
conseqüências das falhas, sua Criticidade, etc...;
• Especialistas na manutenção e operação do sistema.
Políticas de gerenciamento de falhas e tarefas de manutenção
descritas.
Avaliar as informações obtidas a fim de selecionar para quais Sistemas
deve-se aplicar manutenção reativa, preventiva, preditiva ou proativa.
ETAPA 7: COMPONENTES DO PROGRAMA
• Informações sobre os Modos de Falhas devidamente
detalhados;
• Conhecimento para avaliação do custo-benefício das
tarefas de manutenção, para as falhas identificadas, e
definição do programa de manutenção;
• Especialistas na manutenção e operação do sistema.
2.4.6 Metodologia Proposta por Moubray
A partir do início dos anos 80, Moubray (2001) e seus colaboradores auxiliaram a
aplicação da MCC em diversas empresas, levando ao desenvolvimento dos conceitos
(denominado RCM2) que nortearam a concepção das Normas SAE JA1011 e SAE JA1012. Trata-
48
se de uma metodologia para aplicação da MCC em empresas/indústrias de setores diversos, além
da aviação, e que acrescenta em sua análise o tratamento de questões ambientais.
A metodologia proposta por Moubray (2001) segue a seqüência mostrada na Figura 2.10.
Figura 2.9 – Metodologia para Implantação da MCC – NOWLAN e HEAP.
Fonte: Nowlan e Heap, 1978.
Programa de MCC
Itens identificados e detalhados, quanto às funções, modos de falha, etc...
Reduzir a análise do problema a um tamanho gerenciável; Direcionar a
análise de acordo com as áreas de conhecimento de engenharia.
ETAPA 1: DESDOBRAR OS EQUIPAMENTOS
• Pr
•
•
descr
ojetos, normas, diagramas e outros documentos;
Conhecimento sobre o funcionamento dos
equipamentos, falhas e modos de falha;
Especialistas na operação e manutenção para
ição dos equipamentos.
Itens significantes identificados e detalhados.
Identificar itens cujas falhas resultam em conseqüências para a segurança ou
economia do processo; Identificar itens que possuem funções ocultas; Identificar
itens
q
ue necessitam de manutenção
p
ro
g
ramada.
ETAPA 2: ITENS SIGNIFICANTES
• Pr
•
•
descr
ojetos, normas, diagramas e outros documentos;
Conhecimento sobre o funcionamento dos
equipamentos, falhas, modos de falha;
Especialistas na operação e manutenção para
ição dos equipamentos.
Requisitos de manutenção e tarefas selecionadas para o programa de
manutenção detalhadas.
Avaliar os requisitos dos itens significantes; Selecionar as tarefas que
satisfazem os requisitos.
ETAPA 3: REQUISITOS DE MANUTENÇÃO
• Descr
fa
•
•
das fer
ição dos itens, históricos de falha, modos de
lha, etc...;
Conhecimento sobre os itens;
Especialistas para a identificação das funções e uso
ramentas.
Itens sem tarefas efetivas identificáveis e/ou sem informações
complementares.
Identificar itens sem tarefas aplicáveis; Identificar itens sem recomendações
de reprojeto; Identificar itens que necessitam de informações adicionais.
ETAPA 4: ITENS SEM TAREFAS EFETIVAS
• Descr
fa
•
•
das fer
ição dos itens, históricos de falha, modos de
lha, etc.;
Conhecimento sobre os itens;
Especialistas para a identificação das funções e uso
ramentas.
Documento contendo as funções, falhas relacionadas e intervalos para
prevenção da Ocorrência das falhas.
Selecionar os intervalos iniciais para organizar todas as tarefas definidas,
ou grupo de tarefas, em pacotes de manutenção a serem implementados.
ETAPA 5: INTERVALOS INICIAIS
• In
•
•
para
formações sobre a Ocorrência de falhas, relação
entre idade e confiabilidade, etc...;
Conhecimento sobre os modos de falha para
definição dos intervalos;
Especialistas para avaliar a Ocorrência das falhas e
uso das ferramentas.
Novas informações levantadas sobre itens não tratados anteriormente
para refinamento do programa inicial.
Sistematizar a coleta de informações, necessárias para determinar a aplicabilidade
de algumas tarefas de manutenção, e avaliar a efetividade de outras.
ETAPA 6: EXPLORAÇÃO DA IDADE
• In
inicial,
•
info
•
formações sobre o programa de manutenção
ciclo de vida dos componentes, etc...;
Conhecimento para coleta e avaliação das
rmações;
Especialistas para realizar as inspeções, registrar os
resultados e analisá-los.
2.4.7 Metodologia Proposta por Smith
A experiência de Smith (1993) está relacionada, principalmente, com as áreas de sistemas
aeroespaciais, motores a jato e usinas nucleares de geração de energia. Tal experiência serviu de
base para um dos livros clássicos da MCC, de Anthony M. Smith, publicado em 1993, que
estende a MCC a setores além da aeronáutica. A amizade profissional com o engenheiro Thomas
D. Matteson, pioneiro da MCC e que participou do desenvolvimento da metodologia adotada pela
FAA, como padrão para a manutenção preventiva de aeronaves, originou discussões sobre
49
problemas de confiabilidade, segurança, operação e manutenção. Na década de 80 as aeronaves
acumularam mais horas em operação do que os reatores nucleares comerciais dos Estados Unidos,
resultando em um produto mais maduro, sendo que os reatores apresentavam problemas similares
àqueles experimentados pelas aeronaves comerciais com o passar dos anos. Percebeu-se, então, o
benefício potencial do uso das práticas e procedimentos adotados na indústria de aviação
comercial, adaptadas para as usinas nucleares.
A metodologia proposta por Smith (1993), para implantação da MCC, segue a seqüência
mostrada na Figura 2.11.
Figura 2.10 – Metodologia para Implantação da MCC – MOUBRAY.
Fonte: Moubray, 2001.
Programa de MCC
Funções identificadas e descritas, com seus devidos padrões de
desempenho.
Definir quais são as funções para os componentes ou sistemas; Definir os
padrões de desempenho para cada função.
ETAPA 1: DEFINIÇÃO DAS FUNÇÕES
• Projetos, normas e outros documentos;
• Conhecimento sobre o funcionamento e manutenção
dos equipamentos;
• Especialistas na operação e manutenção para
descrição dos equipamentos.
Falhas relacionadas a cada função devidamente identificadas e
detalhadas.
Identificar as falhas funcionais relacionadas às funções identificadas.
ETAPA 2: FALHAS FUNCIONAIS
• Projetos, históricos de falha e outros documentos;
• Conhecimento sobre os equipamentos e sobre as
falhas;
• Especialistas na operação e manutenção.
FMEA, contendo os modos de falhas e seus efeitos identificados,
relacionados a cada falha funcional.
Identificar os modos de falha; Identificar os efeitos dos modos de falha.
ETAPA 3: FMEA
• Descrição dos componentes, listas de modos de
falha etc...;
• Conhecimento sobre os sistemas e modos de falha;
• Especialistas nos sistemas e componentes para
identificação dos modos de falha.
Documentos contendo as conseqüências identificadas, relacionadas a
cada falha funcional.
Avaliar as conseqüências das falhas para a organização, relacionadas à
segurança, operação e meio ambiente
ETAPA 4: CONSEQÜÊNCIAS DAS FALHAS
• Normas, leis, projetos e outros documentos;
• Conhecimento sobre a operação e manutenção;
• Especialistas para a identificação das conseqüências.
Tarefas de manutenção preventiva selecionadas e descritas.
Avaliar os modos de falha; Avaliar as características de deterioração;
Avaliar o contexto operacional; Identificar as tarefas de manutenção.
ETAPA 5: TAREFAS PREVENTIVAS
• Levantamentos do custo-benefício das tarefas,
modos de falha, históricos de falha etc...;
• Conhecimento sobre as características de
deterioração dos sistemas,
• Especialistas para a tomada de decisão
Tarefas de manutenção preditiva e as técnicas de avaliação da
condição devidamente detalhadas.
Avaliar as condições dos equipamentos; Avaliar o potencial de Ocorrência de
falhas; Definir as ações a serem tomadas caso a falha seja eminente.
ETAPA 6: TAREFAS PREDITIVAS
• Informações sobre as falhas, Ocorrência, relação
entre o potencial das falhas e o tempo etc...;
• Conhecimento sobre as falhas potenciais para
avaliação das tarefas;
• Especialistas para seleção das tarefas.
Seleção e detalhamento de ações para aumentar a confiabilidade das
funções.
Definir e aplicar critérios para: Localizar falhas; Propor reprojeto; Operar
até a ocorrência de falha; Realizar rondas de inspeção.
ETAPA 7: AÇÕES PADRÃO
• Projetos, manuais de fabricantes, bancos de dados
comerciais etc...;
• Conhecimento sobre benefícios e viabilidade de
cada ação;
• Especialistas para avaliação das informações e
seleção das ações padrão.
50
Figura 2.11 – Metodologia para Implantação da MCC – SMITH.
Fonte: Smith, 1993.
Programa de MCC
Sistemas definidos e selecionados, com as informações coletadas,
(Ex.: Diagramas que facilitam a visualização).
Selecionar os Sistemas; Definir a ordem de análise; Organizar a coleta de
informações.
ETAPA 1: SELEÇÃO DOS SISTEMAS
• Critér
•
• Docu
bloc
•
ios de seleção;
Conhecimento sobre os equipamentos e os critérios
de seleção;
mentos descritivos dos sistemas, diagramas de
o, etc...;
Especialistas na operação e manutenção.
Informações claras e bem definidas sobre os sistemas e suas fronteiras.
Identificar as fronteiras dos sistemas selecionados.
ETAPA 2: FRONTEIRAS DOS SISTEMAS
• Pr
•
•
descr
ojetos, normas, diagramas e outros documentos;
Conhecimento sobre o funcionamento dos
equipamentos, e dos sistemas responsáveis pelas
funções;
Especialistas na operação e manutenção para
ição dos equipamentos.
Descrição dos sistemas e subsistemas (Ex.: diagramas de bloco
funcional, lista de componentes, entradas, saídas etc...).
Identificar e documentar os detalhes essenciais dos sistemas.
ETAPA 3: SISTEMA E DIAGRAMA DE BLOCO
• Inform
siste
• Conheci
funcio
•
siste
ações que contemplem a constituição do
ma e sua operação;
mento sobre os a constituição e
namento dos sistemas;
Especialistas para a identificação e descrição dos
mas.
Funções dos sistemas, falhas funcionais e parâmetros que definem as
falhas funcionais identificados e descritos.
Identificar e listar as funções dos sistemas; Identificar e listar as falhas
funcionais dos sistemas.
ETAPA 4: FUNÇÕES E FALHAS FUNCIONAIS
• Descr
func
•
•
ições dos componentes dos sistemas, seu
ionamento. etc...;
Conhecimento sobre os sistemas;
Especialistas para a identificação das funções e
falhas funcionais.
Modos de falha, componentes relacionados e informações para a
seleção de tarefas devidamente documentados.
Identificar quais os componentes de um sistema que contribuem para a
ocorrência de uma falha funcional.
ETAPA 5: FMEA
• In
m
• Conheci
•
formações sobre as funções, falhas funcionais,
odos de falha, etc...;
mento sobre o projeto e a operação;
Especialistas da manutenção e operação.
Funções, falhas funcionais, modos de falha, etc..., priorizados e
descritos para a seleção das tarefas.
Priorizar e focalizar os recursos a serem aplicados no tratamento dos modos
de falha.
ETAPA 6: DIAGRAMA DE DECISÃO
• In
•
•
formações sobre as funções, falhas funcionais,
equipamentos, componentes e modos de falha;
Conhecimento sobre os equipamentos e sua
operação e manutenção;
Especialistas na manutenção e operação.
Documentação da seleção das tarefas detalhada, organizada em
planilhas, diagramas, formulários etc...
Determinar, para cada modo de falha, as tarefas de manutenção mais
eficazes entre todas as tarefas possíveis.
ETAPA 7: SELEÇÃO DAS TAREFAS
• Info
inform
•
•
rmações obtidas nas etapas anteriores e com as
ações do programa de manutenção existente;
Conhecimento para comparação entre os programas,
avaliação e seleção de tarefas;
Especialistas na manutenção e operação.
2.4.8 Metodologia Proposta por Smith e Hinchcliffe
O livro de Smith (1993) foi atualizado pelo autor em 2004, em co-autoria com Glenn R.
Hinchecliffe, que liderou a aplicação da MCC na
Florida Power & Light
, tendo Anthony M.
Smith como consultor. Neste, os autores aprimoram o conteúdo do livro
Reliability Centered
Maintenance
, Smith (1993), e propõem melhorias na metodologia de implantação da MCC, com
base em questões práticas observadas pelos autores.
51
A metodologia proposta por Smith e Hinchcliffe, (2004) para implantação da MCC segue
a seqüência mostrada na Figura 2.12.
Figura 2.12 – Metodologia para Implantação da MCC – SMITH e HINCHCLIFFE.
Fonte: Smith e Hinchcliffe, 2004.
Programa de MCC
Sistemas definidos e selecionados com as informações relevantes
coletadas (Ex.: diagramas para a visualização).
Selecionar os sistemas; Definir a ordem de análise; Organizar a coleta de
informações.
ETAPA 1: SELEÇÃO DOS SISTEMAS
• Critérios de seleção;
• Conhecimento dos equipamentos e critérios de
seleção;
• Documentos descritivos dos sistemas, diagramas de
bloco, etc...;
• Especialistas na operação e manutenção.
Informações claras e definidas sobre os sistemas e suas fronteiras.
Identificar as fronteiras dos sistemas selecionados.
ETAPA 2: FRONTEIRAS DOS SISTEMAS
• Projetos, normas, diagramas e outros documentos;
• Conhecimento sobre o funcionamento dos
equipamentos, e sistemas responsáveis pelas
funções;
• Especialistas na operação e manutenção para
descrição dos equipamentos e sistemas.
Sistemas e subsistemas descritos (Ex.: diagramas de bloco funcional,
lista de componentes, entradas, saídas, etc...).
Identificar e documentar os detalhes essenciais dos sistemas.
ETAPA 3: SISTEMA E DIAGRAMA DE BLOCO
• Informações que contemplem a constituição do
sistema e sua operação;
• Conhecimento sobre os sistemas e sua constituição e
funcionamento;
• Especialistas para a identificação e descrição dos
sistemas.
Funções dos sistemas, falhas funcionais e parâmetros que definem as
falhas funcionais identificados e descritos.
Identificar e listar as funções dos sistemas; Identificar e listar as falhas
funcionais dos sistemas.
ETAPA 4: FUNÇÕES E FALHAS FUNCIONAIS
• Descrições dos componentes dos sistemas, do
funcionamento, etc...;
• Conhecimento sobre os sistemas;
• Especialistas para a identificação das funções e
falhas funcionais.
Documentação de modos de falha, componentes relacionados e outras
informações para a seleção de tarefas.
Identificar quais os componentes de um sistema que contribuem para a
Ocorrência de uma falha funcional.
ETAPA 5: FMEA
• Informações sobre as funções, falhas funcionais,
modos de falha etc...;
• Conhecimento do projeto e da operação;
• Especialistas da manutenção e operação.
Funções, falhas funcionais, modos de falha, etc..., priorizados e
descritos para a seleção das tarefas.
Priorizar e focalizar os recursos a serem aplicados no tratamento dos modos
de falha.
ETAPA 6: DIAGRAMA DE DECISÃO
• Informações sobre as funções, falhas funcionais,
equipamentos, componentes e modos de falha;
• Conhecimento sobre os equipamentos, operação e
manutenção;
• Especialistas na manutenção e operação.
Documentação das tarefas selecionadas detalhadas, organizadas em
planilhas, diagramas, etc...
Determinar, para cada modo de falha, as tarefas de manutenção mais
eficazes entre todas as tarefas possíveis.
ETAPA 7: SELEÇÃO DAS TAREFAS
• Informações obtidas nas etapas anteriores e com as
informações do programa de manutenção preventiva
existente;
• Conhecimento para comparação entre os programas,
avaliação e seleção das tarefas;
• Especialistas na manutenção e operação.
Tarefas de manutenção definidas, detalhadas e organizadas em
“pacotes”.
Planejar e coordenar a implementação dos resultados da análise
desenvolvida.
ETAPA 8: PACOTES DE TAREFAS
• Resultados da análise, detalhados e organizados;
• Conhecimento para a análise e estruturação das
tarefas, análise do programa e uso das ferramentas;
• Especialistas na manutenção e operação.
Resultados obtidos com o programa, melhorias identificadas e
detalhadas para orientar alterações a serem implementadas.
Validar as decisões de manutenção da MCC; Reavaliar as decisões da MCC;
Realizar ajustes necessários para o programa de manutenção e as definições
b
ásicas da MCC.
ETAPA 9: PROGRAMA CONTÍNUO
• Resultados do programa, alterações na estrutura da
instalação e outras informações para identificar
possíveis melhorias;
• Conhecimento para avaliar o programa e o uso das
ferramentas inerentes;
• Especialistas na manutenção e operação.
52
2.5 CONSIDERAÇÕES E SÍNTESE DO CAPÍTULO
Neste capítulo foram abordados os principais conceitos relacionados à MCC e de especial
interesse aos objetivos deste trabalho, citados no Capítulo 1. Explanadas as definições
relacionadas à manutenção, foram abordados os conceitos inerentes à MCC sendo, então, possível
explicitar as principais metodologias para implantação da MCC, fundamentadas nas bibliografias
e normas comumente utilizadas na prática.
A pesquisa revelou inconsistências e/ou divergências no procedimento de implantação da
MCC, o qual difere entre as normas e bibliografias pesquisadas. Tal constatação revela uma das
dificuldades associadas à implantação da MCC, relacionada à escolha do procedimento mais
adequado para a condução desse processo, respeitando-se as características da empresa/sistema.
Esta observação ratifica a necessidade de compatibilização das características da empresa e/ou
sistema com os requisitos da MCC, o que corrobora com os objetivos deste trabalho. E neste caso,
também ensejou a proposta de um procedimento de referência, abordado no Capítulo 5, para
contemplar as divergências observadas nas normas e bibliografias pesquisadas. No Capítulo 5
também são abordados os desdobramentos e as deliberações processadas a partir dos aspectos
apresentados no presente capítulo. Quanto as questões conceituais e de escopo, as seguintes
observações podem ser feitas em relação as normas e bibliografias pesquisadas:
● A Norma IEC 60300-3-11 é de âmbito internacional e foi concebida para ser aplicada ao
setor elétrico;
● As Normas SAE JA1011 e JA1012 propõem uma metodologia para implantação da MCC
muito semelhante a proposta por Moubray (2001), a qual serviu de base para a SAE. Destaca-
se, neste caso, a preocupação com as questões ambientais nos diagramas de decisão;
● Os guias da NASA e da ABS apresentam abordagens mais específicas, respectivamente
para: instrumentos e equipamentos de segurança; e embarcações e instalações em terra
onde a MCC é parte de uma estratégia para gerenciamento de risco;
● As bases da MCC foram propostas por Nowlan e Heap (1978) entretanto a abordagem
destes autores está fortemente vinculada à manutenção de aeronaves e equipamentos
militares. A aplicação da MCC no setor industrial, a partir dos conceitos de Nowlan e
Heap (1978), se deve a Antony M. Smith (1993). Posteriormente Smith e
Hinchcliffe,
(2004
) aprimoraram a metodologia inicial, proposta por Antony M. Smith (1993),
enfatizando a MCC como um programa contínuo, ressaltando a necessidade de
realimentações e atualizações.
No próximo capítulo são abordados os aspectos relativos à gestão do conhecimento e sua
relação com a MCC.
53
CAPÍTULO 3
GESTÃO DO CONHECIMENTO
3.1 INTRODUÇÃO
As vantagens competitivas, inerentes à manutenção, estão fortemente relacionadas à
política de Gestão do Conhecimento (GC), a qual, associada à Inteligência Artificial (IA), em
especial os Sistemas Baseados em Conhecimento (SBC), resulta em agilidade e efetividade das
intervenções de manutenção, ao mesmo tempo em que preserva o capital intelectual das empresas.
No caso específico da Manutenção Centrada na Confiabilidade (MCC), sua implantação pode ser
mais consistente e eficaz, na medida que o conhecimento institucional é utilizado como elemento
norteador das decisões.
A GC se insere e contribui com este trabalho explicitando, no SBC-
Fuzzy
proposto, o
conhecimento tácito de especialistas em implantação da MCC e mantenedores. Tal conhecimento
será utilizado para confrontar as características específicas da empresa/sistema com as
necessidades da MCC. Assim, é possível ratificar ou não o atendimento da empresa/sistema aos
pré-requisitos da MCC e/ou a conformidade na execução das etapas do processo de implantação.
A aplicação do SBC-
Fuzzy
proposto resulta em um diagnóstico das características da
empresa e sua aderência ou não às necessidades da MCC. As conclusões relativas ao processo de
diagnóstico refletem o estágio atual de aderência da empresa à MCC, servindo de base para
análises futuras da evolução da empresa e guia durante o procedimento de implementação e
auditoria, ou seja, de maneira indireta, reflete/explicita o conhecimento que a empresa tem de suas
próprias habilidades e competências e seu grau de adesão às necessidades da MCC.
3.2 DEFINIÇÕES E CONCEITOS
Tentando ilustrar o conceito de conhecimento, Rezende (2003) e Giarratano e Riley,
(1998) utilizam a pirâmide do conhecimento, Figura 3.1, na qual:
• Ruído: são dados de pouco ou nenhum interesse;
• Dado: é um elemento da informação, um conjunto de letras, números ou dígitos que,
tomados isoladamente, não transmitem nenhuma informação, ou seja, não contém um
significado claro;
• Informação: é todo aquele dado que foi tratado e possui um valor significativo atribuído
ou agregado a ele e, com sentido natural e lógico para quem usa a informação;
54
• Conhecimento: é a informação tratada por pessoas ou recursos computacionais para
geração de cenários. É um termo abstrato que tenta capturar a compreensão do indivíduo
sobre um dado assunto;
• Síntese, Análise e Compreensão: constituem o metaconhecimento, um conhecimento
profundo que descreve o conhecimento sobre o conhecimento, ou seja, as leis básicas que
regem o mundo e a forma como os demais tipos de conhecimento podem ser aplicados. É
usado para selecionar qual o conhecimento mais apropriado para a resolução de um problema.
Segundo Santiago (2004), a informação tem por finalidade exercer algum impacto sobre o
julgamento do destinatário. Ela deve informar e, portanto, pode ser considerada como sendo o
dado que faz a diferença, pois, ao contrário deste, ela possui relevância e propósito. Dados só se
tornam informações a partir dos seguintes métodos:
• Contextualização: definição da finalidade dos dados coletados;
• Categorização: conhecimento das unidades de análise;
• Cálculo: análise matemática dos dados;
• Correção: eliminação das imprecisões e dos erros;
• Condensação: sumarização dos dados existentes.
Para o autor, o conhecimento é uma mistura fluida de experiências, valores, informações
contextualizadas e percepções
“insights”
, além de possibilitar a existência de uma estrutura que
permite a avaliação e incorporação de novas experiências e informações. O conhecimento é
intrínseco as pessoas. Nas organizações ele está presente não apenas em documentos, mas
também em rotinas, processos e práticas e, segundo Davenport e Prusak (1998), a transformação
da informação em conhecimento é possível a partir da:
• Comparação: entendimento sobre como as informações relativas a um determinado
assunto podem ter alguma relação ou aplicação em outras situações;
• Conseqüência: implicação que determinada informação pode trazer para a tomada de
CONHECIMENTO
SINTESE
ANÁLISE
COMPREENSÃO
INFORMA
Metaconhecimento
Ç
ÃO
DADO
RUÍDO
Figura 3.1 – Hierarquia do Conhecimento.
Fonte: adaptado de REZENDE, 2003 e GIARRATANO e RILEY, 1998.
55
alguma decisão e/ou ação;
• Conexão: relação entre a informação adquirida e um conhecimento já existente;
• Conversação: interpretação daquela informação a partir do entendimento sobre o que as
pessoas pensam sobre ela.
A GC busca agregar valor às informações, filtrando, resumindo e sintetizando-as e, dessa
forma, desenvolvendo um perfil de utilização pessoal que ajuda a levá-las à ação. Entre
informação e conhecimento, observa-se que (SANTIAGO, 2004):
• O conhecimento, ao contrário da informação, diz respeito às crenças e compromissos;
• O conhecimento, ao contrário da informação, está relacionado à ação, isto é, o
conhecimento tem um determinado “fim”;
• Tanto informação como conhecimento dizem respeito ao significado específico com
relação a um determinado contexto considerado.
Segundo Abel (2005), o conhecimento pode ser categorizado nos seguintes níveis:
• Conhecimento Superficial: descrição de objetos do domínio, informações que se referem a
problemas imediatos e a solução associada;
• Conhecimento do Domínio: descreve a forma de resolver problemas no domínio na forma
de descrições, heurísticas ou procedimentos, mesmo que muitos deles não sejam
compreendidos teoricamente;
• Conhecimento Profundo: estrutura interna e causal (relações de causa e efeito) dos objetos
do domínio e suas interações. É o conhecimento teórico do domínio que pode ser aplicado
a diferentes tarefas e em mais de uma situação, utilizando mecanismos de transferência e
analogia. Este tipo de conhecimento é de difícil aquisição e trato computacional.
Além do nível, as seguintes categorias de conhecimento têm especial interesse para a
finalidade deste trabalho: declarativo, procedural, heurístico, tácito e explícito.
Segundo Abel (2005), o Conhecimento Declarativo trabalha com uma representação
descritiva do domínio, declara os fatos do mundo, o quê as coisas são, como se associam e se
relacionam no mundo. Quanto ao nível, trata-se de um conhecimento superficial. Já o
Conhecimento Procedural descreve a forma como as coisas trabalham sob diferentes tipos de
circunstâncias, descrito na forma de instruções passo-a-passo. Pode fornecer uma aplicação
imediata para o conhecimento declarativo (ABEL, 2005).
O Conhecimento Heurístico
1
pode ser tratado como um conjunto de regras que conduzem
o processo de raciocínio. É empírico e representa o conhecimento compilado por um especialista
por meio da experiência na resolução de problemas passados. Este é o tipo mais importante de
1
A palavra heurística vem da palavra grega
heuriskein
, e significa descobrir, e também é a origem da palavra
eureca
, derivada da exclamação atribuída a Arquimedes,
heurika
(descobri), dita na descoberta de um método
para determinar a pureza do ouro.
56
conhecimento tratado pelos SBC’s e foi introduzido em IA por George Polya, em 1957, em seu
livro
How to Solve It
(RICH e KNIGHT, 1993; POLYA, 1957).
O Conhecimento Tácito é pessoal e intrínseco ao indivíduo. É um saber subjetivo,
baseado em experiências pessoais e específico ao contexto e, por essa razão, difícil de ser
formulado e comunicado (SANTIAGO, 2004). Segundo Nonaka e Takeuchi (1997), o
conhecimento tácito pode ser de dois tipos: o primeiro, incorporado nas habilidades e que
pode ser copiado, é passível de codificação, podendo ser articulado e escrito. O segundo é
aquele que não pode ser codificado ou escrito, sendo de difícil transferência por não poder ser
demonstrado; é adquirido pela experiência, tendo a interação pessoal um papel fundamental.
Por isso a transferência dessa forma de conhecimento se dá principalmente através das redes
pessoais. O Conhecimento Explícito, por sua vez, é objetivo e facilmente captado, codificado
e compartilhado. Este é um conhecimento transmissível em linguagem formal e sistemática
(SANTIAGO, 2004).
Para Nonaka e Takeuchi (1997), o conhecimento tácito é algo pessoal, presente no cérebro
das pessoas, resultante de suas experiências e ações, formado através das emoções, valores,
desejos ou ideais, mas que, num sentido amplo, é o novo fator de produção para as organizações.
Já o conhecimento explícito é aquele exposto nos documentos, computadores e sistemas de uma
organização, ou seja, foi transferido da mente das pessoas para ser acessado por membros da
empresa, de forma sistematizada e controlada.
3.3 CRIAÇÃO DO CONHECIMENTO
Para Nonaka e Takeuchi (1997), a estrutura conceitual básica, sobre as formas de
administração do processo de criação do conhecimento, possui duas dimensões:
• Ontológica: o conhecimento só pode ser criado por indivíduos. Uma organização, por
si só, não pode criar conhecimento; seu escopo é apoiar os indivíduos e lhes
proporcionar condições para a criação deste. A existência do conhecimento
organizacional é possível a partir de interações que permitam sua criação de forma
individual e a sua disseminação para a organização como um todo;
• Epistemológica: segundo o qual, há dois tipos de conhecimento: Tácito e Explícito.
Os conhecimentos tácito e explícito não são entidades totalmente separadas, mas
mutuamente complementares. O conhecimento humano é criado e expandido através da interação
social entre os conhecimentos tácito e explícito, ao que se chama de Conversão do Conhecimento.
O processo de conversão ocorre conforme o modelo apresentado na Figura 3.2. Este processo,
chamado de Espiral do Conhecimento, pressupõe a superação de um ambiente competitivo e
egocêntrico por um ambiente cooperativo e em harmonia com os objetivos da organização. A
57
espiral do conhecimento é cíclica e seu objetivo é converter o conhecimento tácito individual no
conhecimento tácito institucional (NONAKA e TAKEUCHI, 1997).
Segundo Santiago (2004), da Figura 3.2 cabe ressaltar que:
• Socialização: é um processo de compartilhamento de experiências e, a partir daí, da criação
do conhecimento tácito como modelos mentais ou habilidades técnicas compartilhadas. As
seguintes considerações podem ser feitas:
→ Trata-se de um processo de compartilhamento de experiências diversas e criação do
conhecimento tácito e habilidades técnicas;
→ A aquisição do conhecimento tácito se faz a partir da experiência;
→
Brainstorming
é um meio que permite a reorientação dos modelos mentais de todos os
indivíduos em uma mesma direção, por essa razão, é um meio eficaz para o
compartilhamento de experiências;
→ Coloca o indivíduo na posição daquele que executa a atividade e permite que ele aprenda
in-loco
a partir de uma experiência real;
→ É possível obter essa socialização a partir do contato com os clientes, permitindo a
criação de idéias para aperfeiçoamento de seus produtos e processos.
• Externalização: é um processo de articulação de conhecimentos tácitos em conceitos
explícitos e é provocado pelo diálogo ou pela reflexão coletiva. As seguintes considerações
podem ser feitas:
→ Trata-se da conversão dos conceitos tácitos em explícitos pelo uso de analogias,
conceitos, modelos, hipóteses ou metáforas;
→ A escrita é uma forma de converter o conhecimento tácito em conhecimento explícito,
apesar das discrepâncias e lacunas que possam ocorrer nessa conversão;
→ O processo de criação do conceito pode ser desenvolvido com o diálogo e reflexão
Internalização Combinação
Externalização
Socialização
COMPETIÇÃO
COOPERAÇÃO
1. GERA
R
2. CODIFICAR
3. DISSEMINAR
Tácito Tácito
Tácito Explícito
4. APROPRIA
R
Explícito Explícito
Explícito Tácito
Figura 3.2 – Espiral do Conhecimento.
Fonte: adaptado de NONAKA e TAKEUCHI, 1997.
58
coletiva, para isto, se combina a dedução e a indução;
→ O uso de metáforas ou analogias é muito eficaz, pois estimula o compromisso direto com
o processo criativo e a criação e elaboração de um conceito. A metáfora é uma forma de
perceber ou entender intuitivamente uma coisa, imaginando outra coisa simbolicamente.
As eventuais contradições inerentes no uso de uma metáfora são harmonizadas a partir da
analogia;
→ E o método chave para criação do conhecimento explícito, uma vez que cria conceitos
novos e explícitos a partir do conhecimento tácito.
• Combinação: baseia-se na troca de informações explícitas e no paradigma da tecnologia da
informação. Envolve a combinação de conjuntos diferentes de conhecimento explícito.
Ocorre troca e combinação de conhecimentos através de meios como documentos, reuniões,
ou redes de comunicação computadorizadas. Sendo assim, as seguintes considerações
podem ser feitas:
→ Trata-se do aprendizado formal baseado em informações explícitas e no uso da
tecnologia da informação;
→ Os indivíduos trocam e combinam conhecimentos através de documentos, reuniões,
conversas ao telefone, e-mails ou redes de comunicação computadorizadas;
→ Os métodos formais de educação e treinamento também são exemplos de conversão
desse conhecimento explícito;
→ A combinação também ocorre quando os conceitos de produtos são associados e
integrados aos principais conceitos da organização (visão da empresa).
• Internalização: é o processo de incorporação do conhecimento explícito no conhecimento
tácito da organização. Os membros da organização passam a vivenciar o novo conhecimento
e aprender a partir da sua aplicação “
learning by doing
”. Esse conhecimento tácito
acumulado precisa ser compartilhado com outros membros da organização iniciando, assim,
uma nova espiral de criação de conhecimento. As seguintes considerações podem ser feitas:
→ Trata-se da incorporação do conhecimento nas atividades operacionais da empresa para
obtenção de um resultado prático;
→ Todo ativo de conhecimento obtido nos processos anteriores de socialização,
externalização e combinação tornam-se valiosos quando são internalizados nas bases do
conhecimento tácito dos indivíduos;
→ Há a necessidade da verbalização e diagramação do conhecimento a partir de
documentos, manuais ou relato de histórias. Toda esta documentação permite ao
indivíduo que suas experiências sejam internalizadas, o que aumenta seu conhecimento
tácito;
→ Ouvir a experiência passada por alguém também é um meio para o compartilhamento do
conhecimento tácito que, a partir de então, passa a ser da organização;
59
→ xperiência prática, o “aprender fazendo”, é essencial para o
a
u modo de fazer. A internalização ocorre a partir do “aprender fazendo” (SANTIAGO, 2004).
.4 A IMPORTÂNCIA DA GESTÃO DO CONHECIMENTO (GC)
e o que chamamos de capital intelectual, isto é, o conhecimento tratado como
o
retém e, em algum grau, medido
ínio do conhecimento e a
• e serviços está crescendo
•
esenvolvimentos científicos e tecnológicos ou modificações nas
•
des tecnológicas, podendo levar a transferência do conhecimento direto
subsídios tecnológicos para
plan
A expansão do escopo da e
processo de internalização.
O modelo da espiral do conhecimento pode ser resumido da seguinte forma: inicialmente a
socialização desenvolve um campo de interação que permite o compartilhamento das experiências
dos indivíduos. A partir da externalização se propicia o diálogo ou reflexão coletiva, com o uso de
metáforas ou analogias, o que resulta no conceito. O modo de combinação possibilita a colocação
do conhecimento recém criado junto àquele já existente, resultando em um novo processo, sistem
o
3
Segundo Abel (2005), o conhecimento de uma empresa, tratado como patrimônio volátil,
pode ter um valor agregado que supera todas as instalações físicas ou bens tangíveis da mesma
mpresa. É
comm dity
.
O desafio da Idade do Conhecimento, pela qual passa atualmente a administração de
empresas, é como transformar esse patrimônio volátil e não-registrável, em algo que possa ser
capturado, tornado independente das pessoas que o
(LEBOWITZ, 1987 e LIEBOWITZ e WILCOX, 1997).
Segundo Abel (2005), a motivação crescente pelo dom
capacidade de gerenciá-lo é garantida por diversos fatores, a saber:
O percentual de conhecimento envolvido nos produtos
rapidamente e se reflete na estrutura dos custos de produção;
O conhecimento necessário para implementar processos de negócios muda subitamente,
como resultado de d
relações econômicas;
• A pressão crescente do tempo cada vez menor no qual as decisões gerenciais devem ser feitas;
A mobilidade dos profissionais vem aumentando, devido às modificações nas relações de
trabalho e possibilida
para a concorrência.
A busca de instrumentos que permitam às organizações reter, organizar e otimizar a
utilização do conhecimento é objeto de estudo da GC (LIEBOWITZ e WILCOX, 1997). A
Engenharia de Conhecimento e, em especial, sua aplicação no desenvolvimento de SBC’s é uma
das ferramentas que auxiliam o processo de GC, fornecendo os
im tação e consolidação dos mecanismos demandados pela GC.
60
Boff (2001), descreve a GC como sendo: “um conjunto de estratégias para criar, adquirir,
compartilhar e utilizar ativos de conhecimento e estabelecer fluxos que garantam a informação
necessária no tempo e formato adequados, a fim de auxiliar na geração de idéias, solução de
problemas e tomada de decisão”. A GC é, portanto, o processo sistemático de identificação,
criação, renovação e aplicação dos conhecimentos estratégicos na vida de uma organização. É um
processo corporativo, focado na estratégia empre
sarial e que envolve a gestão das competências,
Terra (2000)
• nhecimento que deverão ter prioridade
• s impostos à inovação, ao aprendizado e à
• e Recursos Humanos: associadas à aquisição de conhecimento externo e interno à
•
do conhecimento nas organizações, associado ao importante papel do
• e Resultados: avaliação dos ganhos obtidos sob diferentes aspectos, desde a
•
a gestão da MCC obtenham êxito. Nesse sentido, as seguintes considerações podem
este trabalho:
• sua
do capital intelectual, a aprendizagem organizacional, a inteligência empresarial e a educação
corporativa (NONAKA e TAKEUCHI, 1997).
Baseado no modelo da Espiral do Conhecimento, proposto por Nonaka e Takeuchi (1997),
destacou as dimensões através das quais a GC pode ser entendida:
Alta Administração: definição dos campos de co
nos esforços de aprendizado dos funcionários da organização, de acordo com a estratégia
organizacional e com as metas a serem atingidas;
• Cultura Organizacional: voltada à inovação e aprendizado contínuo, comprometida com os
resultados de longo prazo e com a otimização das áreas da empresa;
Estrutura Organizacional: para superar os limite
geração de novos conhecimentos, as estruturas tradicionais devem dar lugar a equipes
multidisciplinares com alto grau de autonomia;
Políticas d
empresa, bem como com a geração, difusão e armazenamento de conhecimentos na
empresa;
Sistemas de Informação: uso de tecnologias que ajudem a captação, difusão e
armazenamento
contato pessoal e do conhecimento tácito para os processos de aprendizado
organizacional;
Mensuração d
imagem, até financeiros e a comunicação dessas metas atingidas para todos na
organização;
Aprendizado com o Ambiente: realização de alianças estratégicas com empresas e
aprendizado com os clientes.
No contexto deste trabalho, todas estas dimensões devem ser consideradas para que a
implantação e
ser feitas com relação a cada uma das dimensões propostas por Terra (2000), com relação direta a
Alta Administração: o conhecimento relativo a MCC, tanto anterior como posterior a
implantação, deve ser tratado com prioridade pelos níveis superiores da administração, caso
61
contrário, não haverá comprometimento dos níveis inferiores com o programa de MCC;
Cultura Organizacional: caso a equipe de manutenção não esteja habituada com práticas
que promovam a GC, dificilmente o fará após a
•
implantação da MCC, fortemente
•
, o programa de MCC
•
ostas rápidas às carências da MCC,
•
itação, armazenamento e disseminação do conhecimento e, com o auxílio
• cial
• o com o Ambiente: o conhecimento de programas bem sucedidos de MCC deve
nortear a implantação e a gestão de programas novos, minimizando assim os riscos de
.5 A F
SBC. Tipicamente envolve uma interação entre o construtor do
dependente de dados históricos e documentação dos ativos. Desta forma, dificilmente
ocorrerá a inovação e o aprendizado organizacional;
Estrutura Organizacional: a manutenção não deve estar isolada dos demais setores da
empresa. O conhecimento e as necessidades de toda a organização devem permear as
decisões da MCC e vice-versa. Durante a sua implantação, o conhecimento institucional
deve balizar as decisões do grupo de MCC para que suas decisões sejam aderentes às
características e necessidades da empresa. Ao longo de sua gestão
deve estar vinculado ao conhecimento estratégico que orienta o planejamento da empresa,
para que as ações de manutenção sejam as mais eficazes possíveis;
Políticas de Recursos Humanos: as necessidades e o potencial interno da empresa devem
estar claramente mensurados e avaliados, para dar resp
com a aquisição de conhecimento externo e/ou interno, bem como, garantir o
armazenamento de novos conhecimentos na empresa;
Sistemas de Informação: a MCC é fortemente dependente de um sistema computadorizado
para armazenamento de dados e documentação dos ativos. Este mesmo sistema pode
servir para explic
do SBC-
Fuzzy
proposto neste trabalho, contribuir com o processo de aprendizado
organizacional;
Mensuração de Resultados: o acompanhamento dos resultados do programa de MCC é cru
para realimentá-lo e maximizar os ganhos para a empresa. Todo o conhecimento heurístico ou
explícito deste processo deve ser armazenado para utilização durante o processo decisório;
Aprendizad
insucesso.
3 UNÇÃO DA ENGENHARIA DO CONHECIMENTO NA GC
A Engenharia do Conhecimento teve este nome reivindicado por Ed Feigenbaum, um
dos idealizadores do DENDRAL
2
(DURKIN, 1994), conduzindo ao paradigma do Sistema
Especialista (SE) ou SBC. Segundo Lira e Fantinato (2005), Engenharia de Conhecimento é um
termo usado para descrever o processo global de desenvolvimento de um SE ou, no caso deste
trabalho (ver Capítulo 4), um
2
DENDRAL - Projeto desenvolvido em 1965 na Universidade de Standford (EUA). O objetivo era desenvolver
programas capazes de determinar automaticamente o conjunto de estruturas moleculares, constituídas de átomos
conhecidos, capazes de explicar dados provenientes da análise espectrográfica de uma molécula desconhecida.
62
si , chamado Engenheiro de Conhecimento (EC), e um ou mais especialistas do domínio que
se quer modelar (Figura 3.3).
O EC é o profissional responsável pela estruturação e construção do SBC. Ele aquista
conhecimento de alguma fonte, interpreta e representa em tipos e estruturas convenientes
stema
(LIRA
FANTINATO, 2005). Um estudo mais detalhado pode ser encontrado em Gonzalez e Dankel
(1993)
. Um estudo detalhado das características inerentes a cada tipo de especialista e
interage
des do usuário do SBC;
4) uso direto ou indireto do SBC. Envolver os usuários desde
5)
rente de projeto referem-se à natureza dos problemas relacionados ao
conhecimento. Assim, requisitos de monitoramento são fundamentais durante o ciclo de
vida do projeto;
e
e Rezende (2003) que traçam o perfil e citam as características desejáveis do EC.
Para Lira e Fantinato (2005) os Especialistas, também chamados Peritos ou
Experts
, são
pessoas que possuem um alto grau de conhecimento em um determinado domínio e habilidade
para transmitir esse conhecimento. Em muitos casos, são a fonte de conhecimento para a
concepção do SBC
as especificidades do relacionamento entre o EC e os Especialistas pode ser encontrado em
Rezende (2003).
Schreiber
et al.
(2002), analisando a GC e sua interação com a EC, destaca seis atores que
m durante a concepção de um SBC, são eles, Figura 3.4:
1) Especialista ou Provedor de Conhecimento: papel exercido pela pessoa que detém o
conhecimento. Tradicionalmente é exercido por um especialista no domínio da aplicação;
2) Engenheiro ou Analista de Conhecimento: responsável pela elicitação do conhecimento do
especialista e modelagem do conhecimento com base nas necessida
3) Desenvolvedor do SBC: é o responsável pelo projeto e implementação do SBC a partir da
modelagem feita pelo Engenheiro ou Analista de Conhecimento;
Usuário de Conhecimento: faz
o início do desenvolvimento do sistema, no caso de SBC’s, é mais importante do que no
caso de softwares tradicionais;
Gerente de Projeto: está encarregado de comandar o desenvolvimento do SBC. Os maiores
riscos para o ge
Engenheiro de
Conhecimento
Perguntas
Respostas
RESULTADOS
Es
p
ecialistas
Figura 3.3 – Processo de Construção de um SBC.
63
6) Gerente de Conhecimento: não está diretamente envolvido no desenvolvimento do SBC,
pois sua função é formular uma estratégia de conhecimento ao nível do negócio e garantir
a disseminação do conhecimento.
A GC requer, além da disponibilidade da informação, a experiência, o contexto, a
negociação, a interpretação e a reflexão das pessoas para que essa informação faça sentido e tenha
valor. A aprendizagem organizacional é a base necessária para a realização de uma GC bem
sucedida. Uma proposta eficiente de aprendizagem na empresa significa que os conhecimentos
não serão recursos estáticos acumulados em arquivos ou na cabeça dos indivíduos, mas sim
disponíveis a qualquer tempo para todos os interessados (SANTIAGO, 2004).
Gestor do
Conhecimento
Define a estratégia de conhecimento, indica
o projeto de desenvolvimento e facilita a
distribuição do conhecimento
SBC
Especialista
Provedor de
Conhecimento
Desenvolvedor
do SBC
Gerente de
Projeto
Engenheiro / Analista
do Conhecimento
Usuário do
Conhecimento
Elícita Conhecimento de Administra
Administra
Elícita Necessidades de
Entrega Modelos de
Análise para
Utiliza Pro
j
eta e Im
p
lementa
Valida
Figura 3.4 – Principais Atores do Processo de Construção de um SBC.
Fonte: adaptado de SCHREIBER et al, 2002.
A Engenharia do Conhecimento provê os mecanismos para criação de repositórios de
conhecimento, ao mesmo tempo em que facilita a externalização e a disseminação deste. No
contexto proposto neste trabalho, a Engenharia do Conhecimento dará suporte às necessidades da
GC na criação do SBC-
Fuzzy
que irá auxiliar o processo da implantação e auditoria da MCC,
incluindo diagnóstico e apoio a decisão.
3.6 A GESTÃO DO CONHECIMENTO E O PROCESSO DE MCC
A implantação e a auditoria de um programa de MCC envolvem decisões com base em
dados qualitativos, disponibilizados pelos operadores e mantenedores dos ativos e, dados
quantitativos que podem ser acessados de um banco de dados da própria empresa, o que é salutar,
64
ou banco de dados genéricos disponibilizados por fabricantes ou entidades ligadas à análise
confiabilística.
O aprendizado e o conhecimento produzidos pela manutenção são expressos por
indicadores de desempenho baseados no custo da manutenção, disponibilidade operacional,
confiabilidade (Tempo Médio entre Falhas – MTBF), mantenabilidade (Tempo Médio para
Reparo – MTTR) e índices de acidentes com pessoas, instalações ou meio ambiente.
Seja qual for a etapa do processo de MCC, é importante salientar a necessidade de
experiência no procedimento de implementação e conhecimento técnico de seus executores,
principalmente durante a concepção do FMEA (
Failure Modes and Effects Analysis
– Análise dos
Modos de Falha e seus Efeitos) ou FMECA (
Failure Modes, Effects and Criticality Analysis
–
Análise dos Modos de Falha seus Efeitos e sua Criticidade). A GC viabilizada pelo SBC-
Fuzzy
,
base da metodologia proposta nesta tese, pode ser utilizada para garantir a administração e
armazenamento deste conhecimento e experiência, auxiliando a implementação e a auditoria da
MCC. Tal conhecimento e experiência estão estruturados na inferência
Fuzzy
, proporcionada pelo
SBC sugerido nesse trabalho. Na fase de implementação da MCC, esse conhecimento será
utilizado para verificar a aderência da empresa/sistema aos requisitos exigidos pela MCC,
enquanto que, na fase de auditoria, a implementação correta das etapas é que será avaliada pelo
SBC-
Fuzzy
. Os próximos parágrafos explicitam a relação e a importância de um sistema de GC
para a MCC.
Caracterização do Problema
A metodologia da MCC se caracteriza por envolver nos estudos, implantação, auditoria e
gestão representantes de diversas áreas (manutenção, operação, segurança e qualidade), garantindo
que a visão e as expectativas de cada setor estejam contempladas nas decisões tomadas. Esse grupo
deve analisar, além da viabilidade da MCC para o contexto da empresa/sistema, as necessidades
estratégicas da empresa em termos de aumento de disponibilidade e confiabilidade dos ativos, além
da maneira mais econômica de alcançar estes objetivos. Com isto é possível definir os sistemas e
subsistemas que serão analisados e suas fronteiras. O processo de decisão e o conhecimento
intrínseco a ele devem ser documentados para orientar as decisões e as etapas seguintes do processo.
Produção e Codificação do Conhecimento
O estudo das falhas e as proposições da MCC são realizados sobre os equipamentos e
componentes escolhidos como estratégicos. O conhecimento, necessário para cumprimento desta
etapa, normalmente é sintetizado em um FMEA/FMECA que deve ser armazenado e disseminado
para auxiliar as equipes de manutenção em intervenções futuras. Este conhecimento pode também
ser convertido em regras para um SBC e utilizado para treinamento e apoio a tomada de decisão.
65
Integração de Conhecimento
Definidas todas as atividades, é preciso agrupá-las visando reunir as de mesma
periodicidade, especialidade e tipo de intervenção em um único procedimento de manutenção. O
objetivo final desta etapa é formar procedimentos padrões de manutenção que possam ser
exportados para o Sistema de Controle e Gestão da Manutenção (SCGM) da empresa. Cumpridas
as tarefas agendadas de manutenção, a GC deve garantir a realimentação do programa de MCC,
incorporando os conhecimentos inerentes para consultas futuras.
Disseminação e Apropriação do Conhecimento
Um dos problemas de qualquer metodologia de gestão da manutenção, neste caso a MCC, é
a falta de apropriação dos conhecimentos inerentes às suas ações. Para que a MCC contribua com
vantagens competitivas para a empresa, é necessário disseminar os conhecimentos produzidos e
treinar a equipe de manutenção. Este treinamento deve salientar a importância da documentação das
etapas e do conhecimento envolvido na correção das falhas, principalmente as falhas ocultas ou que
não estavam previstas no FMEA/FMECA inicial e que foram detectadas durante uma intervenção
sistemática ou não. Com isto, garante-se que os procedimentos de manutenção sejam realizados nas
datas corretas, por pessoal especializado, e assim sejam mensurados os resultados da aplicação dos
novos conhecimentos. A partir desses apontamentos é calculada a confiabilidade dos equipamentos,
sendo extraídos os dados para simulação de disponibilidade, adequação das periodicidades de
intervenção e das quantidades de sobressalentes no estoque. Esses procedimentos são indispensáveis
para garantir o sucesso de um programa de MCC.
Resultados Esperados
Os resultados qualitativos, decorrentes da aplicação da GC na MCC são:
• Otimização das ações da manutenção, a partir do registro histórico de falhas, agrupamento
de atividades semelhantes e documentação dos ativos;
• Melhoria contínua focada no aprendizado organizacional;
• Retenção de experiências e conhecimento;
• Envolvimento dos operadores nas ações de manutenção e conservação dos ativos devido
ao maior conhecimento sobre suas funções e modos de falha;
• Organização e atualização da documentação técnica dos ativos e seus componentes.
66
Os resultados quantitativos, decorrentes da aplicação da GC na MCC são:
• Aumento do tempo médio entre falhas (MTBF);
• Diminuição do tempo médio para reparo (MTTR);
• Aumento da disponibilidade operacional do sistema;
• Redução do custo de manutenção;
• Redução do número de acidentes;
• Acréscimo no volume de produção.
3.7 CONSIDERAÇÕES E SÍNTESE DO CAPÍTULO
O conhecimento inerente às atividades de manutenção é, em geral, de natureza tácita com
alto grau de diversidade e forte transferência através do relacionamento interpessoal (ORTIZ, 2004).
A GC implica em uma nova técnica aliada à gestão da manutenção que leva em conta o
conhecimento organizacional para, então, alcançar um diferencial competitivo fundamentado na
efetividade das atividades de manutenção.
No contexto específico, proposto neste trabalho, a teoria da GC orientará a estruturação do
conhecimento dos especialistas e a explicitação do conhecimento tácito dos envolvidos no
processo de implementação e auditoria da MCC. O conhecimento explicitado na metodologia
proposta reflete as características da empresa e o confronto destas com as necessidades da MCC
tornando-se, assim, estratégico para amenizar os fatores de insucesso que podem influenciar o
processo de implantação. A engenharia do conhecimento, especificamente o SBC-
Fuzzy
desenvolvido, é utilizada neste trabalho para dar suporte e orientar a tomada de decisão durante a
análise dos pré-requisitos e a auditoria do processo de implantação da MCC.
Neste capítulo foram abordados os principais conceitos relacionados a GC e de especial
interesse aos objetivos deste trabalho. Elucidados os principais conceitos referentes à hierarquia
do conhecimento, foram discutidos: os processos de conversão e criação do conhecimento; a
importância da GC no contexto deste trabalho; a função da Engenharia do Conhecimento como
suporte da GC; e como a GC pode auxiliar o processo de implantação e auditoria da MCC. As
técnicas e os conceitos, intrínsecos à GC norteiam a implementação do SBC-
Fuzzy
proposto, de
acordo com a finalidade exposta no Capítulo 1.
67
CAPÍTULO 4
SISTEMAS BASEADOS EM CONHECIMENTO
4.1 INTRODUÇÃO
Um dos propósitos deste trabalho é desenvolver um Sistema Baseado em Conhecimento
Fuzzy
(SBC-
Fuzzy
) para auxiliar o processo de implantação e auditoria da Manutenção Centrada
na Confiabilidade (MCC), focado em seus fatores críticos de sucesso. Um destes fatores, o qual
pode comprometer os benefícios da MCC, é o conhecimento tanto do sistema técnico quanto da
melhor estratégia para implementação e auditoria. Este conhecimento, conforme abordado no
Capítulo 3 é reconhecidamente heurístico, o que ratifica a necessidade e os benefícios dos SBC’s.
Analisando o Documento Nacional de 2007 (ABRAMAN, 2007), é possível verificar a
importância e a função estratégica dos SBC’s para a gestão da manutenção nas empresas brasileiras.
Esta importância pode ser concluída com a análise da Figura 4.1, a qual mostra o Grau de
Especialização do Pessoal da Manutenção. Excluindo os anos de 1997 e 1999, observa-se uma forte
concentração do pessoal de manutenção em tarefas de uma mesma especialidade associadas ou não à
tarefas complementares, ou seja, as tarefas de manutenção estão cada vez mais a cargo de
especialistas. Tal constatação enfatiza a importância dos SBC’s para preservação da memória
corporativa, servindo de repositório do conhecimento heurístico dos especialistas além de uma
ferramenta para o treinamento de pessoal e instrumento para consolidação da Gestão do
Conhecimento (GC) principalmente no que diz respeito a explicitação e disseminação.
Este capítulo tratará, portanto dos aspectos relacionados à Inteligência Artificial (IA) em
geral, e sua aplicação no desenvolvimento de SBC’s em particular, para concepção de um sistema
computacional baseado em lógica
Fuzzy
para implementação e auditoria da MCC.
Figura 4.1 – Grau de Especialização do Pessoal da Manutenção.
F
o
nt
e:
a
d
a
p
ta
do
de
ABRAMA
N,
2
00
7
.
0
10
20
30
40
50
60
1995 1997 1999 2001 2003 2005 2007
Mesma Especialidade
Mesma Especialidade + Tarefas Complementares
Mais de uma Especialidade
Ano
Manutenção (%)
Grau de Especialização do Pessoal da Manutenção (%)
Tipo de Tarefa do Pessoal da Manutenção 1995 1997 1999 2001 2003 2005 2007
Mesma Especialidade 8,69 6,90 5,22 6,99 37,98 48,72 12,03
Mesma Especialidade + Tarefas Complementares 51,39 38,79 37,39 50,35 15,51 9,40 47,47
Mais de uma Especialidade 39,92 54,31 57,39 42,66 46,51 41,88 40,5
68
4.2 DEFINIÇÕES E CONCEITOS
Inserido no contexto computacional, o termo Inteligência
1
Artificial (IA) foi introduzido
pelo Dr. John McCarty, em 1956, no MIT -
Massachusetts Institute of Technology
como título da
conferência de Dartmouth, New Hampshire, sobre as possibilidades de fornecer inteligência à
máquina. Esta conferência foi também o primeiro encontro entre os quatro pesquisadores de IA, nos
Estados Unidos, durante duas décadas: McCarthy,
et al
. (1955). Deste encontro nasceram os dois
paradigmas da inteligência artificial: Simbólica e Conexionista, e uma definição de IA atribuída a
John McCarthy, como sendo: o campo da Ciência da Computação que se dedica ao estudo e a
modelagem da inteligência humana. Na IA Simbólica, o comportamento inteligente global é
simulado, sem considerar os mecanismos responsáveis por este comportamento. Na IA
Conexionista, acredita-se que construindo máquinas que imitem a estrutura do cérebro ela
apresentará inteligência (ABEL, 2005).
Tentando definir IA Russell e Norvig (2004) concluíram que esta definição depende de
algumas variantes, relacionadas ao processo de pensamento e raciocínio e ao comportamento.
Assim, segundo Abel (2005), o estudo da IA é distribuído em três grandes áreas:
● Processamento de Linguagem Natural: permite que as pessoas interajam com o
computador da maneira que estão habituadas a se comunicar, utilizando expressões da
linguagem humana;
● Robótica: aliada a engenharia, busca implementar as funções de movimento, percepção e
controle à máquina;
● Processamento de Conhecimento: refere-se ao armazenamento e a manipulação de
conhecimento pela máquina de forma a permitir sua utilização para a resolução de
problemas.
A IA permite construir sistemas para processamento simbólico, o que de muitas formas
reproduz a forma como o ser humano resolve problemas. A partir dos anos 60 foram construídos
sistemas para resolver problemas simbólicos complexos como solução de equações diferenciais
(MACSYMA)
2
, ou proposição de fórmulas químicas estruturais (DENDRAL). A experiência
dessa primeira fase ensinou que a qualidade de solução desses sistemas não era determinada pelos
mecanismos de raciocínio neles embutidos, mas sim pelo conhecimento extraído de especialistas
humanos e codificado no programa. A partir dessa constatação, parte do esforço na construção de
sistemas de IA voltou-se, na segunda fase, para técnicas de extração do conhecimento de
especialistas e codificação em diversos formalismos de representação. Assim nasceu a Engenharia
de Conhecimento e os primeiros Sistemas Especialistas (SE’s), numa alusão à origem do
1
Etimologicamente, a palavra inteligência vem do latim
inter
(entre) e
legere
(escolher). Inteligência significa
aquilo que nos permite escolher entre uma coisa e outra, objetivando eficiência.
2
As descrições destes e de outros sistemas especialistas desenvolvidos nas décadas de 60 e 70 podem ser
encontradas em WATERMAN, 1986, GIARRATANO e RILEY, 1998, GONZALEZ e DANKEL, 1993.
69
conhecimento que esses sistemas aplicavam, dos quais os representantes mais conhecidos desta
época são os sistemas MYCIN que fazia diagnóstico de doenças infecciosas, e PROSPECTOR,
que auxiliava na prospecção de minérios metálicos. Esses sistemas, onde o conhecimento de um
indivíduo (o especialista) era representado em uma base de conhecimento para ser utilizado
exclusivamente por um mecanismo de inferência, respondendo consultas, sem integração com
outros sistemas, estabeleceram as bases para a engenharia de SE’s que orientou a área até o final
dos anos 80 e inicio da década de 90. Assim foram definidos os sistemas especialistas nesta fase
(ABEL, 2005):
● Um programa de computador inteligente que usa conhecimento e inferência para resolver
problemas que são difíceis o suficiente para requerer perícia humana significativa para sua
solução (FEIGENBAUM, 1979);
● Sistema de computação que usa representação de conhecimento ou perícia humana num
domínio particular de forma a executar funções semelhantes às de um Especialista
Humano (EH) naquele domínio (BEYON, 1991);
● Sistemas computacionais que procuram reunir todos os elementos do processo de decisão
de um EH. Estes sistemas reúnem informações especializadas sobre campos de
conhecimento muito específicos (RABUSKE, 1995).
Segundo Abel (2003), uma nova revolução na Engenharia de Conhecimento aconteceu
com o surgimento dos modelos administrativos de GC e das plataformas distribuídas de sistemas.
O modelo tradicional de SE’s restringe-se hoje a aplicações de pequeno porte. Na moderna
Engenharia de Conhecimento, os SE’s foram incorporados aos SBC’s que têm como função,
implementar um processo de solução de problemas que foi racionalizado e padronizado por uma
organização, e não apenas reproduzir o conhecimento de um EH.
Para encadeamento deste trabalho, é importante diferenciar os SE’s dos SBC’s. Os SBC’s
são sistemas capazes de resolver problemas usando conhecimento específico sobre o domínio da
aplicação, normalmente estão inseridos no processo de gestão de um sistema ou organização e
envolvem coleta de dados e manipulação de diversos tipos de conhecimento, por exemplo:
procedural, heurístico e explícito. Os SE são SBC que resolvem problemas ordinariamente
resolvidos por um EH, por isso eles requerem conhecimento sobre a habilidade, a experiência e as
heurísticas usadas pelo especialista, portanto seu desenvolvimento requer uma profunda interação
entre o Engenheiro de Conhecimento (EC) que ira modelar e/ou desenvolver o sistema e o EH.
Assim os SBC’s podem ser classificados como SE quando o desenvolvimento do mesmo é voltado
para aplicações nas quais o conhecimento a ser manipulado restringe-se a um domínio específico e
conta com um alto grau de especialização e conhecimento heurístico e cujo funcionamento se
processa de maneira isolada de outros sistemas,
stand alone
(REZENDE, 2003). A Figura 4.3
sintetiza as características destes sistemas no contexto dos Sistemas Inteligentes (SI).
70
SI
SBC
SE
Exibem comportamento inteligente.
Tornam explícito o domínio do conhecimento e
estão inseridos em um processo de Gestão.
Resolvem problemas
ordinários a um EH.
Figura 4.2 – Contextualização de SBC e SE dentro dos SI’s.
Fonte: REZENDE, 2003.
O sistema proposto neste trabalho auxilia a implantação da MCC, avaliando seus pré-
requisitos e auditando suas etapas, com foco na GC. Além do conhecimento heurístico dos EH’s
serão utilizados no processo de inferência o conhecimento explícito de manuais e normas. Portanto,
a partir deste ponto, o produto deste trabalho será tratado como um SBC. A base do SBC proposto é
um SE implementado com a s
hell
FuzzyClips e com uma interface desenvolvida em
Visual Basic
.
Os SE’s são concebidos para reproduzir o comportamento de EH’s na resolução de
problemas do mundo real, mas o domínio destes problemas é restrito, porém dentro de seu
domínio, o conhecimento armazenado deve estar no limite da perícia e, também, organizado de
forma a facilitar a consulta de soluções por um usuário não especialista. Com estas características
os SE’s não somente diferem dos sistemas de informação convencionais, que apenas facilitam a
obtenção e o armazenamento da informação, como também tornam-se úteis para a capacitação e o
ensino (LAUDON, 2002). A Figura 4.3 ilustra a estrutura de um SE.
Figura 4.3 – Arquitetura de um Sistema Especialista (SE).
Fonte: GIARRATANO e RILEY, 1998.
A base de conhecimento fornece as características funcionais do sistema. Este terá o
conhecimento que for inserido na sua base de conhecimento (RIBEIRO e CUNHA, 1987). Segundo
Fernandes (2003) a base de conhecimento é formada pelas regras e procedimentos que o EH utiliza
na solução de problemas. Este conhecimento é modelado no sistema, com auxílio de um EH ou
outras fontes, pelo EC, que o implementa de maneira própria à representação escolhida.
71
A memória operacional funciona como uma memória de curto prazo do sistema, pois
armazena os fatos, relativos ao problema apresentado pelo usuário, durante o processo de solução
do problema. Estes fatos podem ser adquiridos de diversas fontes tais como: sensores, respostas
via teclado, banco de dados, ou outros programas (GIARRATANO e RILEY, 1998).
A máquina de inferência funciona como um processador cognitivo que compara os dados
contidos na memória operacional com o conhecimento contido na base de conhecimento, para
extrair uma conclusão (DURKIN, 1994).
A máquina de inferência é a parte do SE que realmente processa o raciocínio e o planejamento
lógico. Quando a base de conhecimento é formada por regras, a máquina de inferência determina qual
condicional da regra, se existir alguma, é satisfeita por fatos que estejam na memória operacional e
adiciona a conclusão desta regra à memória operacional. Existem duas maneiras de implementar a
inferência, o encadeamento para frente (
forward chaining
) onde se inicia com uma evidência para se
chegar a uma conclusão e o encadeamento para trás (
backward chaining
) onde se inicia com uma
conclusão e procura-se uma evidência que a comprove. Também é possível, em um sistema, a
aplicação de ambos os métodos (FERNANDES, 2003).
A agenda é uma lista das regras priorizadas pela máquina de inferência, cujas condições
são satisfeitas pelos fatos ou objetos na memória operacional (GIARRATANO e RILEY, 1998).
Desta forma, a agenda armazena informações, fatos e estruturas de suporte ao funcionamento do
sistema, quando este efetua raciocínios/inferências.
O subsistema de aquisição de conhecimento é utilizado para introdução ou remoção de
conhecimentos da base de conhecimento (FERNANDES, 2003).
O subsistema de explicação é empregado para explicar ao usuário a linha de raciocínio
que o SE utilizou para chegar à conclusão. Esta característica permite solicitar ao sistema
informações adicionais, além de capacitá-lo para fins educacionais (FERNANDES, 2003).
A interface com o usuário estabelece um meio de comunicação entre o usuário e o sistema
(FERNANDES, 2003).
4.3 DIFERENÇAS ENTRE A ABORDAGEM ALGORÍTMICA E A HEURÍSTICA
Segundo Rezende (2003), a comunidade de IA tem atribuído algumas características
específicas a um SI para classificá-lo como um SBC ou em casos mais específicos um SE. Em
resumo, os SBC’s devem ser capazes de:
● Questionar o usuário, usando uma linguagem de fácil entendimento, para reunir as
informações de que necessita;
● Desenvolver uma linha de raciocínio a partir dessas informações e do conhecimento nele
embutido para encontrar soluções satisfatórias. Para isso, o SBC pode manipular regras e
informações incompletas, imprecisas e conflitantes;
● Explicar seu raciocínio, caso seja questionado pelo usuário, do porquê necessita de
informações externas e de como chegou às suas conclusões. Para tanto, o sistema deve
72
memorizar as inferências realizadas durante o processo de raciocínio, ser capaz de
interpretar esse processo e apresentá-lo de forma compreensível para o usuário do sistema;
● Assim como um EH, o SBC pode cometer erros, uma vez que sua base de conhecimento deriva
do EH. Portanto é de se esperar que as soluções apresentadas, para problemas complexos,
devam ser no mínimo equivalentes àquelas oferecidas pelo EH, quando este existir.
As características acima definem funcionalidades, contudo, não evidenciam as diferenças
fundamentais entre um sistema convencional e um SBC. Tentando evidenciar estas diferenças
Rezende (2003), esclarece que, em um SBC:
● Tudo que se sabe sobre o problema deve estar explicitamente representado na base de
conhecimento do sistema;
● A base de conhecimento deve ser usada por um agente capaz de interpretá-la (em outras
palavras, a representação necessita ser interpretada para possuir significado). Na terminologia
de SBC’s, esse agente é conhecido como o mecanismo ou máquina de inferência;
● Os problemas resolvidos por SBC’s são aqueles sobre os quais não é conhecido um
procedimento determinístico que garanta uma resolução efetiva (em termos de limitações de
tempo e recursos). Tipicamente, esses sistemas usam conhecimento específico do domínio
para contornar a exponencialidade da formulação genérica do problema e/ou a ausência de
conhecimento preciso e completo sobre o seu domínio.
Os dois primeiros itens dessa definição procuram tornar clara a distinção entre SBC’s e
sistemas convencionais, nos quais base de conhecimento e mecanismo de inferência são
freqüentemente misturados. Já o último item diferencia SBC’s de sistemas nos quais há
codificação explícita do conhecimento e a resolução de problemas se faz por meio de
procedimentos determinísticos. A Tabela 4.2 resume, as principais diferenças entre sistemas
convencionais e SBC, com base na bibliografia pesquisada.
Tabela 4.1 – Diferenças entre os Sistemas Convencionais e os SBC’s.
Fonte: GONZALEZ, 1993 - REZENDE, 2003 - WATERMAN, 1986.
Característica Programa Convencional SBC
Organização Representa dados Representa conhecimento
Como incorporam o
conhecimento
Dados e relações entre dados Conceitos, relações entre conceitos e regras
Técnica de execução
Tipicamente algoritmos
determinísticos
Busca heurística
Forma de controle
Conhecimento embutido no
código do programa
Conhecimento representado explicitamente e
separado do programa que o manipula e interpreta
Explicação Explicação do raciocínio é difícil Podem e devem explicar seu raciocínio
Modificação Difícil Fácil
Informações processadas Precisas Com incerteza
Saída Sempre correta Depende do problema e da base de conhecimento
Expansão Em saltos Incremental
73
4.4 PROCESSO DE DESENVOLVIMENTO DE UM SBC
Segundo Sommerville (2004), um processo de desenvolvimento de software pode ser definido
como um conjunto de atividades e resultados associados, que conduzem à produção de um produto de
software. São processos complexos e dependem do julgamento humano como em qualquer processo
intelectual. Por essa razão, existe uma grande diversidade de processos de desenvolvimento de
software, nenhum ideal, e que devem estar adequados às necessidades do desenvolvedor, incluindo a
opção por utilizar processos
ad-hoc
em vez de utilizar algum processo padronizado. No entanto, em
todo processo de software existem atividades fundamentais comuns como:
● Especificação: definição das funcionalidades e restrições de operação do software;
● Projeto e Implementação: concepção e codificação do software de acordo com as
especificações;
● Validação: avaliação de conformidade com os requisitos;
● Evolução: modificação do software para atender as novas exigências;
● Manutenção: correção de erros de sintaxe e/ou semântica (
bug
), ampliações da capacidade e
atualizações do software;
Essas atividades definem o que é chamado de ciclo de vida do software e podem ser
desenvolvidas de diferentes maneiras pelo engenheiro de software ou EC no caso de um SBC.
Segundo Sommerville (2004) e Pressman (2004) existem diversos modelos para desenvolvimento
de software. Os mais conhecidos são:
● Modelos seqüenciais: linear ou modelo em cascata ou ainda
waterfall
;
● Modelos evolucionários: incremental e espiral;
● Modelo de desenvolvimento baseado em componentes.
Este trabalho adotará o modelo evolucionário incremental, pois nele é possível que as
etapas do ciclo de desenvolvimento do SBC sejam seguidas utilizando apenas pequenas partes de
conhecimento em relação à totalidade do domínio do conhecimento, permitindo retornos às etapas
anteriores, caso seja constatado algum tipo de erro ou inadequação em alguma tomada de decisão
sobre o projeto do SBC, seguindo assim os conceitos de Engenharia Simultânea propostos por
Silva (1998). O Apêndice B deste trabalho descreve os demais modelos.
Os modelos evolucionários são modelos interativos cujo objetivo é o refinamento
sucessivo do software objetivando versões cada vez mais completas a partir de aplicações
sucessivas do modelo seqüencial linear. Ao final de cada interação uma versão do software é
produzida e avaliada, e novos requisitos e definições são levantados para iniciar um novo ciclo. O
processo é repetido até que o software esteja completo. Isto permite ciclos de realimentação com
informações advindas tanto por parte do EH como dos usuários, sendo, conseqüentemente mais
flexível permitindo mudanças de paradigma nas etapas do ciclo de desenvolvimento, conforme
seja exigido (SOMMERVILLE, 2004 e PRESSMAN, 2004).
74
Uma das diferenças entre o desenvolvimento de um programa computacional
convencional e um programa de SBC está na origem e quantidade de conhecimento a ser
pesquisado, que para os SBC’s dificilmente é totalmente conhecido mesmo para os EH’s, o que
dificulta a determinação do esforço total a ser despendido. Estas particularidades dos SBC’s
devem ser consideradas na escolha do seu modelo de desenvolvimento, sendo o incremental um
bom exemplo a ser seguido (GONZALEZ e DANKEL, 1993).
Segundo Gonzalez e Dankel (1993), as etapas do ciclo de vida, no desenvolvimento de
programas computacionais, utilizando o modelo incremental,
podem ser seguidas conforme a Figura
4.4. O conhecimento é, portanto, dividido em pequenas partes, que em conjunto formam a base de
conhecimento. Durante a formação da base de conhecimento, apesar desta não estar ainda concluída,
pode-se obter uma funcionalidade parcial com algumas limitações, ao contrário dos programas
convencionais que precisam estar totalmente concluídos para poderem ser utilizados e testados.
Figura 4.4 – Etapas de desenvolvimento de software utilizando o Modelo Incremental.
Fonte: GONZALES e DANKEL, 1993.
Etapa 6
Ajuste de Projeto
Etapa 7
Implementação
Etapa 8
Teste
Etapa 9
Manutenção
Etapa 1
Análise
Etapa 2
Especificação
Etapa 3
Projeto Preliminar
Etapa 4
Prototipagem
Etapa 5
Projeto Detalhado
Dentro da seqüência metodológica de desenvolvimento dos SBC’s, pelo modelo
incremental têm-se as seguintes características de cada uma das etapas de evolução do sistema,
com base na Figura 4.4 (GONZALEZ e DANKEL, 1993):
● Análise: nesta etapa são definidos o domínio do problema, que deverá ser plenamente
compreendido, e a adequação da técnica de SBC para este domínio, a análise pode ser
auxiliada pela Tabela 4.2. No caso específico deste trabalho o domínio da aplicação é a
MCC que devido à natureza e especificidade do conhecimento envolvido satisfaz de modo
pleno todos os critérios de análise propostos na referida tabela;
● Especificação: define as fronteiras do campo de aplicação e identifica as funcionalidades
desejadas no SBC. Quanto às fronteiras este trabalho abrange os fatores críticos da
implantação e auditoria da MCC. Quanto à funcionalidade o SBC proposto deve ponderar as
características do sistema/empresa e a partir de um processo de inferência
Fuzzy
avaliar os
fatores críticos que podem interferir na implantação e auditoria da MCC e propor soluções
ou regras de conduta para amenizar ou eliminar estes fatores críticos;
75
Tabela 4.2 – Critérios para Seleção de SBC’s.
Fonte: WATERMAN, 1986.
Possibilidade de
Desenvolvimento
Justificativa do
Desenvolvimento
Desenvolvimento do SBC é Apropriado
Tarefa não requer senso
comum
Custo com EH
grande
EH’s podem articular
seus métodos
Perda do EH
Existem EH’s EH raro
Natureza
Tarefa requer
manipulação simbólica
Tarefa requer solução
heurística
Há consenso entre EH’s Complexidade Tarefa não é trivial
Tarefa requer também
habilidades heurísticas
EH requerido em
vários locais
Todos os itens devem ser satisfeitos
A tarefa é plenamente
explorada e conhecida
Pelo menos 1 item deve ser satisfeito
Atuação do EH em
ambiente hostil
Todos os itens devem ser satisfeitos
Escopo
Tarefa tem valor prático
Tarefa é de proporção
gerencial
● Projeto Preliminar: define a maneira como o conhecimento é inserido na base de
conhecimento, escolha das ferramentas computacionais e do EH ou fontes de conhecimento
alternativas a serem consultadas. Neste caso a ferramenta de desenvolvimento do SBC
proposto é a
shell
FuzzyClips e as fontes de conhecimento especialistas na implantação da
MCC, literatura técnica e normas;
● Prototipagem Inicial: é a construção de um SBC, com limitações de robustez e abrangência
de atuação, porém com possibilidade de obter conclusões limitadas a base de conhecimento
inicial e as decisões tomadas na etapa de projeto preliminar. Nesta fase inicia-se a Aquisição
do Conhecimento (AC), incluindo sua identificação, conceituação e formalização para
posterior armazenamento na base de conhecimento. Neste ponto uma primeira versão do
SBC é concebida para testes e tomadas de decisão;
● Projeto Detalhado: faz a readequação das decisões tomadas na etapa de projeto preliminar,
fundamentada nos resultados da prototipagem inicial;
● Implementação: inicia-se nesta etapa o ciclo de desenvolvimento incremental. Nesta fase o
conhecimento adquirido deve ser representado formalmente. Concluída a representação
parte-se para o desenvolvimento da interface, documentação e geração dos manuais do SBC;
● Teste: objetiva ter o retorno do desempenho do SBC. Pode ser subdividida em: etapa de
verificação realizada pelo EC, e etapa de validação conduzida pelo EH e usuários do
sistema. Estas atividades são complementares e necessárias para avaliar e assegurar a
qualidade do SBC. Após a avaliação das características dinâmicas do SBC o sistema é
refinado, corrigindo algum conhecimento incorreto ou ausente no modelo executável;
● Ajustes de Projeto: visa realizar pequenos ajustes a partir do retomo das conclusões da etapa
de teste. Após esta etapa, inicia-se um novo ciclo de implementação e teste, que é conduzido
para cada parte de conhecimento a ser inserido no SBC;
● Manutenção de Software: atingidas as metas de abrangência da base de conhecimento, o
SBC é finalizado, e entra na etapa de manutenção que é realizada para correções de falhas
76
não identificadas durante a construção do SBC e atualizações ou expansões da base de
conhecimento para as novas configurações do domínio do problema.
O desenvolvimento dos SBC’s inicia-se realmente após o término das etapas iniciais
compreendidas entre a análise e o projeto detalhado que definem e justificam a sua aplicação,
especificando os requisitos do programa computacional e projetando o SBC. Conforme as etapas de
desenvolvimento incremental são percorridas, a base de conhecimento atinge a maturidade e a
capacidade de resolução de problemas cada vez mais complexos e com grande amplitude de
atuação. Devido a sua relevância, alguns dos componentes das etapas do ciclo de desenvolvimento
do SBC serão abordados com mais detalhes nos tópicos que seguem.
4.5 AQUISIÇÃO E ELICITAÇÃO DO CONHECIMENTO
Forsythie e Buchanan (1989) fazem uma diferenciação entre Aquisição e Elicitação ou
Extração do Conhecimento definindo que: a AC está relacionada com a coleta das informações a partir
de um ou mais especialistas ou através de outras fontes de conhecimento (livros, documentos, normas,
etc...) até a sua codificação de forma computacional, enquanto que a Elicitação ou Extração do
Conhecimento diz respeito às várias técnicas utilizadas na etapa de AC (entrevistas, teachback
3
,
análise de protocolo, etc...), Rezende (2003), também alerta que, estes termos não são sinônimos de
AC, mas sim um processo de interação entre um agente humano responsável por construir o SBC,
chamado de Engenheiro de Conhecimento (EC) e a fonte humana de conhecimento (o Especialista).
Entre as definições do termo Aquisição do Conhecimento (AC), na literatura, têm-se:
● Transferência e transformação da habilidade ou perícia para resolver problemas contidos em
alguma fonte de conhecimento para um programa computacional (GENARO, 1986);
● Processo de dispor, codificar e esmerar o conhecimento, o que pode requerer entrevistas
com especialistas, consultas a uma biblioteca ou introspecção. A pessoa que empreende a
AC deve converter o conhecimento adquirido de maneira que possa ser utilizado por um
programa de computador (HARMON, 1988).
A AC é referenciada por vários autores como um dos maiores obstáculos na construção de
SBC’s (GENARO, 1986; HART, 1992; GIARRATANO e RILEY, 1998; REZENDE, 2003).
Vários são os problemas que tornam a AC uma tarefa difícil. Existe a incompatibilidade de níveis
entre seres humanos e máquinas, ou seja, as máquinas exigem que o conhecimento seja expresso
explicitamente, porém, nem sempre o especialista está consciente da estrutura do seu próprio
conhecimento de maneira detalhada para que a máquina possa raciocinar (CLEAL, 1988). Outra
questão é a diferença que existe entre as regras que os especialistas declaram e as regras utilizadas
na prática quando resolvem um problema (HART, 1992).
3
A entrevista “
teachback
” consiste de uma conversação entre entrevistador e entrevistado até chegarem a um
consenso sobre o pensamento do entrevistado (ALIBERAS
et al
, 1996).
77
Para tornar mais efetivo o processo de AC, várias técnicas têm sido desenvolvidas para a etapa
de elicitação. Elas podem ser classificadas como manuais, semi-automáticas e automáticas. Nas
técnicas manuais, o EC é responsável por elicitar o conhecimento do especialista ou de outras fontes e
depois codificá-lo em uma base de conhecimento. Contudo, os problemas de comunicação entre o
grande número de agentes humanos envolvidos na tarefa (especialistas, EC e programadores) acabam
por introduzir ruídos semânticos no processo que podem comprometer a qualidade da base de
conhecimento. Uma alternativa que objetiva minimizar esses problemas é a elicitação automática ou
semi-automática, na qual se usa uma ferramenta computacional para auxiliar o EC, ou o próprio
especialista, a construir a base de conhecimento. Com o uso dessas ferramentas, além de reduzir o
número de agentes humanos envolvidos e, por conseqüência, os seus problemas de comunicação,
torna-se mais rápido o processo de construção da base de conhecimento. Isto, facilita para o EC ou
especialista obter respostas a respeito do comportamento do sistema e identificar possíveis
inadequações. Basicamente, as ferramentas de elicitação do conhecimento baseiam-se em algum tipo
de conhecimento ou técnica preexistente para apoiar o processo de aquisição (REZENDE, 2003).
4.5.1 Técnicas Manuais para Elicitação do Conhecimento
Este item apresenta as técnicas manuais de elicitação do conhecimento utilizadas neste
trabalho. O Apêndice B mostra outras técnicas, que também foram estudadas. Segundo Rezende
(2003) as técnicas manuais de elicitação do conhecimento podem ser classificadas e caracterizadas
como segue:
a)
Baseadas em Descrições
Esta abordagem exige que o EC estude e analise os textos de referência do domínio e produza
a base de conhecimento a partir deles. Existem vários problemas com esta abordagem, tais como:
inexistência de referências homologadas em um domínio e a necessidade de formação específica para
entender os textos de referência.
b)
Baseadas em Entrevistas
Envolvem um diálogo direto entre o EC e os especialistas. Esta abordagem não dispensa a
investigação bibliográfica, mas a utiliza para criar uma linguagem de senso comum entre especialista e
o EC. Existem diferentes tipos de entrevistas que podem ser utilizadas:
b1)
Entrevistas Não-Estruturadas
Devem ser feitas na fase de identificação, na qual o escopo e o foco da aplicação são
determinados. São conduzidas informalmente, economizando tempo e possibilitando ao EC conhecer
78
mais rapidamente a estrutura do domínio do problema. Por outro lado, segundo Rezende (2003),
dificilmente oferecem uma descrição completa e bem organizada do processo cognitivo do
especialista. Os produtos esperados das entrevistas não-estruturadas são o escopo, a lista de referências
e um glossário inicial.
b2)
Entrevista Estruturada
Identifica os elementos e as relações do domínio. É feita na fase de Prototipagem Inicial,
na qual é formulada a descrição do domínio. Esta abordagem se fundamenta em um processo
sistemático orientado a um objetivo que leva a uma comunicação organizada entre o EH e o EC.
Isso ajuda a evitar distorções decorrentes da subjetividade. As seguintes recomendações gerais
podem ser seguidas pelo entrevistador:
● Estudar o material disponível a respeito do assunto para fazer questionamentos que sejam
relevantes;
● Revisar as tarefas que o SBC terá de realizar;
● Escalonar formalmente e planejar a entrevista, usando formulários;
● Elaborar algumas amostras de perguntas antes da entrevista;
● Conscientizar o especialista dos objetivos e propósitos das entrevistas e instruí-lo a se
preparar com antecedência.
As entrevistas estruturadas têm a desvantagem de poder produzir resultados influenciados
pelo entrevistador e, portanto, devem ser planejadas e revistas cuidadosamente. Os produtos
esperados das entrevistas estruturadas são: um glossário robusto, um conjunto de casos a serem
estudados e uma descrição da tarefa, do domínio, e das limitações.
b3)
Acompanhamento de Casos
Feito o modelo de conhecimento a partir da análise do material das entrevistas e das
referências, alguns casos devem ser verificados e falhas na descrição do conhecimento,
detectadas. Esse processo de detecção de falhas e incompletudes no modelo, é realizado junto com
o especialista em entrevistas focadas em informações para preenchimento do modelo.
c)
Teachback
Teachback
é uma técnica utilizada para validar o conhecimento. Nesta técnica o EC explica
alguns conceitos da área ou faz a simulação de tarefas de uma área particular do conhecimento. A
técnica permite ao especialista acompanhar o raciocínio do EC sobre um determinado assunto.
Deve ser utilizada logo após as técnicas de entrevistas.
79
d) Técnica
Delphi
Delphi
é o nome dado para um conjunto de procedimentos para elicitar e refinar a opinião
de um grupo de pessoas, tipicamente um painel de especialistas, e foi desenvolvida por Norman
C. Dalkey e colaboradores na Rand Corporation (DALKEY, 1967). De maneira geral, o método
para aplicação da técnica
Delphi
consiste em: obter as respostas de cada participante às questões
pré-elaboradas, por meio de questionários ou outra forma de comunicação formalizada; fazer
iterações (uma ou mais) desses questionários, onde as informações colhidas em cada rodada são
controladas e resumidas pelo mediador e realimentada junto ao próximo questionário; e adotar
como a resposta do grupo uma estatística representativa das respostas finais (DALKEY, BROWN
e COCHRAN, 1969).
O Apêndice B mostra mais detalhes da Técnica
Delphi
.
4.5.2 Técnicas Automatizadas para Elicitação de Conhecimento
Diferente das técnicas manuais de
elicitação de conhecimento, que são altamente
dependentes da interação do EC com o especialista, e portanto, sujeitas a ruídos semânticos, existem
também, abordagens semi-automáticas e automáticas que oferecem parte ou toda a tarefa de aquisição
já implementada. Algumas abordagens são específicas do domínio e outras são específicas da tarefa.
Algumas enfatizam a interação com o EH, baseando-se em processos psicológicos de elicitação do
conhecimento. Outras enfatizam o reuso de componentes de conhecimento disponíveis em bibliotecas,
tais como ontologias e métodos de resolução de problemas (REZENDE, 2003).
O Apêndice B mostra algumas das técnicas automatizadas de uso corrente para a
concepção de SBC’s. Os próximos parágrafos mostram a técnica semi-automática baseada no
reuso da representação e dos mecanismos de inferência, a qual foi utilizada neste trabalho.
As primeiras ferramentas semi-automáticas de AC surgiram a partir da constatação de que a
forma de representação e o mecanismo de inferência, utilizados por um determinado SBC poderiam
ser reusados em aplicações similares em outros domínios. Por serem produzidas a partir de
abstrações sobre SBC’s já existentes, essas ferramentas ficaram conhecidas como
shells
para SBC’s.
As
shells
evoluíram a ponto de conterem mecanismos de busca e diversas formas de representação
do conhecimento prontas para serem configuradas. Com isso, o EC pode focar mais na tarefa de
modelagem e desvincular-se significativamente do esforço de implementação do mecanismo de
inferência atividade que antes do desenvolvimento das
shells
, consumia um tempo significativo,
porém indispensável para a etapa de representação do conhecimento (REZENDE, 2003).
Este trabalho utilizou a
shell
FuzzyClips para construção do SBC proposto. Esta decisão
reduziu consideravelmente o tempo de desenvolvimento do SBC permitindo uma passagem direta
da aquisição para a representação do conhecimento.
80
4.5.3 Considerações sobre Aquisição de Conhecimento (AC)
Segundo Rezende (2003) embora as ferramentas de aquisição semi-automáticas e
automáticas tenham suavizado o processo de AC, elas não eliminaram a dependência do EC. De
fato, ainda não existe uma ferramenta que tenha sido usada em escala comercial diretamente com
especialistas. Neste sentido, as abordagens automáticas vêm recebendo grande força, dado seu
potencial de investigação de registros existentes em larga escala e da liberação do EC.
As técnicas de elicitação do conhecimento não são mutuamente exclusivas, porém ainda
falta definir um mapeamento entre as diversas técnicas desenvolvidas e como elas podem ser
integradas para resolver os diferentes problemas de aquisição. Algumas metodologias traduzem
automaticamente o modelo de conhecimento para alguma linguagem de representação de
conhecimento, por exemplo, o Protege-II gera regras de produção para a
shell
CLIPS e JESS –
Java Expert System Shell
(REZENDE, 2003).
A área de AC também não se encontra plenamente estabilizada. No estágio atual, não foi
estabelecido um consenso sobre o ciclo de vida para o processo de AC com a definição de etapas,
dos produtos resultantes de cada etapa e dos métodos a serem utilizados em cada uma delas
(RUSSELL e NORVIG, 2004).
Neste trabalho a AC, para desenvolvimento do SBC-
Fuzzy
, não ficou restrita a um único
tipo ou fonte de conhecimento, foi incluído: conhecimento heurístico de EH’s (especialistas na
implantação da MCC), conhecimento procedural ou explícito de tabelas, diagramas, fluxogramas,
normas e livros. Os Capítulos 5 e 6 mostram mais detalhes do processo de AC utilizado.
4.6 REPRESENTAÇÃO DO CONHECIMENTO (RC)
A Representação do Conhecimento (RC) pode ser entendida como uma forma sistemática de
estruturar e codificar o que se sabe sobre uma determinada aplicação. Do ponto de vista da estrutura
de representação, o conhecimento pode ser considerado um conjunto de fragmentos que são
acessados pelo processo de inferência. A adequação heurística da estrutura de RC pode ser analisada
sob dois aspectos: em relação às propriedades dos fragmentos e em relação às propriedades da
estrutura (FERNANDES, 2003). Quanto à codificação, ao contrário de uma codificação qualquer ou
procedural, uma RC deve apresentar as seguintes características (BITTENCOURT, 2001):
● Ser compreensível ao ser humano, pois caso seja necessário avaliar o estado de conhecimento
do sistema, a RC deve permitir a sua interpretação;
● Abstrair-se dos detalhes de como funciona internamente o processador de conhecimento que a
interpretará;
● Ser robusta, isto é, permitir sua utilização mesmo que não aborde todas as situações possíveis;
81
● Ser generalizável, ao contrário do conhecimento em si que é individual. Uma representação
necessita de vários pontos de vista do mesmo conhecimento, de modo que possa ser atribuída
a diversas situações e interpretações.
Como propriedades dos fragmentos de conhecimento, cita-se (BITTENCOURT, 2001):
● Granularidade ou nível de detalhe do fragmento;
● Disponibilidade, pois os fragmentos do conhecimento podem ser explicitamente representados
ou não. Exemplos de conhecimento implícito são as heranças na programação que utilizam
modelagem orientada a objetos;
● Credibilidade que está associada ao grau de certeza destes fragmentos.
Como propriedade da estrutura, cita-se (BITTENCOURT, 2001):
● Modularidade que vai mostrar o quão fácil é adicionar ou modificar os fragmentos de
conhecimento.
Existem várias técnicas de RC e para avaliar essas técnicas existem alguns critérios, dos
quais os principais são (RICH, 1993):
● Adequação Lógica: observa se o formalismo usado é capaz de expressar o conhecimento do
domínio que se deseja representar;
● Conveniência Notacional: verifica as convenções da linguagem de representação. Se essas
forem muito complicadas, a tarefa de codificação torna-se extremamente complexa;
● Adequação Inferencial: capacidade de manipular as estruturas representacionais de modo a
derivar novas estruturas que correspondam a novos conhecimentos, inferidos a partir de
conhecimento antigos;
● Eficácia Inferencial: capacidade de incorporar à estrutura de conhecimento informações
adicionais que podem ser utilizadas para focalizar a atenção dos mecanismos de inferência nas
direções mais promissoras;
● Eficácia Aquisitiva: capacidade de adquirir um novo conhecimento de maneira facilitada. O
caso mais simples envolve a inserção direta, por um EH, na base de conhecimento. Idealmente
o próprio programa deveria ser capaz de controlar a AC diretamente do EH.
A RC é um dos problemas cruciais de IA, pois não existe uma teoria geral de RC.
Entretanto, se nenhum bom mapeamento puder ser definido a partir de um problema, então não
importa a competência do programa para solucionar problemas, ele não será capaz de produzir
respostas que correspondam as respostas reais para o problema. (RICH, 1993).
Muitas técnicas de RC têm sido estudadas pelos pesquisadores de IA. Nos itens seguintes
são apresentadas as técnicas de RC utilizadas neste trabalho. No Apêndice B são mostradas outras
técnicas de RC que foram estudadas durante a pesquisa bibliográfica para embasamento teórico
deste trabalho.
82
a) Regras de Produção
Os primeiros SBC’s foram sistemas baseados em regras. Esses sistemas se inspiraram na
idéia que o processo de tomada de decisão humano poderia ser modelado por meio de regras do tipo
{
SE
Condições
ENTÃO
Conclusões
FAÇA
Ações
}. Portanto, as regras podem expressar
relacionamentos lógicos e equivalências de definições para simular o raciocínio humano
(REZENDE, 2003).
A parte
SE de uma regra é uma lista de condições a serem satisfeitas, a parte ENTÃO é uma
lista de conclusões e
FAÇA são as ações a serem executadas. Cada uma das condições da lista é
verificada, e se todas forem satisfeitas, as conclusões são consideradas verdadeiras e as ações serão
executadas. Assim como outros esquemas de representação, as regras podem ser usadas para
justificar a conduta do sistema na busca da solução. Entre várias alternativas de RC, as regras
constituem uma forma natural de representar o conhecimento de um EH (REZENDE, 2003).
As grandes vantagens da regra são a naturalidade e a uniformidade. A regra é natural, pois é
a forma de representação que as pessoas e especialistas normalmente empregam no dia a dia, o que
as tomam fáceis de serem entendidas. Uniformes porque normalmente as regras são escritas
segundo um padrão, na forma de pares de expressão consistindo em uma condição e uma ação.
Como desvantagem tem-se a dificuldade de compreensão do fluxo de informações em um SBC.
Esta dificuldade pode ser contornada em algumas situações onde é possível separar as regras em
grupos (RICH, 1993).
b)
Orientação a Objetos
Segundo Rezende (2003), a orientação a objetos reúne características tanto das redes
semânticas quanto dos frames. Entretanto, neste trabalho, o estudo de frames e redes semânticas,
mostradas no Apêndice B, têm caráter eminentemente histórico e didático, visto que os SBC’s
contemporâneos vêm utilizando orientação a objetos em vez destas técnicas. Na orientação a
objetos a estratégia principal é representar o conhecimento como conjuntos completos de objetos
com comportamentos. Os objetos são definidos em classes hierarquicamente estruturadas, de
modo que níveis inferiores na estrutura acessam atributos e relacionamentos de níveis superiores
(REZENDE, 2003). A potencialidade da representação orientada a objeto está relacionada com
propriedades como abstração, encapsulamento, herança e polimorfismo, caracterizadas a seguir
(GONZALEZ e DANKEL, 1993):
● Abstração: ignora aspectos de algumas entidades, concentrando-se naqueles aspectos mais
relevantes para a resolução do problema corrente;
● Encapsulamento: separação dos aspectos externos de um objeto, acessíveis por outros, dos
detalhes internos da implementação que ficam ocultos dos demais. É usado no
83
desenvolvimento de uma estrutura global de programas, onde cada parte do programa deve
conter tarefas específicas, revelando tão pouco quanto possível, os detalhes internos;
● Herança: permite expressar características comuns possuídas por uma coleção de diferentes
classes de objetos em uma só vez;
● Polimorfismo: permite que uma mesma mensagem seja respondida por diferentes classes de
maneira própria de cada classe. Onde mensagem é uma solicitação ou comando enviado por
um objeto emissor para um objeto receptor para realização de um serviço ou processamento;
A flexibilidade na descrição é o ponto mais forte desta técnica de representação. Um
conjunto básico de objetos pode ser estabelecido e então ser utilizado na implementação de vários
sistemas através de modificações, de acordo com cada situação (REZENDE, 2003).
c)
Orientação a Objetos Associada a Regras de Produção
A orientação a objetos oferece uma representação estrutural concisa de relações estáticas,
mas não oferece facilidades diretas para descrever declarativamente como o conhecimento
armazenado deve ser utilizado. Essa deficiência da representação orientada a objetos pode ser
tratada com sucesso por meio do uso de regras de produção. Por isso, está cada vez mais
difundido o uso de regras de produção combinadas com orientação a objetos, de maneira a
explorar as vantagens que as duas representações oferecem (REZENDE, 2003).
Segundo Rezende (2003), enquanto a orientação a objetos oferece uma forma rica, simples e
natural para expressar os objetos do domínio, suas relações e a forma de comportamento, as regras
de produção oferecem um meio simples e natural de expressar o processo de raciocínio do sistema.
4.6.1 Considerações sobre Representação de Conhecimento (RC)
A RC consiste nos caminhos que podem ser trilhados para codificar o conhecimento em
um programa computacional. A bibliografia estudada revela que, a técnica de RC mais adequada
depende do tipo do problema e da área na qual o SBC está sendo usado, não havendo uma regra
geral de representação que atenda a todas as situações.
Entretanto cabe ressaltar que, sistemas baseados em um único formalismo de RC (em
particular regras de produção) limitam o tipo de informação que pode ser representado e tendem a
ficarem ineficientes à medida que cresce a quantidade e os tipos de informações que precisam ser
armazenadas. Assim, SBC’s híbridos podem ser encarados como uma solução adequada, pois
combinam as vantagens dos formalismos por eles utilizados.
Neste trabalho se utilizou a orientação a objetos associada a regras de produção, com
auxílio da
shell
FuzzyClips, os Capítulos 5 e 6 mostram mais detalhes deste processo.
84
4.7 VERIFICAÇÃO E VALIDAÇÃO DE SBC
Segundo Gonzalez e Dankel (1993), os termos verificação e validação estão relacionados
à qualidade de software. Neste sentido Smith e Kandel (1993) afirmam que a maioria das
exigências para um software convencional definidas na ISO/IEC 9126 ou na NBR 13596, aplica-
se também aos SBC’s, principalmente no tocante à interface com o usuário e à máquina de
inferência, que podem ser tratados como softwares convencionais. Entretanto, muitos aspectos da
qualidade do software, presentes nas referidas normas, não foram especificados para SBC’s. Um
aspecto único dos SBC’s é a capacidade de emular um EH. Assim, uma especificação da
qualidade para os SBC’s é a habilidade do SBC de equiparar-se ao desempenho de um EH. Uma
outra característica original dos SBC’s é a separação do conhecimento e do controle, onde: o
conhecimento reside na base de conhecimento e o controle na máquina de inferência. A máquina
de inferência pode ser considerada um software algorítmico, portanto, as definições da qualidade
para o software convencional se aplicam a ela. Já a base de conhecimento não segue o mesmo
raciocínio, de fato, a qualidade de um SBC é igualada freqüentemente com a qualidade do
conhecimento armazenado na base de conhecimento.
A verificação examina o cumprimento do SBC aos requisitos de projeto, verificando se o que
o mesmo executa está de acordo com as especificações do sistema. As atividades de verificação são
executadas normalmente pelo EC, e envolvem os seguintes itens (GIARRATANO e RILEY, 1998):
● Verificar se o adequado paradigma de RC foi implementado e se o mesmo está livre de erros
de semântica;
● Verificar a funcionalidade da tomada de decisão do SBC, examinando a máquina de
inferência e o processo de raciocínio do sistema, avaliando não somente a conformidade dos
resultados intermediários e finais, mas também se o SBC está usando o processo correto de
encadeamento ao determinar os resultados corretos;
● O projeto e a implementação foram modulares;
● O sistema tem uma interface apropriada com outros sistemas;
● A interface do usuário corresponde às especificações;
● A forma de explicação foi apropriada ao usuário;
● Os requisitos de tempo de execução do sistema foram satisfeitos;
● O sistema tem manutenção conforme o grau especificado;
● O sistema satisfaz as especificações de segurança;
● Foram adotadas medidas de segurança para proteger que a base de conhecimento seja
modificada sem autorização;
● Verificar as regras quanto aos erros de sintaxe, e neste caso investigar:
→ Regras Redundantes: duas regras são redundantes se elas possuem premissas idênticas e
levam a conclusões idênticas sintaticamente ou em significado;
85
→ Regras Conflitantes: quando a premissa de duas regras é idêntica, porém suas conclusões
são conflitantes;
→ Regras Incluídas: uma regra é incluída por outra se esta tem mais restrições condicionais
para conclusões idênticas;
→ Regras Circulares: conjunto de regras que apresentam um encadeamento entre si
formando
loops
;
→ Condicionais Desnecessárias: quando duas regras com conclusões idênticas têm quase as
mesmas premissas;
→ Regra sem Saída (
Dead end Rules
): no encadeamento direto, estas são regras cujas ações não
afetam qualquer conclusão e não são usadas por outras regras para gerar outras conclusões;
→ Regras "Perdidas": são caracterizadas por fatos que não são usados no processo de
inferência, conclusões não afetadas por qualquer outra regra ou função, ou falhas em cobrir
todos os possíveis valores das entradas;
→ Regras Inatingíveis: no sistema de encadeamento direto, este tipo de regra indica que
suas premissas jamais serão satisfeitas, ou pela ausência de certas regras ou pela falta de
dados de entrada. Isto é equivalente a uma "regra sem-saída" no sistema de
encadeamento reverso.
Segundo Smith e Kandel (1993) a verificação é realizada utilizando-se a análise estática e
dinâmica. A análise estática não envolve a execução do SBC, e é utilizada, por exemplo, para
verificar a base de conhecimento, manualmente ou utilizando alguma ferramenta automática, a
fim determinar a exatidão, consistência e a integralidade do conhecimento. A análise dinâmica
envolve a execução do SBC, e é utilizada, por exemplo, para determinar se o SBC está
produzindo as respostas corretas e se está usando o processo correto de inferência.
A validação determina a eficácia do sistema final com relação às necessidades do usuário
final e ao mesmo tempo avalia se o SBC executa a tarefa desejada com um nível suficiente da
perícia. A validação analisa as exigências explícitas e implícitas do sistema. As exigências
explícitas são aquelas definidas na fase de planejamento e especificação do SBC, e que
necessitam ser confirmadas e testadas. Nesta etapa valem os preceitos das normas para softwares
convencionais ISO/IEC 9126 ou NBR 13596. As exigências implícitas analisam a habilidade do
SBC se equiparar a um EH na resolução de suas tarefas, estas características são únicas dos SBC’s
e não são válidos os preceitos das normas para softwares convencionais. Nesta etapa, utilizando-
se da análise dinâmica, as respostas do SBC são confrontadas com as respostas do EH ou com
soluções de casos anteriores, buscando ratificar a acurácia do SBC (SMITH e KANDEL, 1993).
O processo de verificação e validação do SBC-
Fuzzy
desenvolvido neste trabalho está
detalhado no Capítulo 8.
86
4.8 TRATAMENTO DE INCERTEZAS
O tratamento de incertezas se justifica nos estudos de SBC’s, pois os domínios adequados
à sua implementação se caracterizam exatamente por não serem modelados por nenhuma teoria
geral, o que implica em descrições incompletas, inexatas ou incertas (FERNANDES, 2003).
As fontes de incerteza possíveis em um SBC podem ser causadas por problemas nos dados,
por exemplo: dados ausentes ou não disponíveis, dados disponíveis porém não confiáveis ou
ambíguos, a representação dos dados pode ser imprecisa ou inconsistente, os dados podem ser
baseados em valores
default
e tais valores podem ter exceções ou os dados podem apenas
representar a melhor suposição do EH, baseado em associações plausíveis ou estatísticas que o EH
observou, podendo não ser apropriado em todas as situações. Além dos dados de entrada, a incerteza
pode estar presente na solução do problema ou em ambos (GONZALEZ e DANKEL, 1993).
Considerando estas várias fontes de erro, a maioria dos SBC’s requer a incorporação de
alguma forma de representação de incerteza nas entradas e no processo de inferência quando
aplicado a domínios com a presença de incerteza. Ao se implementar uma técnica para tratamento
de incerteza, devem-se considerar três questões principais (GONZALEZ e DANKEL, 1993):
● Como representar dados incertos;
● Como combinar dois ou mais dados incertos;
● Como gerar inferência usando-se dados incertos.
Existem, basicamente, dois métodos de representação de incertezas: o simbólico e o
numérico. O método simbólico trata incertezas através de regras de inferência que representam as
exceções no raciocínio do EH e, portanto é viável para trabalhar com uma pequena quantidade de
exceções. Os métodos numéricos atribuem aos fatos e regras uma medida numérica que represente
de alguma forma a “confiança” do especialista. Uma característica freqüente desses métodos é a
existência de um limite mínimo para a medida de incerteza, abaixo do qual o fato ou regra é
desconsiderado. Este limite pode, em geral, ser fixado pelo usuário (NASSAR, 2004).
4.8.1 Tratamento das Incertezas do Processo de Implantação da MCC
Este trabalho utiliza, para representação da incerteza, métodos numéricos fundamentados
na Teoria dos Conjuntos Difusos (
Fuzzy Set
), uma vez que, a incerteza presente na estruturação
do conhecimentto inerente à implementação e auditoria da MCC é por imprecisão ou de natureza
léxica. Outras razões que justificam esta escolha são:
● A comunicação com o usuário deve ser a mais apropriada e natural possível para refletir
os termos e incertezas do processo de implantação da MCC. Isto sugere a utilização de
variáveis linguísticas, as quais, podem ser formalmente tratadas com a lógica
Fuzzy
;
87
● A base de conhecimento de um SBC é um repositório de conhecimento humano e, sendo
este impreciso por natureza, é comum a presença de incompletudes tanto nas regras
quanto nos fatos. Os conjuntos
Fuzzy
representam uma maneira formal e coerente para
tratar estas incompletudes do conhecimento humano;
● A incerteza da informação na base de conhecimento requer que a máquina de inferência
disponha de ferramentas para tratamento desta incerteza. Este tratamento deve transmitir a
incerteza das premissas para as conclusões e associar às conclusões alguma medida de
incerteza apropriada e compreensível pelo usuário. A lógica
Fuzzy
e mais especificamente
a
shell
FuzzyClips, adotada neste trabalho, permitem este tratamento;
● Ao contrário da lógica clássica, onde uma proposição só pode assumir o valor Verdadeiro
(1) ou Falso (0), na lógica
Fuzzy
existem também valores intermediários de verdade
dentro de um conjunto finito ou infinito entre 0 e 1. Este conceito está mais próximo do
processo decisório humano.
Os próximos itens apresentam os conceitos da lógica
Fuzzy
, os quais subsidiaram o SBC-
Fuzzy
desenvolvido.
4.9 LÓGICA
FUZZY
A expressão lógica
Fuzzy
foi mencionada pela primeira vez em 1965 pelo engenheiro
eletrônico Lotfi Asker Zadeh, professor de Teoria dos Sistemas na Universidade de Berkeley que
desenvolveu, na década de 60, a Teoria dos Conjuntos
Fuzz
y e na década de 70 propôs sua
extensão com o conceito de Variável Lingüística (CAMPOS, 2004).
A lógica
Fuzzy
representa a incerteza por imprecisão, isto é trabalha com conjuntos com
limites imprecisos. Sendo uma extensão da lógica clássica, a lógica
Fuzzy
é utilizada para
representar termos lingüisticamente imprecisos (Ex.: ruim, bom, ótimo). Na lógica clássica, com
base na teoria clássica dos conjuntos, um elemento pertence ou não ao conjunto, enquanto, na
lógica
Fuzzy
um elemento possui um grau de pertinência ao conjunto, que varia de 0 a 1, este
grau é obtido por meio da função de pertinência que representa o conjunto (NASSAR, 2004).
4.9.1 Conjuntos
Fuzzy
– Definições
Na teoria clássica dos conjuntos, se um elemento
x
do universo de discurso
U
, pertence a
um dado conjunto
A,
então este elemento satisfaz um predicado associado a este conjunto. Pode-se
então definir este conjunto por meio de uma função, chamada de função característica, mapeada por
que associa a cada elemento do universo de discurso
U
um binário:
{
1,0→:γ
Α
Ux
)(
}
4.1
=)(
A
x
∈ x se 0
A∈ x se 1
γ
Α
88
A propriedade fundamental da lógica
Fuzzy,
proposta por Zadeh, tem uma caracterização
mais ampla, generalizando a função característica de modo que ela pode assumir um número
infinito de valores no intervalo {0,1}. Um conjunto
Fuzzy
é completamente caracterizado por seu
vetor de pertinência, com os graus de pertinência individuais multivalentes dentro do intervalo
numérico {0,1}. Esses graus de pertinências podem ser considerados como medidas que
expressam a possibilidade de um dado elemento ser membro de um conjunto
Fuzzy
.
Se
U
é o universo que contém os elementos denotados genericamente por
x,
então o
conjunto
Fuzzy A
em
U,
é o conjunto de pares ordenados:
{}
UxxxA
A
∈∀,),(μ=
4.2
Onde: é uma função real, dita função de pertinência, mapeada por
, que associa a cada um número real , no
intervalo . Este número real representa o grau de pertinência de
x
em
A
.
)(μ
x
A
]1,0[→:)(μ
Ux
A
Ux
∈
)(μ
x
A
]1,0[
A seguinte terminologia descreve um conjunto
Fuzzy
(Figura 4.5):
● Núcleo: região do universo de discurso caracterizada por ter uma pertinência total ao
conjunto
Fuzzy
, .
Núcleoxx
∈∀,1)(μ =
● Suporte: região do universo de discurso caracterizada por ter uma pertinência ao conjunto
Fuzzy
diferente de zero, .
Suportexx
∈∀,0≠)(μ
● Limite: região do universo de discurso caracterizada por ter uma pertinência ao conjunto
Fuzzy
entre 0 e 1, .
Limitexx
∈∀,1)(μ0 <<
Figura 4.5 – Núcleo, Suporte e Limites de um Conjunto
Fuzzy
.
Limite Limite
Núcleo
μ
Suporte
U
Sejam
A
e
B
conjuntos
Fuzzy
em um universo
U
, então :
Ux
∈∀
● A é um conjunto vazio
Φ
=
A
, se e somente se ;
0)(μ =
x
A
●
A
é um conjunto complemento de A , se e somente se
UxxAxA
∈∀−= ),(1)(
μμ
;
● Os conjuntos A e B são iguais , se e somente se ; )(
BA
=
)(μ)(μ
xx
BA
=
● O conjunto A é um subconjunto de B , se e somente se . )⊂(
BA
)(μ)(μ
xx
BA
<
Um subconjunto de um conjunto
Fuzzy A
de pontos
x
de
U
tal que é
denominado de conjunto suporte,
S(A)
, do conjunto
Fuzzy
A.
Um conjunto
Fuzzy
cujo conjunto
0)(μ >
x
A
89
suporte é um único ponto
x
de
U
com é chamado de conjunto Unitário
Fuzzy
ou
Singular (
Singleton
).
1)(μ =
x
A
Dado um conjunto
Fuzzy A
definido em
U
e qualquer número , o
α-cut A(α)
e o
α-cut-forte A(α+)
são os conjuntos clássicos (
crisp
)
definidos da seguinte forma:
]1,0[∈α
}α)(|{)α(
}α≥)(|{)α(
>=+
=
xAxA
xAxA
4.3
4.9.2 Propriedades dos Conjuntos
Fuzzy
Sendo
A
,
B
e
C
conjuntos
Fuzzy
do universo de discurso
U
, as propriedades, mostradas na
Tabela 4.3 são válidas:
Tabela 4.3 – Propriedades dos Conjuntos
Fuzzy
.
Fonte: REZENDE, 2003.
Propriedade Comutativa
A
B
B
A
∪∪ =
e
A
B
B
A
∩∩ =
Propriedade Associativa
)∪(∪∪)∪(
CBACBA
=
e
)∩(∩∩)∩(
CBACBA
=
Idempotência
A
A
A
=∪
e
A
A
A
=∩
Distributividade em relação à União
)∪(∩)∪()∩(∪
CABACBA
=
Distributividade em relação à Intersecção
)∩(∪)∩()∪(∩
CABACBA
=
Conjunto
Fuzzy
e seu Complemento
UA
≠A∪
e
φ≠A∩
A
Conjunto
Fuzzy
e o Conjunto Nulo
AA
=φ∪
e
φφ∩ =
A
Conjunto
Fuzzy
e o Conjunto Universo
UA
=U∪
e
AA
=U∩
Involução
A
=A
e
Teorema de Morgan
B∪AB)∪(A = B∩AB)∩(A =
4.9.3 Operações
Fuzzy
Conforme Shaw e Simões (2002), as operações entre conjuntos, pertencentes a universos de
discurso diferentes, possibilitam a construção da base de conhecimento de um sistema. Esses
mapeamentos ocorrem entre os conjuntos da variável de entrada , e o conjunto da
variável de saída
através da expressão condicional de inferência:
, que é a ligação do antecedente ou condição, definido pelo conjunto
A
caracterizado por seu vetor de pertinência, , com o conseqüente ou resultado da
ação, definido pelo conjunto
B
caracterizado pelo seu vetor de pertinência, . Os
próximos itens mostram as operações entre conjuntos
Fuzzy
utilizadas neste trabalho.
UxxA
∈),(
VyyB
∈),(
B(y)A(x) EntãoB ou Se A
⇒
Uxx
A
∈),(μ
Vyy
B
∈),(μ
Complemento:
O complemento de um conjunto
Fuzzy A
normalizado, correspondente ao conectivo
)(
xA
μ
A ANÃO, normalmente é denotado por . A função de pertinência deste conjunto , , em
um universo
U
é definida por:
UxxAxA
∈∀−= ),(1)(
μμ
.
90
Interseção:
A interseção entre dois conjuntos
Fuzzy A
e
B
do universo de discurso
U
corresponde ao
conectivo
BAC
∩
=
E, e pode ser representada por , com
C
do mesmo universo de discurso
U.
A
função de pertinência
BAC
∩
=
)(
x
C
μ
da interseção , proposta por Zadeh, é definida por:
Uxxxxx
BABAC
∈
∀==
∩
)}(),(min{)()(
μ
μ
μ
μ
.
União:
A união de dois conjuntos
Fuzzy A
e
B
do universo de discurso
U
corresponde ao
conectivo
BAC
∪
=
OU, e pode ser representada por , com
C
do mesmo universo de discurso
U.
A função de pertinência
BAC
∪
=
)(
x
C
μ
da união , proposta por Zadeh, é definida por:
Uxxxxx
BABAC
∈
∀==
∪
)}(),(max{)()(
μ
μ
μ
μ
.
A Figura 4.6 mostra graficamente as operações complemento, interseção e união dos
conjuntos
Fuzzy
A e B em U = [ 0 , 10 ] e as respectivas funções de pertinência.
0 1 2 3 4 5 6 7 8 9 10
1
0,8
0,6
0,4
0,2
μ
B
(
x
)
B
U
1
0,8
0,6
0,4
0,2
0 1 2 3 4 5 6 7 8 9 10
μ
A
(
x
)
A
U
1
0,8
0,6
0,4
0,2
0 1 2 3 4 5 6 7 8 9 10
A
U
(x)Aμ
1
0,8
0,6
0,4
0,2
μ
A
∪
B
(
x
)
0 1 2 3 4 5 6 7 8 9 10
A
U
B
1
0,8
0,6
0,4
0,2
0 1 2 3 4 5 6 7 8 9 10
U
μ
A
∩
B
(
x
)
A
B
Complemento de A =
A
Interseção de A e B =
B
A
∩
União de A e B =
B
A
∪
Figura 4.6 – Operações Complemento, Interseção e União de Conjuntos
Fuzzy
.
4.9.4 Variáveis Lingüísticas
O conceito da variável lingüística foi considerado por Cox (1994) como sendo a essência
da técnica de modelagem
Fuzzy.
Uma variável lingüística pode ser considerada como sendo o
nome dado a um conjunto
Fuzzy
. As variáveis lingüísticas representam de modo impreciso,
conceitos de variáveis de um dado problema, admitindo como valores somente expressões
lingüísticas, também chamadas de termos primários. Uma variável lingüística pode ter seu termo
primário representado por um conjunto
Fuzzy
existente no universo de discurso em que esta
variável está definida. Deste modo, a cada conjunto
Fuzzy
deste universo de discurso é associado
um conceito lingüístico que classifica ou define um valor lingüístico para a variável
Fuzzy
em
91
questão. A estrutura de conhecimento, ou participação
Fuzzy
de uma variável lingüística é
definida pelos termos primários desta variável. O quanto um dado elemento
i
, do universo de
discurso
U
, satisfaz o conceito representado por um conjunto
Fuzzy A
, é definido pelo valor da
função de pertinência (Figura 4.7).
x
Uxx
iiA
∈∀),(μ
São as propriedades sintáticas e semânticas que regem o comportamento do sistema de
conhecimento
Fuzzy
. Elas definem a forma de utilização das variáveis lingüísticas. As
propriedades sintáticas definem a forma com que as informações lingüísticas
Fuzzy
são
armazenadas, proporcionando a criação de uma base de conhecimento com sentenças
devidamente estruturadas. Estas propriedades sistematizam os processos de armazenamento,
buscando e processando os dados existentes. Por sua vez, as propriedades semânticas são as
responsáveis pela especificação do modo como é extraído e processado o conhecimento, contido
na estrutura definida pelas propriedades sintáticas, armazenado na forma de declarações
condicionais
Fuzzy
, ou regras de produção
Fuzzy
.
Figura 4.7 – Partição de Conjuntos
Fuzzy
.
Quesito / Critério ou Eta
p
a sob Análise
Ruim Baixa Boa Alta Ótima
1 2 3 4 5 6 7 8 9 10
μ
1
Variável Lingüística
Termo Primário
Função de Pertinência
Universo de Discurso
Partições do
Universo de Discurso
4.9.5 Modificadores Lingüísticos
Fuzzy
Associados aos termos primários das variáveis lingüísticas os modificadores são
operações que alteram a forma das funções de pertinência, introduzindo um novo significado ao
conjunto original, criando um conjunto
Fuzzy
composto. Os modificadores podem alterar tanto o
suporte (por espalhamento ou deslocamento) quanto o núcleo do conjunto
Fuzzy
original (YEN e
LANGARI, 1998). Os principais modificadores utilizados neste trabalho e que estão disponíveis
na
shell
FuzzyClips são mostrados na Figura 4.8.
A
Figura 4.8 – Modificadores Lingüísticos do FuzzyClips.
Função de Pertinência Inicial
Função de Pertinência Inicial com Modificador
More-or-Less
Função de Pertinência Inicial com Modificador
Extremely
Nome do Modificador Ação
Not
Não
Uxx
iiA
∈∀− ),(1
μ
Somewhat
Um Pouco
Uxx
iiA
∈∀),(
3
1
μ
More-or-Less
Mais ou Menos
Uxx
iiA
∈∀),(
5,0
μ
Very
Muito
Uxx
iiA
∈∀),(
2
μ
Extremely
Extremamente
Uxx
iiA
∈∀),(
3
μ
0
0,1
0,2
0,3
0,4
0,5
0,6
0,7
0,8
0,9
1
02468101214161820
)(
x
A
μ
92
4.9.6 Regras de Produção
Fuzzy
O modo mais comum de armazenar informações em uma base de conhecimento
Fuzzy
,
conforme Rezende (2003) é a representação por meio de regras de produção
Fuzzy
. As regras de
produção
Fuzzy
normalmente são compostas de duas partes principais, mostradas abaixo de três
formas equivalentes:
SE {
situação
} ENTÃO {
ação
}
⇔
SE {
x é A
} ENTÃO {
y é B
}
Variável
Lingüística de
Entrada
Termo
Primário de
Entrada
Variável
Lingüística de
Saída
Termo
Primário de
Saída
SE é ENTÃO é
4.4
A parte
SE da regra (antecedente) descreve a
situação
, para a qual ela é designada e a
parte
ENTÃO (conseqüente) descreve a
ação
do sistema
Fuzzy
nesta
situação
. A
situação
compõe
um conjunto de condições que, quando satisfeitas, mesmo parcialmente, determinam o
processamento da
ação
, através de um mecanismo de inferência
Fuzzy,
ou seja, dispara uma regra.
Por sua vez, a
ação
compõe um conjunto de diagnósticos que são gerados com o disparo da regra.
As
ações
das regras disparadas são processadas em conjunto e geram uma resposta quantitativa
para cada variável de saída do sistema.
A modelagem baseada em regras difusas tem como ponto central a definição e a
verificação de um sistema de regras. A definição das regras é o procedimento em que o
conhecimento e/ou os dados disponíveis são transcritos em regras. Neste processo, quatro
situações distintas podem ocorrer (BÁRDOSSY e DUCKSTEIN, 1995):
1. As regras são bem conhecidas pelos especialistas e podem ser descritas diretamente;
2. As regras podem ser definidas por especialistas, mas os dados disponíveis devem ser
utilizados para atualizá-las;
3. As regras não são conhecidas explicitamente, mas as variáveis requeridas para a descrição
do sistema podem ser especificadas por especialistas;
4. Somente um conjunto de observações está disponível, e um sistema de regras tem de ser
definido de forma a descrever as interconexões entre os elementos desse conjunto de dados.
Excetuando-se a primeira situação, em que as regras são definidas unicamente através do
conhecimento de especialistas, nas demais, um sistema parametrizado de regras deve ser
inicialmente definido. Posteriormente, este sistema deve ser validado com base num conjunto de
dados contendo valores para as variáveis de entrada e de saída, buscando representar, da melhor
forma possível, segundo algum critério especificado, a relação entrada/saída desejada. O modelo
assim obtido deve representar bem a relação contida no conjunto de dados para o qual foi
validado. Entretanto, o modelo será realmente válido quando representar bem a relação contida
93
em qualquer conjunto de dados que lhe seja apresentado. O processo de modelagem baseada em
regras
Fuzzy
, portanto, é um processo iterativo que envolve, geralmente, três etapas: identificação
do modelo; treinamento ou ajuste das regras; e, validação do modelo.
A identificação de um sistema inicial de regras é um processo subjetivo que requer, tanto
quanto possível, conhecimento sobre o sistema a ser modelado. Em geral, o processo de
identificação de um sistema de regras envolve as seguintes tarefas interdependentes: seleção de
variáveis; partição de domínios; atribuição de funções de pertinência e termos lingüísticos; e,
descrição das regras.
O treinamento ou ajuste das regras é a etapa em que os parâmetros das funções de
pertinência associadas aos termos lingüísticos são ajustados com base num conjunto de dados,
denominado conjunto de treinamento. Por mais criteriosas que tenham sido a seleção das variáveis
e a escolha das funções de pertinência, raramente, o sistema de regras inicialmente definido
representará bem a relação entre as variáveis de entrada e de saída do sistema. O ajuste dos
parâmetros é, em geral, a tarefa que consome mais tempo no processo de modelagem, por
envolver um processo de tentativa e erro, em que o conjunto de regras é sistematicamente inferido
com base nos valores dados para as variáveis de entrada e os resultados desta inferência são
comparados aos valores dados para as variáveis de saída.
A validação é o processo em que o modelo é avaliado quanto ao seu desempenho em
termos de eficiência e eficácia computacional. A eficiência computacional depende,
fundamentalmente, da simplicidade do modelo. A eficácia está relacionada com a capacidade do
modelo em reproduzir as saídas desejadas, quando um conjunto de dados distinto do conjunto
para o qual o modelo foi treinado lhe é apresentado. Diz-se que, neste processo, se está avaliando
a capacidade de generalização do modelo. O conjunto de dados utilizado é comumente
denominado conjunto de validação.
4.9.7 O Processo de Inferência
Fuzzy
Dada uma base de conhecimento
Fuzzy
representativa de um sistema (neste caso dos fatores
críticos para implantação da MCC), e um vetor de entradas
crisp
, pode-se definir Inferência
Fuzzy
como: o processo pelo qual obtemos as conclusões ou saídas de tal sistema, pela avaliação dos
níveis de compatibilidade das entradas com as condições impostas pela referida base de
conhecimento (regras). O conjunto
Fuzzy
resultante (conclusão) pode ou não, de acordo com a
necessidade, ser convertido para um escalar chamado de valor condensado ou
desfuzzyficado
. O
processamento dos antecedentes
,
os indicadores de disparos das regras e os operadores utilizados
em um sistema de conhecimento
Fuzzy
são definidos, de acordo com a semântica, pelo mecanismo
de inferência. Desta forma, então, é executado o processamento de conhecimento.
Mamdani (1975) propôs um método de inferência que foi por muitos anos um padrão para
a utilização dos conceitos da lógica
Fuzzy
em processamento de conhecimento. As regras de
94
produção em um modelo de Mamdani possuem relações
Fuzzy
tanto em seus antecedentes
como
em seus conseqüentes
.
O modelo de Mamdani possui módulos de interface que transformam as
variáveis de entrada baseadas em grandezas numéricas (
crisp
), em conjuntos
Fuzzy
equivalentes
e, posteriormente, as variáveis
Fuzzy
geradas em variáveis numéricas (
crisp
) proporcionais. A
Figura 4.9 apresenta um diagrama do modelo de inferência
Fuzzy
de Mamdani, o qual será
utilizado neste trabalho. Os dados provenientes da interface com o usuário são
fuzzyficados
no
módulo de conversão Escalar →
Fuzzy
, a máquina de inferência recebe estes dados e processa as
regras existentes na base de conhecimento gerando, a partir da composição de todas as regras
disparadas, um conjunto
Fuzzy
de saída para o módulo de conversão
Fuzzy
→ Escalar que
desfuzzyfica
os resultados do processo de inferência, para posterior apresentação ao usuário. Uma
regra é disparada quando o processamento dos antecedentes para as entradas atuais gera graus de
pertinência maiores que zero. O Capítulo 6 explicita melhor este processo.
Figura 4.9 – Diagrama Típico de um Modelo de Inferência de Mamdani.
Fonte: adaptado de REZENDE, 2003.
No modelo de inferência
Fuzzy
de Mamdani, a regra semântica tradicionalmente usada
para o processamento de inferência é denominada de
Máx-Min
, a qual, segundo Rezende (2003),
utiliza as operações de união e interseção entre conjuntos da mesma forma que Zadeh, por meio
de operadores de máximo e mínimo, respectivamente. Os próximos parágrafos ilustram este
processo.
Seja a seguinte regra de produção
Fuzzy
genérica:
SE {(x é A
1 i,1
) ⊗ (x é A
2 i,2
) ⊗...⊗ (x
k
é A )} ENTÃO {(y é B
i,k 1 i,1
) ⊗...⊗ (y
m
é B
i,m
)} 4.5
Onde:
• – É o número de termos primários de cada variável lingüística utilizada;
n 1,..., i =
• x
1
...x
k
– São as variáveis lingüísticas de entradas do sistema;
• A ... A
i,1 i,k
– São os termos primários definidos nas partições
Fuzzy
de cada variável de
entrada, definidos por funções de pertinência μ
;
Ai,k
• y
1
...y
m
– São as variáveis lingüísticas de saída;
• BB
i,1
... B
i,m
– São os termos primários definidos nas partições
Fuzzy
de cada variável de
saída, definidos por funções de pertinência μ
Bi,m
;
• ⊗ – Representa os operadores lógicos ("E" ou "OU").
95
Avaliação dos Antecedentes
A avaliação dos antecedentes (premissas ou situações) de uma regra se compõe, em geral,
de duas etapas. Primeiramente, os valores numéricos dados para cada variável de entrada são
avaliados de acordo com as funções de pertinência associadas à variável correspondente,
resultando o grau de pertinência de cada valor nos termos lingüísticos correspondentes. Entende-
se esse processo, também, como a transformação dos valores numéricos das variáveis de entrada
em números
Fuzzy
(fuzzyficação). Na segunda etapa, uma função é aplicada aos graus de
pertinência obtidos para cada proposição antecedente, produzindo um valor numérico, entre 0 e 1,
que representa o grau com que a expressão condicional da regra é satisfeita (grau de
aplicabilidade da regra). As funções utilizadas nesse processo dependem do operador lógico usado
na combinação das proposições, sendo as mais comumente adotadas as funções de mínimo para o
operador "E" e máximo para o operador "OU", tal qual as operações de interseção e união de
conjuntos
Fuzzy
, respectivamente. Formalmente, tem-se:
ABBA
Uxxx
∈∀)}(μ),(μmin{B∩A = B) E(A ν = 4.6
ABBA
Uxxx
∈∀)}(μ),(μmax{B∪A = B) OU(A ν = 4.7
Onde:
• ν é o grau de aplicabilidade ou coeficiente de disparo;
• A
e B são termos lingüísticos;
• μ
A
(x) e μ
B
(x) são os graus de pertinência de x nos conjuntos
Fuzzy
associados com A
B
e B,
respectivamente.
As regras com (ν > 0) são ditas regras aplicáveis ou que dispararam para as entradas
atuais, ou seja, elas vão contribuir para o cálculo da saída correspondente do sistema de
inferência. Por sua vez, os graus de aplicabilidade limitarão os valores máximos dos conjuntos
Fuzzy
de saída gerados por estas regras.
Implicação
É o processo em que os conseqüentes das regras, cujas condições são satisfeitas com
algum grau (ν > 0), referidas como regras aplicáveis, são calculados com base nos respectivos
graus de aplicabilidade. Este processo encerra a idéia de que: se o antecedente da regra é
verdadeiro com algum grau, então o conseqüente é, também, verdadeiro, com o mesmo grau. Nos
casos em que as regras possuem mais de um conseqüente, todos os conseqüentes são igualmente
afetados pelo grau de aplicabilidade.
96
O processo de implicação consiste, basicamente, na modificação dos conjuntos
Fuzzy
associados com os conseqüentes da regra. No modelo de inferência
Fuzzy
de Mamdani, o
conjunto é truncado em um nível correspondente ao grau de aplicabilidade da regra.
Agregação dos Conseqüentes
Quando um sistema de regras é avaliado para um conjunto de valores dados para as
variáveis de entrada, encontram-se, em geral, mais de uma regra aplicável. Neste caso, os
conseqüentes obtidos pela inferência destas regras devem ser combinados ou agregados para
produzir uma resposta única do sistema para cada variável de saída. No modelo de inferência
Fuzzy
de Mamdani, o método de agregação dos conseqüentes é a união dos conjuntos difusos.
Condensação dos Conseqüentes
O conjunto
Fuzzy
gerado ao final do processo de agregação pode então ser utilizado
diretamente em um diagnóstico qualitativo de tomada de decisão. Entretanto, em alguns casos, os
conjuntos difusos obtidos pela agregação dos conseqüentes não são suficientes como respostas do
sistema, sendo necessária a escolha de valores numéricos (
crisp
) representativos das respostas
difusas. No modelo de inferência
Fuzzy
de Mamdani, este valor correspondente ao baricentro
geométrico ou centróide da área definida pelo conjunto
Fuzzy
resultante da agregação dos
conseqüentes. Este processo é comumente chamado de
desfuzzyficação.
No método do baricentro geométrico, para um dado conjunto
Fuzzy
de saída, proveniente
de uma base de conhecimento processada, a abscissa do baricentro geométrico da área
correspondente, é utilizada como valor escalar de saída. A equação abaixo sintetiza este processo
para uma saída escalar (S) de um conjunto
Fuzzy
resultante (C).
Para um Universo (U) Discreto →
)(∑
).(∑
∈∀
∈∀
Ci
UC
CiCi
UC
A
Ax
S
Ci
Ci
=
4.8
Para um Universo (U) Contínuo →
C
Ux
C
C
Ux
CC
dxxf
dxxfx
S
Cc
Cc
)(
)(.
∫
∫
∈∀
∈∀
=
Onde:
• S é o valor escalar de saída (valor
crisp
);
• é a área de cada subconjunto
Fuzzy
de C;
Ci
A
• é o baricentro geométrico de cada elemento ;
Ci
x
Ci
A
97
• é a função de pertinência do conjunto
Fuzzy
resultante C;
)(
C
xf
C
x
são os pontos do universo de discurso U do conjunto
Fuzzy
resultante C. •
Para ilustrar os conceitos abordados neste item, a Figura 4.10 mostra um exemplo de
processo de inferência
Fuzzy
, utilizado nesse trabalho. No caso desse exemplo, o usuário pondera
2 Quesitos (Documentação da Manutenção e Documentação do Sistema), os quais irão compor o
processo da avaliação do Critério (Disponibilidade da Informação/Recursos) o qual faz parte da
avaliação da Etapa 0 do procedimento de referência, que será explicitado no Capítulo 5. O
primeiro Quesito foi ponderado com uma Nota 1,8, a qual tem um grau de pertinência μ = 0,2 ao
termo primário Ruim e μ = 0,8 ao termo primário Baixa. O segundo Quesito foi ponderado com
uma Nota 7,5, a qual tem um grau de pertinência μ = 1,0 ao termo primário Alta. Os termos
primário se referem a aderência da empresa/sistema aos Quesitos ponderados.
Documentação da Manutenção
Após a implicação e a agregação dos conseqüentes se tem o conjunto
Fuzzy
resultante do
processo de inferência cuja
desfuzzyficação
resulta na Nota = 4,78 que retrata a aderência da
empresa/sistema ao Critério sob análise (Disponibilidade da Informação/Recursos).
4.10 A
SHELL
FUZZYCLIPS
O FuzzyClips (
http://www.iit.nrc.ca/IR_public/fuzzy/fuzzyClips/fuzzyCLIPSIndex.html) é
uma extensão da
shell
Clips e foi desenvolvido pela
Integrated Reasoning Group
do
Institute for
Information Technology
da
National Research Council of Canada
. O FuzzyCLIPS está totalmente
integrado com o mecanismo de inferência e de fatos do Clips, permitindo assim representar e
manipular fatos e regras
Fuzzy
, além de processar raciocínio exato,
Fuzzy
(não-exato) e
78,4
2
1).13(
2
8,0).4,13(
2
2,0).8,12(
2
1).13(
.5,7
2
8,0).4,13(
.5,2
2
2,0).8,12(
.1
)(
)(.
2 =
⎥
⎦
⎤
⎢
⎣
⎡
⎟
⎠
⎞
⎜
⎝
⎛
+
+
⎟
⎠
⎞
⎜
⎝
⎛
+
+
⎟
⎠
⎞
⎜
⎝
⎛
+
⎥
⎦
⎤
⎢
⎣
⎡
⎟
⎠
⎞
⎜
⎝
⎛
+
+
⎥
⎦
⎤
⎢
⎣
⎡
⎟
⎠
⎞
⎜
⎝
⎛
+
+
⎥
⎦
⎤
⎢
⎣
⎡
⎟
⎠
⎞
⎜
⎝
⎛
+
==
∫
∫
∈∀
∈∀
C
Ux
C
C
Ux
CC
dxxf
dxxfx
C
Cc
Cc
Implicação
Nota = 4,78
Ruim Baixa Boa Alta Ótima
1 2 3 4 5 6 7 8 9 10
μ
1
Nota = 1,8
Documentação do Sistema
Ruim Baixa Boa Alta Ótima
1 2 3 4 5 6 7 8 9 10
μ = 1,0
Disponibilidade da Informação/Recursos
Ruim Baixa Boa Alta Ótima
1 2 3 4 5 6 7 8 9 10
μ
1
0,8
0,2
μ
1
Nota = 7,5
Ruim Baixa Boa Alta Ótima
1 2 3 4 5 6 7 8 9 10
μ
1
1 2 3 4 5 6 7 8 9 10
Implicação
Agregação
Pondera
ç
ão e Fuzz
y
fica
ç
ão
Condensa
ç
ão ou Desfuzz
y
fica
ç
ão
Disponibilidade da Informação/Recursos
Disponibilidade da Informação/Recursos
μ
1
0,8
0,2
μ = 0,8
μ = 0,2
Figura 4.10 – Exemplo de um Processo de Inferência
Fuzzy
.
98
combinações destes, permitindo a mistura de termos
Fuzzy
e
Crisp
em regras e fatos do sistema
especialista (FERNANDES, 2001).
Detalhes da estrutura de regras utilizadas no SBC-
Fuzzy
desenvolvido neste trabalho, com
a utilização da
shell
FuzzyClips, podem ser vistos no Capítulo 6. O Apêndice B mostra as
características da
shell
FuzzyClips incluindo trechos do programa computacional desenvolvido.
4.11 CONSIDERAÇÕES E SÍNTESE DO CAPÍTULO
Neste capítulo foram abordados os principais conceitos relacionados aos SBC’s e de
especial interesse aos objetivos deste trabalho, explanados no Capítulo 1.
Elucidado seu contexto dentro da IA, foram discutidos: a arquitetura, o processo de
desenvolvimento e o tratamento de incertezas utilizando a lógica
Fuzzy
. O Apêndice B deste
trabalho apresenta mais detalhes dos tópicos abordados neste capítulo
Deste capítulo ressalta-se as seguintes resoluções:
• O modelo de desenvolvimento adotado neste trabalho é o modelo incremental, pois nele é
possível que as etapas do ciclo de desenvolvimento do SBC sejam seguidas utilizando
apenas pequenas partes de conhecimento em relação à totalidade do domínio do
conhecimento, permitindo retornos às etapas anteriores, caso seja constatado algum tipo
de erro ou inadequação em alguma tomada de decisão sobre o projeto do SBC, seguindo
assim os conceitos de Engenharia Simultânea propostos por Silva (1998);
• Para elicitação do conhecimento são adotadas as técnicas baseadas em descrições,
entrevistas, análise de protocolo e
teachback
;
• Devido à versatilidade dos SBC’s híbridos, este trabalho utiliza a representação orientada
a objeto associada a regras de produção como forma de RC;
• Este trabalho utiliza os mecanismos de inferência da
shell
FuzzyClips e uma interface com
o usuário desenvolvida em
Visual Basic
. Detalhes deste desenvolvimento são abordados
no Capítulo 6.
As técnicas de Engenharia do Conhecimento, abordadas neste capítulo, estão alinhadas
com as necessidades da GC abordada no Capítulo 3, ao mesmo tempo em que auxiliam a tomada
de decisão durante o processo de implementação e auditoria da MCC.
99
CAPÍTULO 5
METODOLOGIA DESENVOLVIDA PARA IMPLEMENTAÇÃO DA MCC
5.1 INTRODUÇÃO
Este capítulo aborda a metodologia proposta para auxiliar a implantação da Manutenção
Centrada na Confiabilidade (MCC), com os requisitos e características apresentadas no Capítulo 1 e
o embasamento teórico elucidado nos demais capítulos precedentes.
Conforme revelou a pesquisa bibliográfica, apresentada no Capítulo 2, os procedimentos
para implantação de um programa de MCC (NOWLAN e HEAP, 1978; SMITH, 1993; SMITH e
HINCHCLIFFE, 2004; MOUBRAY, 2001; NASA, 2000; IEC 60300-3-11, 1999; SAE JA 1011,
1999; SAE JA 1012, 2002; ABS, 2004) são divergentes em alguns aspectos, quando comparados
entre si. Portanto, para viabilizar o processo de elicitação dos fatores críticos para o sucesso de um
programa de MCC faz-se necessário a elaboração de um procedimento de referência que incorpore
todos os aspectos sugeridos na bibliografia pesquisada. Deste modo, será possível garantir a
conformidade com todas as normas e autores pesquisados e propor etapas não contempladas por tais
normas e/ou autores, mas que podem de alguma maneira afetar positivamente o sucesso de um
programa de MCC.
5.2 PROCEDIMENTO DE REFERÊNCIA PARA IMPLANTAÇÃO DA MCC
Este item apresenta o procedimento sugerido neste trabalho como referência para
implantação da MCC. Com base neste procedimento será possível elaborar uma metodologia para
auxiliar a implantação da MCC que analise e pondere as características e objetivos da empresa, as
necessidades do sistema ao qual a MCC será implantada e os fatores críticos para o sucesso de um
programa de MCC. Ao final dessa análise será possível propor ferramentas e normas de conduta que
minimizem os aspectos que podem afetar negativamente o programa de MCC.
O procedimento de referência segue as etapas mostradas na Figura 5.1. Cada etapa
pressupõe requisitos específicos de entrada e fornecem saídas que serão utilizadas nas etapas
seguintes ou que irão compor o manual de MCC da empresa. Além disso, cada etapa demanda
determinadas tarefas, mecanismos e controles para sua execução. O detalhamento de cada uma
destas características será explicitado no item referente aos aspectos de cada etapa. O procedimento
de referência foi desenvolvido para contemplar todas as etapas do ciclo de vida da MCC, desde a
verificação de sua adequação para o sistema pretendido até a realimentação das decisões tomadas ao
longo do processo de implantação, em função de critérios de desempenho do programa de MCC.
Cinco macro-etapas compõem o procedimento de referência proposto, as quais são: Pré-
Implantação; Análise; Tomada de Decisão; Implementação; e Execução.
100
Figura 5.1 – Procedimento de Referência para Implantação da MCC.
Demandas
Objetivos
Tarefas
Entradas
Saídas
Controles
Mecanismos
Etapa 0
Adequação da MCC
Etapa 1
Preparação
Etapa 2
Seleção do Sistema e Coleta de Informações
Etapa 3
Análise dos Modos de Falha, seus Efeitos e sua
Criticidade (FMECA)
Etapa 4
Seleção das Funções Significantes e Classificação de
seus Modos de Falha
Etapa 5
Seleção das Tarefas de Manutenção Aplicáveis e
Efetivas
Etapa 6
Definição dos Intervalos Iniciais e Agrupamento das
Tarefas de Manutenção
Etapa 7
Redação do Manual e Implementação
Etapa 8
Acompanhamento e Realimentação
Análise
Tomada
de
Decisão
Implementação
Pré- Implantação
Execução
5.3 ASPECTOS DE CADA ETAPA DO PROCEDIMENTO DE REFERÊNCIA
Para explicitar os aspectos envolvidos em cada etapa do procedimento de referência será
utilizado um modelo adaptado das recomendações da metodologia IDEF (
Integration DEFinition
–
Definição Integrada) baseada na Técnica de Análise e Projetos Estruturados (
Structured Analysis
and Design Techinique – SADT
), uma abordagem gráfica para a descrição de sistemas introduzida
por Douglas T. Ross na década de 70 (MICHEL, 2002). Existem 16 métodos IDEF (do IDEF0 ao
IDEF14 – incluindo IDEF1X) sendo que cada um foi projetado para capturar um tipo de informação
particular através da modelagem do processo. Em dezembro de 1993, o Instituto Nacional de
Padronizações e Tecnologias (
National Institute of Standards and Technology – NIST
) liberou o
IDEF0 como um padrão para a Modelagem de Funções. O IDEF0, primeiro conjunto de padrões do
101
IDEF, processa uma coleção de atividades e outras ações utilizando-se de ICOM’s (
Input, Control,
Output, Mechanism
– Entrada, Controle, Saída e Mecanismo), Setas e Caixas. Cada atividade ou
função é conceitualmente representada por uma caixa retangular, sendo que esta atividade pode ser
decomposta em vários níveis, os quais seguem as mesmas convenções. Portanto, um modelo
completo de IDEF0 é uma representação hierárquica do processo decomposta por atividades ou
funções em quantos níveis forem necessários.
Este trabalho utilizará uma abordagem adaptada da IDEF0 explicitando, além dos ICOM’s,
os Objetivos e as Tarefas de cada etapa, para complementar o método IDEF0 e adequá-lo às
necessidades da metodologia MCC, (Figura 5.2), explanados a seguir:
Figura 5.2 – Aspectos do Procedimento de Referência para cada Etapa da MCC.
Controles
Mecanismos
Entradas
Saídas
Etapa
TarefasObjetivos
● Objetivos – São as razões de existência de cada etapa e estão relacionados com as funções
que cada etapa desempenha dentro do programa de MCC, por exemplo: verificar aderência a
determinado critério; definir um sistema para implementação da MCC; levantar os modos de
falha seus efeitos e sua criticidade para o sistema sob análise;
● Tarefas – São atividades a serem desenvolvidas em cada etapa para atendimento de seus
objetivos e das necessidades do programa de MCC, por exemplo: preencher a planilha de
FMECA (
Failure Modes, Effects and Criticality Analysis
– Análise dos Modos de Falha
seus Efeitos e sua Criticidade); conceber índices de desempenho; documentar a atividade
desenvolvida na etapa;
● Entradas – São os requisitos exigidos pela etapa para obtenção das saídas, por exemplo:
especialistas, documentação, dados, informações ou conhecimento sobre o sistema no qual
será implantada a MCC; resultados de etapas anteriores;
● Saídas – São os resultados do processamento de cada etapa, para uma próxima etapa ou para
o manual de MCC, por exemplo: decisões documentadas; planilha de FMECA preenchida;
manual das ações de manutenção;
● Controles – São informações, critérios ou estratégias para monitoramento e/ou garantia da
correta execução da tarefa, por exemplo: normas aplicáveis; conhecimento do especialista;
necessidades da empresa; índices de desempenho;
● Mecanismos – São os recursos/ferramentas necessários ou que auxiliam a execução da
etapa, por exemplo: planilha de FMECA; diagramas de decisão; equações para formulação
de índices de desempenho.
102
Nos próximos parágrafos, cada uma das etapas do procedimento de referência será
discriminada fundamentando-se na metodologia IDEF0, adaptada conforme descrito anteriormente.
5.3.1 Etapa 0 – Adequação da MCC
Objetivos: verificar se a gestão da manutenção fundamentada na MCC, com seus requisitos e
características metodológicas e filosóficas, é a mais adequada para a empresa/sistema, considerando
suas disponibilidades e limitações.
Tarefas: comparar e verificar o grau de aderência das características da empresa/sistema com as
necessidades e exigências de um programa de MCC; documentar de forma auditável as premissas e
conclusões desta etapa.
Entradas: especialistas em MCC; especialistas nos sistemas candidatos a implantação da MCC
(pertencentes à equipe de manutenção, operação e outros envolvidos direta ou indiretamente com
os sistemas candidatos); pessoal pertencente aos níveis gerenciais da empresa, com autonomia
para tomada de decisão, mobilização de recursos humanos e financeiros e conhecedores da
estratégia gerencial da empresa com relação aos sistemas candidatos a implantação da MCC e sua
manutenção; informações gerenciais da empresa; informações técnicas e gerenciais da
manutenção; planejamento estratégico da empresa com relação a manutenção e ao sistema ao qual
a MCC será aplicada
1
.
Saídas: relatório de avaliação da empresa/sistema contendo os critérios adotados, as ponderações
feitas e a conclusão se a MCC é ou não aderente a empresa/sistema sob análise, com as respectivas
justificativas. Nos casos em que a adoção da MCC não seja recomendada esta etapa pode apresentar
como saída um planejamento estratégico de implementação da MCC, atrelado às características
atuais da empresa/sistema; documentação referente às decisões tomadas nesta etapa.
Controles: expertise em MCC, no sistema-alvo e na gerência da empresa; normas e materiais
bibliográficos que explicitem as necessidades de um programa de MCC.
Mecanismos: local e estrutura para condução das reuniões; disponibilidade dos envolvidos no
processo de implantação da MCC; questionário estruturado para elicitação das características da
empresa/sistema, relacionadas com a MCC; critérios para comparação das características da
empresa/sistema com as necessidades da MCC; métodos de ponderação dos critérios analisados.
5.3.2 Etapa 1 – Preparação
Objetivos: formação da equipe e planejamento estratégico para implantação da MCC.
1
A partir deste ponto estes componentes serão referenciados como “expertise em MCC, no sistema-alvo e na
gerência da empresa”
103
Tarefas: estabelecer os objetivos do programa de MCC; definir a abrangência ou nível de aplicação
do programa de MCC; preparar, organizar e estruturar a equipe de implantação da MCC para
atender os requisitos das etapas seguintes; inferir sobre as necessidades relacionadas a treinamento,
organização e estruturação, requeridas ao longo dos procedimentos de implementação do programa
de MCC; elaborar a metodologia e a estratégia para execução e condução das reuniões da equipe de
implantação da MCC; documentar de forma auditável as premissas e conclusões desta etapa.
Entradas: saídas da etapa anterior
2
; expertise em MCC, no sistema-alvo e na gerência da empresa.
Saídas: documentação referente às decisões tomadas nesta etapa; plano para implantação da MCC
contendo no mínimo os seguintes itens: objetivos e metas a serem atingidas durante a implantação;
composição da equipe responsável pela implantação da MCC; calendário de reuniões; programa de
treinamento para a equipe de implantação, membros dos níveis gerenciais e demais interessados
estratégicos para o programa de MCC; cronograma para execução das tarefas; designação de um
patrocinador interno com suas respectivas atribuições e responsabilidades; alocação de recursos
humanos e financeiros; previsão orçamentária.
Controles: expertise em MCC, no sistema-alvo e na gerência da empresa; normas e materiais
bibliográficos sobre MCC; disponibilidades e limitações para formação e treinamento da equipe de
implantação da MCC; critérios e necessidades internas da empresa; dados que permitam um
comparativo com empresas/sistemas de referência (benchmarking).
Mecanismos: ferramentas computacionais (para esta etapa bastam planilhas eletrônicas e
processadores de texto); local e estrutura para condução das reuniões; disponibilidade dos
responsáveis pela condução do processo de implantação da MCC.
5.3.3 Etapa 2 – Seleção do Sistema e Coleta de Informações
Objetivos: identificar e documentar o sistema que será submetido à análise e implantação da MCC.
Tarefas: definir e aplicar critérios quantitativos e qualitativos para seleção do sistema ao qual a
MCC será aplicada; documentar o sistema selecionado e suas fronteiras.
Entradas: saídas das etapas anteriores; expertise em MCC, no sistema-alvo e na gerência da
empresa; sistemas candidatos a implantação da MCC, com as seguintes informações: contexto
operacional, documentação de engenharia, históricos de manutenção, custo atualizado de
manutenção, relação com a disponibilidade global do processo produtivo e implicações na
segurança e meio ambiente.
2
Como saídas das etapas anteriores entenda-se, a partir deste ponto, as saídas “materiais” (relatórios, documentos,
resultados de análises, etc...) de todas as etapas anteriores a etapa sob análise. Isso não exclui a necessidade de
expertise em MCC, no sistema-alvo e na gerência da empresa para as análises exigidas na etapa corrente.
104
Saídas: sistema selecionado com as seguintes informações, quando aplicáveis: identificação dos
subsistemas e componentes, descrição textual, diagramas esquemáticos, diagramas de blocos,
diagrama organizacional, diagrama funcional, diagrama lógico funcional e descrição das fronteiras;
documentação referente às decisões tomadas nesta etapa.
Controles: expertise em MCC, no sistema-alvo e na gerência da empresa; documentação de
engenharia dos sistemas candidatos a implantação da MCC; normas aplicáveis aos sistemas
candidatos a implantação da MCC; necessidades estratégicas da empresa.
Mecanismos: ferramentas computacionais (planilhas eletrônicas e processadores de texto) ou
software específico para implantação da MCC; local e estrutura para condução das reuniões; e
disponibilidade dos responsáveis pela condução do processo de implantação da MCC.
5.3.4 Etapa 3 – Análise dos Modos de Falha, seus Efeitos e sua Criticidade (FMECA)
Objetivos: identificar e documentar todas as funções do sistema selecionado na etapa 2, seus modos
de falha, os efeitos adversos destes modos de falha, as causas do modo de falha e uma avaliação de
sua criticidade.
Tarefas: conduzir e documentar o processo de FMECA; criar índices de consenso, entre a equipe de
implantação e a empresa, para avaliar a criticidade do modo de falha, a qual envolve: a severidade
dos efeitos, a freqüência de ocorrência das causas do modo de falha e a probabilidade de detecção
das causas do modo de falha.
Entradas: saídas das etapas anteriores; expertise em MCC, no sistema-alvo e na gerência da
empresa; documentação técnica do sistema ao qual a MCC será aplicada; desenhos técnicos, fotos e
texto explicativo referente aos modos de falha seus efeito e suas causas.
Saídas: funções desempenhadas pelo sistema; falhas funcionais associadas a cada função; modos de
falha associados à perda da função; efeitos provocados no sistema devido a um modo de falha;
índice de criticidade ponderando a severidade dos efeitos e a ocorrência e a detecção das causas do
modo de falha; documentação referente às decisões tomadas nesta etapa (planilha de FMECA e
índices de severidade, ocorrência e detecção adotados).
Controles: expertise em MCC, no sistema-alvo e na gerência da empresa; documentação técnica do
sistema ao qual a MCC será aplicada; saídas da etapa 2; normas aplicáveis ao sistema sob análise;
normas e/ou procedimentos para condução da FMECA.
Mecanismos: ferramentas computacionais (planilhas eletrônicas, processadores de texto ou software
específico para implantação da MCC); planilha de FMECA ou FMEA (
Failure Modes and Effects
Analysis
– Análise dos Modos de Falha e seus Efeitos); local e estrutura para condução das
reuniões; FTA (
Fault Tree Analysis
– Análise da Árvore de Falhas) dos modos de falha, para
auxiliar a identificação de suas causas raízes; ETA (
Event Tree Analysis
– Análise da Árvore de
105
Eventos) dos efeitos do modo de falha, para auxiliar a identificação e atribuição do seu grau de
severidade; disponibilidade dos responsáveis pela condução do processo de implantação da MCC.
Observação: Este trabalho considera, para efeitos de composição do procedimento de referência, a
metodologia de FMECA/FMEA proposta pela norma J1739 da SAE (
Society of Automotive
Engineers
) que divide sua abordagem em 2 tópicos: FMEA de Projeto (
Potential Failure Mode and
Effects Analysis in Design
) e FMEA de Processo (
Potential Failure Mode and Effects Analysis in
Manufacturing and Assembly Processes
). A mesma norma apresenta também uma metodologia para
aplicar a FMEA em máquinas (
Potential Failure Mode and Effects Analysis for Machinery
). Para
compatibilizar a proposta da SAE J1739 com as exigências da SAE JA1011 (
Criteria for Reliability
Centered Maintenance Processes
) e SAE JA 1012 (
A Guide to the Reliability Centered Maintenance
Standard
) foi incluído na planilha de FMECA uma coluna para registro da Falha Funcional. A
planilha de FMECA proposta por esta norma pode ser vista na Figura 5.3 e seu preenchimento
segue as recomendações detalhadas no Apêndice A.
Figura 5.3 – Planilha de FMECA adotada no Procedimento de Referência.
Fonte: adaptado de SAE J1739.
Resultados das
Ações
Item
Função
Falha
Funcional
Modo
de
Falha
Efeito
do
Modo
de
Falha
Severidade (S)
Causas
do
Modo
de
Falha
Ocorrência (O)
Controles
Atuais
Detecção (D)
NPR (S.O.D)
Ações
Recomendadas
Responsável
e
Data de
Término
Programada
Ações
Adotadas
Severidade (S)
Ocorrência (O)
Detecção (D)
NPR (S.O.D)
5.3.5 Etapa 4 – Seleção das Funções Significantes e Classificação de seus Modos de Falha
Objetivos: analisar cada função identificada na etapa anterior e determinar se a falha funcional tem
efeito significante, e caso afirmativo, classificar seus modos de falha levando em conta os impactos
nos aspectos pilares da MCC: segurança, meio ambiente, operação e economia do processo.
Tarefas: elaborar os critérios para definição da significância ou não das funções identificadas na
etapa 3; elaborar os critérios para definição se um modo de falha e/ou seus efeitos são ou não
evidentes e se o impacto é ambiental, de segurança, econômico ou operacional; aplicar a lógica de
seleção das funções significantes identificando cada função como: significante ou não significante;
para as funções significantes classificar, segundo os critérios da MCC, cada modo de falha e/ou seus
efeitos: ESA – Evidente com efeito na Segurança ou Ambiente; EEO – Evidente com efeito
Econômico ou Operacional; OSA – Oculto com efeito na Segurança ou Ambiente; OEO – Oculto
com efeito Econômico ou Operacional; documentar as funções significantes com a respectiva
classificação de seus modos de falha, os quais devem seguir na análise do processo de implantação
da MCC; documentar as funções não significantes, as quais a análise termina nesta etapa.
106
Entradas: saídas das etapas anteriores; expertise em MCC, no sistema-alvo e na gerência da
empresa; documentação técnica do sistema ao qual a MCC será aplicada; lista de funções já
protegidas por tarefas existentes de manutenção.
Saídas: lista das funções significantes com seus respectivos modos de falha classificados (ESA, EEO,
OSA e OEO), os quais serão submetidos às etapas subseqüentes; lista de funções não significantes,
cuja análise termina nesta etapa; documentação referente às decisões tomadas nesta etapa.
Controles: expertise em MCC, no sistema-alvo e na gerência da empresa; documentação técnica do
sistema ao qual a MCC será aplicada; saídas da etapa 3; normas aplicáveis ao sistema sob análise;
critérios para identificação das funções significantes e classificação de seus modos de falha.
Mecanismos: ferramentas computacionais (planilhas eletrônicas, processadores de texto ou software
específico para implantação da MCC); diagramas de decisão para seleção de funções significantes;
diagramas de decisão para classificação dos modos de falha das funções definidas como
significantes; local e estrutura para condução das reuniões; disponibilidade dos responsáveis pela
condução do processo de implantação da MCC.
Observação: Por julgar mais adequada, este trabalho utiliza, para composição do procedimento de
referência, a lógica de seleção das funções significantes e classificação de seus modos de falha,
proposta pela IEC 60300-3-11 (
Dependability Management - Part 3-11: Application Guide -
Reliability Centred Maintenance
) a qual pode ser vista nas Figuras 5.4 (a) e (b), respectivamente.
Figura 5.4 – Seleção das Funções Significantes e Classificação dos seus Modos de Falha.
Fonte: adaptado de IEC 60300-3-11.
a) Seleção das Funções Significantes. b) Classificação dos Modos de Falha
5.3.6 Etapa 5 – Seleção das Tarefas de Manutenção Aplicáveis e Efetivas
Observação: Por julgar mais adequada este trabalho utiliza, para composição do procedimento de
referência, a lógica de seleção de atividades de manutenção aplicáveis e efetivas proposta pela IEC
107
60300-3-11 (
Dependability Management - Part 3-11: Application Guide - Reliability Centred
Maintenance
) a qual pode ser vista na Figura 5.5.
Figura 5.5 – Seleção das Tarefas de Manutenção.
Fonte: adaptado de IEC 60300-3-11.
ESA – Evidente com efeito na Segurança ou Ambiente
OSA – Oculto com efeito na Segurança ou Ambiente
EEO – Evidente com efeito Econômico ou Operacional
OEO – Oculto com efeito Econômico ou Operacional
Objetivos: determinar quais as tarefas de manutenção aplicáveis e efetivas para cada uma das
funções significantes identificadas e caracterizadas na etapa 4.
Tarefas: definir os critérios de aplicabilidade e efetividade das tarefas de manutenção; aplicar o
diagrama de decisão para selecionar as tarefas de manutenção aplicáveis e efetivas; documentar o
processo de seleção das tarefas de manutenção aplicáveis e efetivas.
Entradas: saídas das etapas anteriores; expertise em MCC, no sistema-alvo e na gerência da
empresa; documentação técnica do sistema ao qual a MCC será aplicada; lista das tarefas atuais de
manutenção, de cada um dos itens, cuja alguma função tenha sido identificada como significante;
dados estatísticos referentes às funções significantes, especialmente: tempo para falhar, tempo entre
falhas, tempo de reparo, rotina/ciclo operacional do item/sistema.
Saídas: tarefas de manutenção aplicáveis e efetivas para cada modo de falha das funções
significantes identificadas na etapa 4, dentre as tarefas de manutenção possíveis estão: Serviço
108
Operacional, Inspeção Preditiva, Restauração Preventiva, Substituição Preventiva, Inspeção
Funcional, Manutenção Combinada, Mudança de Projeto e Reparo Funcional; documentação
referente às decisões tomadas nesta etapa.
Controles: expertise em MCC, no sistema-alvo e na gerência da empresa; documentação técnica do
sistema ao qual a MCC será aplicada; saídas da etapa 4; normas aplicáveis ao sistema sob análise;
critérios para definição de quais tarefas de manutenção são aplicáveis e efetivas para o sistema em
seu contexto operacional.
Mecanismos: ferramentas computacionais (planilhas eletrônicas, processadores de texto ou software
específico para implantação da MCC); diagramas de decisão para seleção de atividades de
manutenção aplicáveis e efetivas; local e estrutura para condução das reuniões; disponibilidade dos
responsáveis pela condução do processo de implantação da MCC.
5.3.7 Etapa 6 – Definição dos Intervalos Iniciais e Agrupamento das Tarefas de Manutenção
Objetivos: definir a periodicidade inicial das atividades de manutenção selecionadas na etapa 5 e
agrupar estas atividades de forma estratégica para otimizar as ações da equipe de manutenção.
Tarefas: para todas as tarefas de manutenção selecionadas na etapa 5: estabelecer os métodos e
critérios para definição da periodicidade ou freqüência de execução; fixar a periodicidade ou
freqüência de execução das atividades; definir os métodos e critérios para agrupamento otimizado
das tarefas; agrupar de forma otimizada as tarefas, de acordo com o tamanho da equipe de
manutenção e oportunidades de concomitância com outras tarefas.
Entradas: saídas das etapas anteriores; expertise em MCC, no sistema-alvo e na gerência da empresa;
documentação técnica do sistema ao qual a MCC será aplicada; dados confiabilísticos, de
mantenabilidade e de produtividade do sistema ao qual a MCC será aplicada, as seguintes fontes para
estes dados poderão ser utilizadas: estatísticas do sistema; experiência/conhecimento
a priori
da equipe
de manutenção; dados de sistemas técnica e operacionalmente similares; dados do fabricante.
Saídas: uma lista contendo as atividades de manutenção selecionadas na etapa 5 agrupadas de forma
otimizada e com um período e/ou freqüência de execução; documentação referente às decisões
tomadas nesta etapa.
Controles: expertise em MCC, no sistema-alvo e na gerência da empresa; documentação técnica do
sistema ao qual a MCC será aplicada; normas aplicáveis ao sistema analisado; saídas da etapa 5; dados
confiabilísticos, de mantenabilidade e de produtividade do sistema ao qual a MCC será aplicada.
Mecanismos: ferramentas computacionais (planilhas eletrônicas, processadores de texto ou software
específico para implantação da MCC); local e estrutura para condução das reuniões; disponibilidade
dos responsáveis pela condução do processo de implantação da MCC.
109
5.3.8 Etapa 7 – Redação do Manual e Implementação
Objetivos: redigir o manual inicial de manutenção e implementar as ações propostas pela MCC com
base nas conclusões das etapas anteriores.
Tarefas: redigir o manual de manutenção do sistema ao qual a MCC será aplicada incluindo:
descrição detalhada do sistema e suas partes componentes, considerações e conclusões das etapas
anteriores, política de manutenção para os itens cujas funções foram definidas como não
significantes na etapa 4; planejar, estruturar e implementar as ações propostas pelo programa de
MCC, levando em conta: as necessidades e limitações da empresa/sistema e o cronograma e a
estratégia de implementação e divulgação do novo programa de manutenção.
Entradas: saídas das etapas anteriores; expertise em MCC, no sistema-alvo e na gerência da
empresa; documentação técnica do sistema ao qual a MCC será aplicada; planejamento estratégico
da empresa com relação ao sistema ao qual a MCC será aplicada.
Saídas: manual do programa de MCC para o sistema selecionado; planejamento estratégico para
implementação do programa de MCC; execução do planejamento para implementação;
documentação referente às decisões tomadas nesta etapa.
Controles: expertise em MCC, no sistema-alvo e na gerência da empresa; documentação técnica do
sistema ao qual a MCC será aplicada; normas aplicáveis ao sistema analisado; saídas das etapas
anteriores.
Mecanismos: ferramentas computacionais (planilhas eletrônicas, processadores de texto ou software
específico para implantação da MCC); local e estrutura para condução das reuniões; disponibilidade
dos responsáveis pela condução do processo de implantação da MCC.
5.3.9 Etapa 8 – Acompanhamento e Realimentação
Objetivos: definir as estratégias inerentes e executar o acompanhamento e a realimentação do
programa de MCC, ao longo de todo o seu ciclo de vida.
Tarefas: definir os critérios para composição dos indicadores de desempenho, do programa de MCC
e do sistema ao qual a MCC foi implantada; formular os indicadores de desempenho do programa
de MCC e do sistema; definir os índices de desempenho, a serem alcançados pela MCC, e/ou que
sejam aceitáveis, do ponto de vista estratégico da empresa; definir os critérios para realimentação do
programa de MCC (realimentações periódicas até a consolidação do programa, realimentações
dependentes dos indicadores de desempenho ou uma estratégia mista); acompanhar o programa de
MCC e o sistema no qual a MCC foi implantada, realimentando o programa inicial/anterior quando
110
necessário, em função dos critérios estabelecidos; estruturar e sistematizar as rotinas e estratégias
para coleta das informações que irão subsidiar os indicadores de desempenho.
Entradas: manual do programa de MCC; expertise em MCC, no sistema-alvo e na gerência da
empresa; planejamento estratégico da empresa com relação ao sistema ao qual a MCC será aplicada;
dados estatísticos do sistema ao qual a MCC será aplicada (confiabilísticos, de mantenabilidade e de
produtividade); dados estatísticos do fabricante ou de sistemas técnica e operacionalmente similares.
Saídas: listagem dos principais índices de desempenho a serem atingidos pelo programa de MCC;
critérios para realimentação do programa de MCC; rotinas e estratégias para coleta das informações
e acompanhamento do programa de MCC e do sistema no qual a MCC foi implantada; indicadores
de desempenho do programa de MCC e do sistema no qual a MCC foi implantada; documentação
referente às decisões tomadas nesta etapa.
Controles: expertise em MCC, no sistema-alvo e na gerência da empresa; planejamento estratégico
da empresa com relação ao sistema ao qual a MCC foi aplicada; normas aplicáveis ao sistema
analisado; manual do programa de MCC; ações técnicas e administrativas que subsidiem as decisões
referentes às ações de manutenção, conforme estabelecidas no programa de MCC.
Mecanismos: ferramentas computacionais (planilhas eletrônicas, processadores de texto ou software
específico para implantação da MCC); local e estrutura para condução das reuniões; disponibilidade
dos responsáveis pelo acompanhamento e realimentação do programa de MCC.
5.4 METODOLOGIA PARA DIAGNÓSTICO DA MCC
A metodologia proposta para diagnóstico da MCC, com base no procedimento de referência
para sua implantação, é composta por duas partes, a saber:
● A primeira parte trata da avaliação dos pré-requisitos necessários para implementação de
cada uma das etapas;
● A segunda parte trata da auditoria de cada etapa implementada conforme o procedimento de
referência.
A fim de minimizar os fatores críticos para o sucesso do programa de MCC, ao final da
avaliação dos pré-requisitos e da auditoria, melhorias são sugeridas com base no diagnóstico da
empresa/sistema ao qual a MCC será implantada. Entre a avaliação dos pré-requisitos e a
auditoria (Figura 5.6), está a implementação de cada uma das etapas da MCC, conforme o
procedimento de referência.
Para maximizar os resultados positivos e evitar os transtornos decorrentes de uma
etapa mal conduzida, durante os procedimentos de implantação da MCC, a metodologia
pressupõe a seguinte seqüência de aplicação:
111
1. Antes de iniciar cada uma das etapas do procedimento de referência, seus pré-requisitos são
avaliados e seus pontos fracos corrigidos;
2. Cada etapa é, então, implementada conforme as exigências do procedimento de referência,
respeitando suas necessidades e contemplando seus resultados/saídas;
3. Cada etapa implementada é, então, auditada para certificação de sua conformidade com o
procedimento de referência, antes de iniciar a implementação da próxima etapa.
Figura 5.6 – Avaliação dos Pré-Requisitos e Auditoria
Fuzzy
das Etapas da MCC.
Inferência
Fuzzy
(Pré-Requisitos)
Aceitável
Revisão da
Etapa
Aceitável
Próxima
Etapa
Etapas do
Procedimento
de Referência
Empresa ou
Sistema
Características
da Empresa
ou Sistema
Etapa sob
Análise
Pré-Requisitos
da Etapa sob
Análise
Avaliação dos
Pré-Requisitos
da Etapa
Avaliação da
Auditoria da
Etapa
Programa de
Melhoramento
Novas Características
da Empresa ou
Sistema
Saídas da
Etapa
Não Conformidades
da Etapa
Não
Sim
Não
Sim
Implementação
da Etapa
Inferência
Fuzzy
(Auditoria)
Os procedimentos de avaliação dos pré-requisitos de cada etapa e de auditoria pós-
implementação da etapa são executados por intermédio de um processo de inferência
Fuzzy
. Neste
processo, o analista pondera os quesitos que irão compor os critérios de avaliação pré e pós-
implementação da etapa sob análise. Sendo assim, cada etapa é composta por diferentes critérios para
avaliação dos pré-requisitos e auditoria e cada um desses critérios conta com diferentes quesitos, cujo
grau de aderência da empresa/sistema resultará na avaliação da etapa. A Figura 5.7 ilustra este cenário.
Fi
g
ura 5.7 – Processo de Avalia
ç
ão dos Pré-Re
q
uisitos e Auditoria
Fuzz
y
da MCC.
Avaliação dos Pré-Requisitos
Quesitos
Etapa
Critério 1
Critério n
Quesitos
Auditoria
Quesitos
Etapa
Critério 1
Critério n
Quesitos
Etapa do
Procedimento de Referência
Objetivos
Tarefas
Implementação
Entradas / Saídas / Mecanismos / Controles
112
O processo de inferência
Fuzzy
, que avalia o grau de aderência da empresa/sistema aos pré-
requisitos de cada etapa, segue a sistemática mostrada na Figura 5.8.
Figura 5.8 – Processo de Avaliação
Fuzzy
dos Pré-Requisitos das Etapas da MCC.
Parametrização do
Conjunto
Fuzzy
para
Pondera
ç
ão do Critério
Agregação dos Quesitos
para Avaliação dos
Critérios
Termos Primários
do Universo de
Discurso
Relatório de Avaliação dos
Critérios.
onjunto
Fuzzy
- Nota
C
Ponderação dos
Quesitos dos
Critérios
Quesitos para Ponderação
Fuzzy
da Aderência da
Empresa/Sistema ao Critério
Critérios que Relacionem as
Características da Empresa
com os Requisitos da MCC
Características
presa
ou Sistema
da Em
Requi
An
sitos da
Etapa sob
álise
Grau de Aderência da
Empresa/Sistema aos Quesitos
que compõem os Critérios
Agregação dos Conjuntos
Fuzzy
resultantes da Avaliação
dos Critérios
Relatório de Avaliação da
Etapa.
Conjunto
Fuzzy
- Nota
Este processo tem início com a comparação das características da empresa/sistema com os pré-
requisitos exigidos pela MCC, para um desenvolvimento adequado da etapa sob análise. Esta
comparação é feita a partir da análise, do ponto de vista da empresa/sistema, de critérios pré-
estabelecidos e específicos para cada etapa.
Para a avaliação de cada critério, a metodologia proposta apresenta diversos quesitos que devem
ser ponderados. Para tanto é necessário, primeiro, a parametrização dos termos primários que irão
compor o conjunto
Fuzzy
, o qual servirá de referência para a análise. Assim, o usuário poderá ponderar
cada quesito com uma Nota, dentro do universo de discurso de 0 a 10, ou um conceito
Fuzzy
conforme
parametrizado inicialmente. Neste caso, a metodologia propõe os seguintes conceitos ou termos
primários (lingüísticos) para a avaliação dos quesitos: Ruim, Baixa, Boa, Alta e Ótima. Esses conceitos
ou a nota referem-se ao Grau de Aderência da empresa/sistema aos requisitos da MCC, examinada
implicitamente pelo respectivo quesito. A Figura 5.9 exemplifica uma parametrização do conjunto
Fuzzy
de referência. Vale ressaltar que o processo de parametrização deve ser conduzido por um especialista
em MCC e no domínio da aplicação. O conhecimento/experiência deste especialista servirá de base para
a definição das funções de pertinência, as quais definirão os termos primários que compõem o conjunto
Fuzzy
de referência.
Quesito referente ao Critério sob Análise
Ruim Baixa Boa Alta Ótima
1 2 3 4 5 6 7 8 9 10
μ
1
Figura 5.9 – Termos Primários para Avaliação de Pré-Requisitos e Auditoria.
113
Ponderados os quesitos dos critérios de avaliação, o que se tem é o grau de aderência da
empresa/sistema àquela necessidade específica da MCC analisada no respectivo quesito. Cabe agora
proceder à agregação dos termos primários afetados pela ponderação dos quesitos para composição
do grau de aderência da empresa/sistema ao critério. Deste procedimento resultarão tantos conjuntos
Fuzzy
quantos forem os critérios a serem avaliados. Neste ponto já se tem uma avaliação parcial dos
critérios que, de alguma forma, impactarão na implementação do programa de MCC.
Agregando os conjuntos
Fuzzy
resultantes da avaliação dos critérios tem-se o conjunto
Fuzzy
que representa a aderência da empresa/sistema aos pré-requisitos da etapa sob análise. Este
conjunto significa implicitamente o quão apta a empresa/sistema está para implantar aquela etapa. A
desfuzzificação dos conjuntos
Fuzzy
, resultantes da avaliação dos critérios e da etapa, resulta em
uma Nota (valor
crisp
) que representa a aderência da empresa/sistema àquele critério e/ou etapa.
Com a avaliação da etapa e seus respectivos critérios característicos, conclui-se o processo de
inferência conduzido pelo SBC (Sistema Baseado em Conhecimento)
Fuzzy
.
Em função dos resultados apresentados pelo processo de inferência
Fuzzy
, a equipe estará
apta ou não para proceder à implementação daquela etapa da MCC. A implementação de cada etapa
deve ser conduzida respeitando-se o procedimento de referência com relação aos objetivos, tarefas,
entradas, saídas, controles e mecanismos.
Os mesmos preceitos da fase de pré-implementação da etapa podem ser adaptados para a
fase de auditoria da etapa, a diferença é que, no caso da auditoria, a entrada do processo de
inferência
Fuzzy
são as saídas do procedimento de referência, cuja conformidade deve ser avaliada.
Sendo assim, o encadeamento da metodologia, após estabelecimento dos quesitos para avaliação e
parametrização dos conjuntos
Fuzzy
, segue a seguinte seqüência (Figura 5.10): ponderação
Fuzzy
dos quesitos relacionadas agora à conformidade de execução da etapa; agregação
Fuzzy
destes
quesitos para avaliação dos critérios de conformidade da etapa; agregação dos conjuntos
Fuzzy
resultantes da avaliação dos critérios a qual, neste caso, origina o conjunto
Fuzzy
representativo do
grau de conformidade das saídas da etapa com as exigências do procedimento de referência.
Figura 5.10 – Processo de Auditoria
Fuzzy
das Etapas da MCC.
Parametrização do
Conjunto
Fuzzy
para
Auditoria da Eta
p
a
Agregação dos Termos
de Avaliação dos
Critérios de Auditoria
Termos Primários
do Universo de
Discurso
Relatório de Avaliação dos
Critérios de Auditoria.
Conjunto
Fuzzy
- Nota
Ponderação dos
Quesitos dos
Critérios
Quesitos para Auditoria
Fuzzy
da Aderência das
Saídas da Etapa aos Critérios
Critérios para
Auditoria da Etapa
da MCC
Saídas da
Etapa
Termos primários referentes ao
Grau de Aderência da Etapa
aos Critérios de Auditoria
Agregação dos Conjuntos
Fuzzy
resultantes da Avaliação
dos Critérios de Auditoria
Relatório de Auditoria da
Etapa.
Conjunto
Fuzzy
- Nota
114
Cabe ressaltar que, sempre que viável e efetivo, o SBC-
Fuzzy
pode apontar soluções para as
não conformidades apresentadas pela empresa/sistema, tanto na fase anterior à implementação da
etapa, detectadas na avaliação dos pré-requisitos, quanto na fase posterior à implementação,
detectadas na auditoria da etapa.
5.5 SUCESSOS E FRACASSOS NA CONDUÇÃO DE UM PROGRAMA DE MCC
Para entender as subjacências do processo de inferência
Fuzzy
, inerente a metodologia
proposta, há de se discorrer sobre o que caracteriza o sucesso ou o fracasso de um programa de
MCC. Programas de MCC que fracassaram em alcançar os objetivos inicialmente estabelecidos são
raramente abordados nas literaturas pesquisadas, o que se vê são casos de aplicação da MCC em
diferentes setores ou mudanças na metodologia normatizada da MCC para adequá-la às restrições
impostas pela aplicação. Algumas considerações teóricas sobre os pontos críticos de um programa
de MCC podem ser encontrados em: Backlund (2003), Moubray (2001), Siqueira (2005), Smith e
Hinchcliffe (2004) e Worledge (1993). Exemplos de adaptações na metodologia normatizada da
MCC podem ser encontrados em: Johnston (2002), Rajotte e Jolicoeur (2001) e Siqueira (2007).
Exemplos de aplicação da MCC podem ser encontrados em: Alkaim (2003), Backlund (2003),
Lucatelli (2002), Ribeiro (2005) e Vizzoni
et al
(1999).
Da mesma bibliografia citada no parágrafo precedente, além de outros artigos pesquisados, é
possível abstrair alguns critérios, a partir dos quais se pode julgar o êxito ou fracasso de um
programa de MCC, entre esses destacam-se (Figura 5.11):
Figura 5.11 – Critérios para Julgamento do Êxito de um Programa de MCC.
Recursos
Retorno do Investimento
Comprometimento
Tempo
Sucesso ou Fracasso de
um Programa de MCC
Resultados e Benefícios
Condições para
Aprimoramento
Contínuo
Recursos: a MCC requer um significante investimento de recursos financeiros, tempo e dedicação da
equipe de implementação. De acordo com Smith e Hinchcliffe (2004), esses recursos são empregados
prioritariamente para treinamento de pessoal e aquisição de novos equipamentos/instrumentos,
principalmente aqueles demandados pela manutenção preditiva. A falta desses recursos pode limitar as
ações do programa de MCC, culminando, na pior das hipóteses, com seu abandono.
115
Retorno do Investimento: o retorno do investimento no programa de MCC pode ser de longo prazo
3
.
Subestimar os investimentos financeiros ao longo do ciclo de vida da MCC, assim como seu tempo
de retorno, pode resultar na perda de apoio da alta gerência, descrédito e abandono do programa de
MCC (WORLEDGE, 1993).
Tempo: os objetivos da MCC são de longo prazo e o tempo necessário para sua implementação
pode ser longo, dependendo da complexidade do sistema, porém, as expectativas que antecedem o
programa de MCC são em geral imediatistas. Acomodar essas expectativas ao longo do ciclo de
vida do programa de MCC pode minimizar possíveis frustrações (BACKLUND, 2003).
Comprometimento: a MCC impõe mudanças internas que exigem o comprometimento da equipe de
manutenção e operação. A falta desse comprometimento pode inviabilizar as ações de manutenção e
desacreditar o programa de MCC (MOUBRAY, 2001).
Condições para Aprimoramento Contínuo: a MCC necessita de aprimoramento contínuo o que
pressupõe: realimentação; coleta de dados de falha; atualização dos mecanismos de detecção da
falha; e revisões periódicas do manual de MCC, entre outras ações que visam manter atualizado o
programa de MCC ao longo de todo o seu ciclo de vida (SMITH e HINCHCLIFFE, 2004).
Resultados e Benefícios: os resultados e benefícios de um programa de MCC devem ser analisados
sob diferentes perspectivas, dentre as quais destacam-se: dos interessados na empresa/sistema
“
stakeholders
” e suas expectativas; da quantificação dos resultados para avaliação e refinamento das
ações; dos benefícios para a empresa/sistema proporcionados pelo sucesso da implementação da
MCC; da melhoria na qualidade do produto e/ou serviço (BACKLUND, 2003).
A proposta deste trabalho vem preencher a lacuna existente entre a teoria, muitas vezes
simplista, e as situações práticas que podem inviabilizar um programa de MCC e que não encontram
respaldo nas normas de conduta. Não se trata, conforme explanado no Capítulo 1, de uma
metodologia para implantação da MCC, mas sim de uma metodologia para certificar a aderência da
empresa/sistema aos requisitos da MCC e a conformidade na implementação das etapas com as
normas e bibliografias pesquisadas.
Com isso pretende-se minimizar os riscos de insucesso dos programas de MCC, garantindo
sua aderência às necessidades da empresa/sistema e consonância com as boas práticas de
implementação e gestão. Nesse sentido, os seguintes mecanismos se complementam buscando
alcançar estes objetivos: o conhecimento heurístico de especialistas em implantação e gestão de
programas de MCC, incorporado no SBC-
Fuzzy
desenvolvido; ferramentas, baseadas em lógica
Fuzzy
, para diagnóstico e apoio a decisão tanto na fase anterior quanto posterior a implantação da
MCC; e relatórios de avaliação ponderando as características da empresa/sistema e as necessidades
da MCC, indicando ações de melhoramento sempre que possível.
3
A Taxa de Retorno do Investimento (ROI –
Return on Investment
) pode ser calculada pela seguinte equação:
ROI = (Investimento ÷ Lucro Líquido), assim, obtém-se o tempo necessário para se reaver o capital investido.
116
Para substanciar a metodologia proposta, os fatores críticos para o sucesso de um programa
de MCC devem ser investigados adotando-se de uma visão holística de sua relação com a
empresa/sistema. Assim será possível conceber critérios para confrontar as características da
empresa/sistema com os pré-requisitos necessários para um programa de MCC e também avaliar a
conformidade das tarefas executadas ao longo dos procedimentos de implementação.
Uma revisão criteriosa da literatura pesquisada revela que, apesar de algumas questões
técnicas corroborarem para o fracasso dos programas de MCC, o grande obstáculo para o sucesso
está nas questões gerenciais relacionadas com o entendimento da metodologia e o planejamento
para sua implantação (BACKLUND, 2003; MOUBRAY, 2001; SIQUEIRA, 2005; SMITH e
HINCHCLIFFE, 2004; WORLEDGE, 1993). Sendo assim, além dos aspectos específicos inerentes
às práticas normatizadas de implementação da MCC, a metodologia proposta analisa os fatores
críticos para o sucesso da MCC, sob os seguintes pontos de vista:
● Fatores gerenciais e técnicos da manutenção, incluindo a MCC como uma metodologia que
utiliza diferentes técnicas e ferramenta para análise de falhas e definição das ações de
manutenção;
● Fatores relacionados com a gestão de projetos, onde, por projeto entende-se a implantação e
a gestão do programa de MCC, incluindo os aspectos relacionados às mudanças internas.
Do ponto de vista gerencial e técnico da manutenção, os critérios a serem ponderados pelo
usuário contemplam os seguintes aspectos gerais:
● Estratégia de gerenciamento da manutenção ou dos ativos: tamanho da equipe, critérios para
planejamento, presença ou não de sistemas computacionais de suporte a manutenção;
● Desempenho da manutenção: ordens de serviço, tarefas acumuladas, técnicas de análise de
resultados e desempenho da equipe;
● Cultura da manutenção: nível de cooperação profissional, conservadorismo;
● Competência da equipe de implantação da MCC: habilidades, experiência, conhecimento da
metodologia, capacidade para implementação da MCC (disponibilidade de documentação,
sistema computacional de apoio, atendimento aos pré-requisitos de cada etapa e
conformidade da execução da etapa, atendimento a imposições normativas);
● Abordagem para análise do desempenho da MCC: preparação e coleta de dados, escopo,
nível de detalhamento adequado para a análise, padrões de desempenho desejados.
Do ponto de vista da gestão de projetos, os critérios a serem ponderados pelo usuário
contemplam os seguintes aspectos gerais:
● Planejamento inicial: limitações, foco, escopo, objetivos, considerações econômicas e de
adequação (conveniência);
● Abordagem e estratégia para implementação: abordagem e estratégias para curto e médio
prazo, estratégias para customizações, abordagem e estratégias para consolidação das etapas;
117
● Controle, monitoramento e avaliação do programa de MCC: planejamento e estruturação
para avaliação dos resultados e benefícios;
● Gestão de recursos: planejamento monitoramento e controle dos recursos financeiros,
humanos e de tempo para implementação do programa de MCC;
● Planejamento e preparação para gestão das mudanças internas: abordagem e estratégia para
conscientização, comprometimento, envolvimento, suporte, gestão das expectativas,
treinamento, resistências internas, sobrecarga de trabalho inicial, disponibilidade de
informação e transparência do processo.
Com foco nos aspectos técnicos e gerenciais, abordados neste item, e em exigências
normatizadas, será possível conceber os critérios que irão nortear a avaliação dos pré-requisitos e a
auditoria de cada uma das etapas da MCC.
5.6 ESTRATÉGIA PARA AVALIAÇÃO DOS PRÉ-REQUISITOS DAS ETAPAS DA MCC
Com o procedimento de referência para implantação da MCC, e a metodologia proposta
para seu diagnóstico, foi possível conceber uma estratégia para avaliar o grau de aderência da
empresa/sistema às necessidades da MCC, levando em conta os fatores críticos de sucesso citados
no item precedente, processo inverso ao proposto por Fuentes (2006). A estratégia proposta consiste
na ponderação de quesitos, os quais refletem: as competências e habilidades dos operadores,
mantenedores e da equipe de implementação da MCC; o comprometimento dos níveis gerenciais da
empresa com o programa de MCC; as características do sistema ao qual a MCC será implantada; e o
atendimento aos pré-requisitos de cada uma das etapas da MCC. A ponderação dos quesitos deve
ser conduzida de forma que todos os envolvidos na implementação das etapas da MCC,
pertencentes ou não à equipe de implementação, possam participar do processo.
Ao final do processo de ponderação dos quesitos, o que se tem são as informações sobre os
pontos fortes e fracos da empresa/sistema. Estas informações, em conjunto com o processo de
inferência do SBC-
Fuzzy
, irão balizar a avaliação dos seguintes aspectos: pontos que necessitam ou
não de melhoramentos para adoção da MCC; planejamento para implementação das etapas;
deficiências e/ou carências da equipe de implementação; otimizações possíveis no processo de
implementação das etapas; necessidades de apoio ou envolvimento institucional; e necessidades
operacionais, logísticas e estruturais;
A ponderação dos quesitos compõe a avaliação do critério correspondente que, em conjunto
com os demais critérios, da etapa sob análise, irão compor sua avaliação final. Esse processo de
avaliação e composição dos conjuntos
Fuzzy
correspondentes forma o relatório final de avaliação
dos pré-requisitos da etapa.
Os próximos itens explicitam os critérios e seus respectivos quesitos. A ponderação destes
quesitos subsidia o processo de inferência
Fuzzy
que resulta na avaliação dos critérios. Os
resultados individuais dessa avaliação disparam um novo processo de inferência para a avaliação de
118
cada uma das etapas do processo de implantação da MCC. Este processo de ponderação dos
quesitos e inferência
Fuzzy
para avaliação dos critérios e da etapa sob análise é válido para todas as
etapas, tanto para a análise dos pré-requisitos quanto para auditoria.
Especificamente na análise dos pré-requisitos, dois quesitos são comuns a todas as etapas,
os quais são (Apêndice F): a verificação de atendimento ao procedimento de referência para
implantação da MCC; e o desempenho atingido na auditoria da etapa anterior. O primeiro quesito
garante que a equipe de implementação da MCC dispõe das entradas, controles e mecanismos
exigidos pelo procedimento de referência. Assim, pode iniciar o processo de implementação da
etapa sob análise, estando preparada para cumprir com os objetivos da etapa e executar suas tarefas
inerentes. O segundo quesito garante que a etapa anterior foi implementada a contento e suas saídas
atingiram um grau mínimo de aderência ao procedimento de referência. Isto sugere que a equipe que
conduz o processo de implantação está apta a iniciar a implementação de uma nova etapa, utilizando
os resultados da etapa anterior.
5.6.1 Avaliação dos Pré-Requisitos da Etapa 0
A Etapa 0 foi assim nomeada por não constar em nenhuma bibliografia ou norma referente à
implantação da MCC. Entretanto, a pesquisa bibliográfica e a elicitação de conhecimento dos
especialistas, que antecederam a concepção da metodologia proposta, revelou que:
● Nem todas as empresas/sistemas estão preparadas para adotar a MCC como estratégia de
gestão da sua manutenção, e o fazem, muitas vezes, por questões mercadológicas ou
decisões intuitivas dos tomadores de decisão.
As questões mercadológicas estão relacionadas
principalmente com a aquisição de softwares proprietários de gestão da manutenção (CMMS
–
Computer Maintenance Management Systems
) os quais nem sempre atendem às
necessidades específicas de uma determinada empresa ou sistema. Decisões intuitivas são,
invariavelmente, parciais e não avaliam todo o contexto da aplicação e/ou empresa;
● Esta falta de aderência aos requisitos mínimos exigidos pela MCC resulta em falta de
comprometimento, descrédito e abandono do programa de MCC;
● Além da aderência da empresa/sistema aos requisitos exigidos pela MCC, deve haver
comprometimento da alta gerência, dos operadores, da equipe de implementação e recursos
financeiros e humanos para execução das etapas e implementação do programa de MCC.
Portanto, o objetivo da Etapa 0, conforme já explicitado no procedimento de referência, é
verificar se a MCC é adequada para a empresa/sistema em seu estágio atual de desenvolvimento e
estruturação. Os seguintes critérios compõem a avaliação dos pré-requisitos da Etapa 0:
Disponibilidade da Informação/Recursos; Condição e Desempenho Atual da Manutenção; Sistema
Computacional de Suporte; Cultura da Manutenção/Empresa; e Gerenciamento Estratégico da
119
Manutenção. Os próximos itens justificam os quesitos que constituem cada um dos critérios,
resumidos na Figura 5.12 e detalhados no Apêndice F.
Critério Quesito a ser Ponderado
● Aderência ao Procedimento de Referência
● Documentação da manutenção
● Documentação dos sistemas candidatos
→
Disponibilidade da
Informação/Recursos
● Planejamento estratégico da empresa
● Estratégia de manutenção
● Desempenho da manutenção
● Recursos humanos na operação
→
Condição e
Desempenho Atual da
Manutenção
● Custos da manutenção
● Automação de escritório
● Gestão da informação
● Gestão da manutenção
● Afinidade/Treinamento com o sistema
→
Sistema
Computacional de
Suporte
● Integração com outros sistemas
● Registro das ações de manutenção
● Função estratégica da manutenção
● Motivação da equipe
● Experiência metodológica
→
Cultura da
Manutenção/Empresa
● Atualização e auditoria
● Orçamento
● Conformidade organizacional
● Aporte de recursos
● Apoio metodológico
Etapa 0
Adequação da
MCC
→
Gerenciamento
Estratégico da
Manutenção
● Terceirização
Figura 5.12 – Avaliação dos Pré-Requisitos da Etapa 0.
Critério 1 (C1) – Disponibilidade da Informação/Recursos
Além do atendimento ao procedimento de referência, este critério analisa: a existência de
documentação adequada e consistente tanto das ações de manutenção quanto dos sistemas candidatos
a implantação da MCC; e a consistência do planejamento estratégico da empresa com relação à
manutenção.
A documentação das ações de manutenção torna as decisões da MCC mais próximas das
características da empresa, garantindo a inclusão dos modos de falha que já ocorreram no passado e
a reanálise das ações que se revelaram eficientes ou não. Neste caso, a inexistência de
documentação referente às ações de manutenção pode comprometer a efetividade da aplicação dos
diagramas de decisão da MCC.
120
A documentação do sistema é importante para a condução dos processos decisórios da
MCC, pois caso o mesmo seja complexo do ponto de vista tecnológico e/ou excessivamente
hierarquizado, podem ocorrer problemas na etapa de definição dos sistemas e identificação das
fronteiras e interfaces.
O apoio e o comprometimento institucional são importantes para o sucesso do programa de
MCC. Portanto, a inclusão da manutenção em seu planejamento estratégico espelha a visão da
empresa, e é um indício da pré-disposição de engajamento às novas propostas da MCC.
Critério 2 (C2) – Condição e Desempenho Atual da Manutenção
O objetivo deste critério é avaliar o estágio atual da equipe/setor de manutenção da empresa.
Como estratégia de manutenção, a MCC privilegia ações preditivas. Portanto, é importante
que a Empresa/Sistema no qual a MCC será implantada, tenha um histórico/experiência nesta
estratégia de manutenção para facilitar o processo de treinamento da equipe de manutenção.
Um desempenho homogêneo e satisfatório das ações de manutenção, além de uma equipe
preparada reflete, em geral, um conhecimento do sistema a ser mantido, o que é adequado às
necessidades da MCC. A falta de homogeneidade no desempenho da manutenção pode representar
um problema para a implantação da MCC em todo o Sistema/Empresa. Convém, neste caso,
escolher subsistemas onde este quesito seja o mais aderente possível e preparar adequadamente os
mantenedores.
Um número reduzido de pessoas envolvidas na operação do sistema, quando comparado a
sistemas fabris similares, pode indicar um elevado grau de automação. Neste caso, a MCC é
preferível frente a outras metodologias de gestão da manutenção (Ex.: TPM – Manutenção
Produtiva Total), uma vez que: o baixo número de operadores pode inviabilizar seu engajamento
como aliados da manutenção; e a automatização do sistema (Ex.: softwares de supervisão e
controle) pode auxiliar no registro histórico das falhas e geração de dados confiabilísticos e de
mantenabilidade, os quais são essenciais para a realimentação do programa de MCC.
Se os custos diretos e indiretos devidos à manutenção são altos, com o sistema atual de
gestão da manutenção, quando comparados a outros sistemas fabris similares, a implantação da
MCC pode ser vantajosa. Apesar do custo inicial da MCC ser alto, quando adotada em sistemas com
pouca manutenção preditiva, os custos totais tendem a diminuir ao longo do tempo (MOUBRAY,
2001). Entretanto, um estudo econômico/financeiro mais elaborado deve ser conduzido antes da
adoção da MCC, caso o fator econômico seja relevante, dado o tamanho e a complexidade do
sistema e a pouca ocorrência de ações preditivas.
121
Critério 3 (C3) – Sistema Computacional de Suporte
Este critério avalia as funcionalidades e a abrangência do sistema computacional da empresa
como ferramenta de suporte à gestão da manutenção bem como a afinidade dos mantenedores com
sua utilização.
Quanto à automação de escritório, segundo Siqueira (2005), a implantação da MCC não
exige muitos recursos, visto que bastam os programas tradicionais de processamento de textos,
planilhas eletrônicas e banco de dados. Para padronizar a análise, a empresa pode adotar softwares
específicos para implantação da MCC.
Algumas etapas do processo de implantação e gestão da MCC são muito dependentes de um
sistema de gestão da informação para apoio a tomada de decisão e as atividades de manutenção.
Neste caso, deve-se verificar se as ferramentas computacionais disponíveis atendem às necessidades
da MCC e se estão integradas com o restante da empresa.
A MCC baseia suas decisões em dados estatísticos de falhas, assim, pode haver benefícios
para o programa de MCC caso sistemas computacionais de gestão da manutenção já tenham sido
introduzidos e/ou são utilizados na empresa. Neste caso, deve-se verificar se tais sistemas suprem as
necessidades da MCC e se os dados disponíveis são confiáveis.
Os sistemas computacionais de apoio a MCC, tanto na fase de implantação como na fase de
gestão, só serão efetivos se a equipe de manutenção tem afinidade com os mesmos e o seu uso está
incorporado em suas práticas diárias, o que pressupõe que tal sistema deva ser de uso amigável.
Caso contrário, um programa de treinamento e conscientização dos mantenedores deve preceder a
implantação da MCC.
Para facilitar e garantir as boas práticas na condução do programa de MCC, o software
utilizado na gestão da manutenção deve ter as funcionalidades mínimas exigidas pela metodologia
MCC. Caso contrário o mesmo deve permitir a integração com softwares específicos para gestão da
MCC garantindo, assim, a padronização, realimentação e customização do programa de MCC,
dentro dos padrões vigentes.
Critério 4 (C4) – Cultura da Manutenção/Empresa
Este critério avalia a cultura e as práticas dos mantenedores na condução de suas atividades
e o envolvimento da empresa na gestão da manutenção.
Como a MCC baseia sua decisões em dados estatísticos de falhas, o registro das ações de
manutenção, de forma suficientemente detalhada para suportar uma análise estatística de tais ações,
tornará as decisões da equipe de implementação mais acertadas. Porém, cabe verificar a consistência
122
dos registros das ações de manutenção para garantir a confiabilidade das decisões da equipe de
implementação.
A implantação da MCC pressupõe mudanças de paradigmas dentro da empresa e do próprio
setor de manutenção, o que está fortemente atrelado ao apoio dos níveis gerenciais. Para tanto, a
manutenção deve ter uma função estratégica dentro da empresa e ocupar um lugar de destaque na
estrutura organizacional. O comprometimento de toda a empresa com o sucesso do programa de
MCC deve ser garantido ao longo de todo o seu ciclo de vida.
As mudanças de paradigmas impostas ao setor de manutenção, pelo programa de MCC,
exigem uma equipe e/ou setor de manutenção motivado e consciente de seu papel estratégico dentro
de empresa, para que tais mudanças sejam efetivas. Esta motivação e conscientização dos
mantenedores devem ser mantidas ao longo de todo o ciclo de vida do programa de MCC.
A experiência da equipe de manutenção com outras metodologias de gestão e sua evolução
para a MCC é benéfica para o sucesso do programa de MCC, facilitando o treinamento e a
assimilação dos conceitos pelos envolvidos no processo de implantação.
A sustentabilidade de um programa de MCC está fortemente atrelada à sua atualização e à
realimentação dos dados que nortearam suas decisões, com o objetivo de corrigir os desvios de
conduta e/ou o planejamento inicial. Além disto, há que se considerar o monitoramento e a auditoria
contínua do programa, por pessoal interno ou externo a empresa, para garantir a correta
implementação das etapas, na fase de implantação, e a correta condução do programa na sua fase de
execução.
Critério 5 (C5) – Gerenciamento Estratégico da Manutenção
Este critério avalia a política de gerenciamento da manutenção adotada pela empresa. Assim
é possível vislumbrar os obstáculos, facilidades e oportunidades que a equipe de implementação
encontrará.
Os custos iniciais para implantação da MCC dependem da estrutura já existente na empresa
e da complexidade do sistema ao qual será implementada. Deve-se considerar, entretanto, a
necessidade de uma previsão orçamentária para treinamento de pessoal dentro da filosofia da MCC,
viabilizar recursos humanos e implantar ações preditivas e sistemas computacionais de suporte a
MCC. Uma previsão orçamentária, anterior a implantação da MCC, é recomendada para avaliar o
aporte financeiro adequado.
As decisões da MCC podem estabelecer modificações na política de gestão dos ativos da
empresa, que vão desde serviços operacionais ou aumento de ações preditivas até mudanças de
projeto. Estas decisões devem estar em conformidade e ter suporte de outros setores da empresa.
123
Cabe a equipe de implementação uma avaliação cuidadosa para verificar as limitações impostas às
suas decisões e garantir o envolvimento de todos os setores da empresa afetados pelas decisões da
MCC, para anuência e comprometimento com tais decisões.
A MCC demanda investimentos contínuos em aprimoramento de ações preditivas e de
acompanhamento estatístico das ações de manutenção e das falhas funcionais. Os níveis gerenciais
da empresa devem considerar a manutenção como um investimento para viabilizar as necessidades
da MCC. Neste caso, cabe a equipe de implementação e aos executores do programa de MCC, a
proposição de um cronograma de investimentos que considere as limitações de investimentos na
MCC para adequar seus custos e maximizar os benefícios ao longo do seu ciclo de vida.
A MCC é parte de um processo geral/global de gerenciamento da manutenção, com
métodos e técnicas. Assim, além do comprometimento dos mantenedores, com o programa de
MCC, deve haver harmonia entre os diversos métodos e técnicas adotadas pelo setor de
manutenção. Os controles e mecanismos externos de suporte devem estar adaptados a estas
diversidades, garantindo sua sinergia e maximizando seus resultados.
A MCC pode não ser a melhor política de gestão da manutenção para toda a
empresa/sistema, neste caso outras metodologias de gestão da manutenção podem ser utilizadas em
paralelo ou integradas à MCC. Neste caso, um estudo prévio deve ser desenvolvido, para avaliar
qual a melhor política da gestão da manutenção que deve ser incorporada ou utilizada em paralelo
com a MCC, dadas as características da empresa/sistema.
A MCC é muito dependente de dados históricos e da experiência da equipe de manutenção.
Se grande parte da manutenção é terceirizada, antes da implantação da MCC, cabe uma avaliação
criteriosa dos aspectos relacionados à gestão do conhecimento. Caso a equipe terceirizada não esteja
adaptada às novas exigências do programa de MCC, presume-se uma revisão prévia dos contratos
de terceirização para garantir que estes requisitos sejam contemplados.
5.6.2 Avaliação dos Pré-Requisitos da Etapa 1
A Etapa 1 trata do planejamento para implantação da MCC e dos critérios e necessidades que
se interpõem na formação da equipe de implementação. Os seguintes critérios compõem a avaliação
dos pré-requisitos da Etapa 1: Disponibilidade da Informação/Recursos; Formação da Equipe;
Planejamento; Estratégia de Implementação.
Os próximos itens justificam os quesitos que constituem cada um dos critérios, os quais estão
resumidos na Figura 5.13 e detalhados no Apêndice F.
124
Critério Quesito a ser Ponderado
● Aderência ao Procedimento de Referência
● Auditoria da Etapa 0
● Apoio computacional
→
Disponibilidade da
Informação/Recursos
● Identificação dos sistemas candidatos
● Patrocinador interno
● Facilitador
● Disponibilidade e disposição da equipe
● Envolvimento e comprometimento das gerencias
→
Formação da Equipe
● Substituições
● Gestão de projetos
● Status do projeto de implantação
→
Planejamento
● Acúmulo de trabalho
● Contexto da empresa/sistema
● Projeto piloto
Etapa 1
Preparação
→
Estratégia de
Implementação
● Programas similares
Figura 5.13 – Avaliação dos Pré-Requisitos da Etapa 1.
Critério 1 (C1) – Disponibilidade da Informação/Recursos
Este critério avalia se a empresa/sistema possui um grau mínimo de requisitos para iniciar
o procedimento de implantação da MCC.
Um software comercial específico para implantação e gestão de programas de MCC pode
acelerar e padronizar o processo de implantação (SIQUEIRA, 2005). Neste ponto do processo de
implantação a equipe já tem noção do tamanho e complexidade dos sistemas candidatos à
implementação da MCC. Portanto, já tem condições de avaliar o custo benefício do uso de softwares
comerciais específicos para MCC ou de automação de escritório aliados ao software existente de
gestão da manutenção. Há que se considerar, neste caso, que softwares de apoio ao programa de MCC
não são utilizados somente na fase de implantação, mas também na sua fase de execução.
Algumas etapas da MCC exigem uma identificação única e inequívoca dos seus
itens/componentes para a organização da documentação e definição das fronteiras dos sistemas.
Assim, é importante, na etapa de preparação, certificar-se de que este pré-requisito esteja atendido,
caso contrário, é recomendável providenciá-lo para agilizar o processo de implantação. Siqueira
(2005) recomenda a utilização de um dos seguintes sistemas: Codificação Operacional; Codificação
Patrimonial; ou Codificação Hierárquica.
125
Critério 2 (C2) – Formação da Equipe
Além do conhecimento da metodologia, a implantação de um programa de MCC exige uma
equipe conhecedora do sistema no qual a MCC será implantada e em consonância com os objetivos
e cultura da empresa (MOUBRAY, 200; SIQUEIRA, 2005; SMITH E HINCHCLIFFE, 2004). A
equipe de implementação possui as seguintes responsabilidades: desenvolver e executar o programa
MCC para sistemas e instalações escolhidas; e estabelecer e gerir os recursos necessários à
sustentação do programa. Dependendo da instalação, a equipe de implementação será composta por
representantes das seguintes categorias profissionais: mantenedores da instalação; operadores da
instalação; inspetores de segurança; inspetores de qualidade; especialistas nos equipamentos;
fornecedores e fabricantes dos equipamentos; e laboratórios de ensaios. A complexidade e dimensão
do sistema serão determinantes na necessidade da participação destes representantes.
Este critério avalia as habilidades e competências da equipe de implementação e seus
substitutos, assim como o envolvimento e comprometimento da empresa.
A celeridade da implantação e a estruturação necessária para a equipe de implementação
estão fortemente atreladas à designação, por parte da empresa, de um patrocinador interno. É ele
que, legitimado pelos níveis gerenciais e com as atribuições requeridas, mobilizará os recursos
humanos e financeiros exigidos ao longo do processo de implantação.
A bibliografia pesquisada revela que muitos programas de MCC são desacreditados e
abandonados por erros conceituais e táticos cometidos ao longo do processo de implantação, por
exemplo: falta de clareza entre causa e modo de falha, falta de critérios para estabelecer a
abrangência da análise e falta de um projeto piloto (BACKLUND, 2003; BLANCO, 2007).
Portanto, é necessário que o facilitador do processo conheça profundamente a metodologia e, com
uma abordagem holística, conduza o processo respeitando os aspectos teóricos, normativos e
práticos da MCC. Ao facilitador cabe: aplicar a lógica MCC; conduzir a análise; conduzir as
reuniões; administrar o tempo; e administrar a logística. O sucesso do processo de análise
dependerá da competência do facilitador, o qual terá de atingir os seguintes objetivos: assegurar a
aplicação correta da MCC; buscar o consenso entre os participantes; garantir a avaliação dos itens
significantes; agilizar as reuniões de revisão; documentar adequadamente as etapas cumpridas; e
providenciar aprovação dos resultados. Ao facilitador compete também garantir a aderência dos
métodos de análise às necessidades do planejamento para implementação, limitando-se
estritamente ao escopo definido.
O envolvimento e comprometimento de toda a empresa no processo de implantação da
MCC são importantes para garantir seu sucesso na sua fase de execução. Para os níveis hierárquicos
inferiores é salutar manter um canal de comunicação que viabilize, entre outros: a coleta de
sugestões e informação sobre o sistema no qual a MCC será implantada; a divulgação das ações da
equipe de implementação; e a divulgação de mudanças nas regras de conduta e ações de
manutenção após a implementação do programa. O engajamento dos níveis hierárquicos superiores
126
garante, ainda: credibilidade; apoio logístico durante a fase de implantação; recursos financeiros
tanto na fase de implantação quanto na fase de execução do programa; e alinhamento com o
planejamento estratégico da empresa.
O processo de implantação da MCC é relativamente longo e, em algumas etapas, demanda
um conhecimento especializado e peculiar do sistema. Nestes e em outros casos, alguns membros da
equipe de implementação precisam eventualmente ser substituídos, seja por motivos alheios aos
interesses da equipe ou pela limitação de habilidades e competências em aspectos específicos, de
determinada etapa, do processo de implantação. Neste último caso pode ocorrer também a inclusão
de novos membros à equipe de implementação. Porém, em todos os casos há que se prever, no
início do processo, o treinamento adequado na metodologia MCC, para garantia sinergia dos novos
membros com o restante da equipe de implementação.
Critério 3 (C3) – Planejamento
A implantação da MCC exige uma decisão empresarial, não só pela importância das
mudanças, mas também pelo volume de recursos financeiros e humanos exigidos (SIQUEIRA,
2005). Portanto, segundo Blanco (2007), um planejamento estratégico detalhado e com uma visão
holística pode significar a diferença entre o sucesso e o fracasso do programa de MCC. Blanco
(2007) adverte também que, o planejamento deve ser executado tanto para o projeto piloto, quanto
para as expansões do programa de MCC.
Para organizar, garantir o comprometimento dos envolvidos e controlar o processo de
implantação é recomendável a utilização de uma metodologia de gestão de projetos para
implementação do programa de MCC. Esta metodologia deve estruturar a implementação levando
em conta o planejamento estratégico, tático e operacional da empresa, com relação ao sistema no
qual a MCC será implantada.
Além da contribuição na missão, objetivos e negócios da empresa, a implantação e uso da
MCC deverão constar como uma de suas diretrizes estratégicas. Em especial, a análise do ambiente
interno, deverá identificar se esta área constitui um dos pontos fortes da empresa ou se será
necessário buscar esta competência no mercado externo. Uma vez tomada a decisão, os objetivos e
metas deverão ser estabelecidos e acompanhados por indicadores e padrões de desempenho
específicos da manutenção. Os marcos de implantação em cada período de planejamento deverão
ser claramente estabelecidos e difundidos na empresa, sendo avaliados com as demais metas
estratégicas. Sem estas definições, a iniciativa não terá o respaldo necessário quando da
implementação nos níveis táticos e operacionais da empresa.
A implantação da MCC requer uma dedicação intensa dos membros da equipe de
implementação exigindo redução da carga normal de trabalho, proporcional a celeridade esperada
para implementação. Dentre as principais atividades, que demandam tempo e dedicação da equipe,
estão: definição do planejamento; busca de fonte de dados para embasar a tomada de decisão;
127
treinamentos; e reuniões para definição diversas em todas as etapas do procedimento de referência
para implementação da MCC. A liberação da equipe de implementação deve estar acordada com a
alta gerência. Isto ratifica o comprometimento da empresa e a importância do programa de MCC
podendo, também, facilitar o engajamento dos diversos setores no processo de implantação e
execução do programa.
Critério 4 (C4) – Estratégia de Implementação
A MCC pode utilizar várias estratégias de implementação. Entre as mais comuns, citam-se:
método de força-tarefa treinada, o qual consiste na seleção de um grupo de pessoas com a missão de
conduzir a análise em toda a empresa; método seletivo de instalações críticas, no qual se escolhe
apenas as instalações consideradas críticas para aplicação da metodologia; método abrangente de
instalações simultâneas, que consiste na implementação paralela com várias equipes de
implementação; e método do projeto piloto, que consiste na escolha de uma pequena instalação
onde será aplicada a metodologia, a título de teste e treinamento, antes de estender a implantação às
demais instalações. O projeto piloto é sempre recomendado no primeiro contato da empresa com um
programa de MCC. A escolha das demais estratégias depende do nível de maturidade e
desenvolvimento da engenharia de manutenção da empresa.
Algumas variações metodológicas de implementação são possíveis, entre as variantes mais
comuns estão (SIQUEIRA, 2005): validação da manutenção existente, onde são analisadas apenas as
tarefas atuais, dispensando-se a análise formal de todos os modos de falha da instalação e de outras
atividades preventivas possíveis; exclusão de modos de falha não críticos, onde são eliminados,
a
priori
, vários modos de falha considerados de difícil ocorrência; análise expedita por analogia, onde
são copiados os resultados da análise de instalações similares; e análise expedita por categorias, que
consiste na avaliação simultânea de uma classe de itens, considerados similares. Seja qual for a
variante metodológica, será necessário garantir o treinamento adequado dos responsáveis,
especialmente nas análises expeditas, para evitar desconhecimento do processo pelos responsáveis
pela execução da manutenção.
Para garantir o engajamento e comprometimento de toda a empresa com o programa de
MCC, a equipe de implementação deve tomar suas decisões com uma visão holística da
empresa/sistema. Assim, deverão ser levados em conta, entre outros: o contexto operacional do
sistema; a cultura da empresa em engenharia da manutenção e nos relacionamentos
interdepartamentais; o histórico de gestão do setor de manutenção e da empresa; e a política da
empresa com relação ao sistema no qual a MCC será implantada.
Conforme mencionado, a primeira implantação de MCC em qualquer empresa deve ser em
um projeto piloto de pequenas proporções. Isto produzirá resultados imediatos garantindo segurança
no processo e avaliação da metodologia, permitindo contornar as adversidades encontradas quando
da expansão para outros sistemas.
128
Programas de MCC similares auxiliam o processo de implantação, sobretudo nas análises
expeditas, reduzindo o tempo para implementação das etapas e auxiliando no dimensionamento
dos recursos humanos, financeiros, estruturais e logísticos. Entretanto, a equipe de implementação
deve estar preparada para a utilização de sistemas similares como benchmarking, a fim de evitar
desvios de conduta na implementação das etapas e insucessos na fase de execução do programa.
5.6.3 Avaliação dos Pré-Requisitos da Etapa 2
Ao iniciar o processo de implantação é possível que a equipe de implementação se depare
com a existência de diversos sistemas ou subsistemas onde a MCC poderia ser profícua. Entretanto,
em alguns casos, uma implantação de largo escopo, sem um amadurecimento em MCC por parte da
empresa, pode se mostrar ineficiente e propensa ao fracasso. Os seguintes motivos ratificam este
conceito: dificuldade de previsão orçamentária, resultando em falta de recursos humanos e
financeiros; força da cultura tradicional da empresa, que gera resistência para mudanças abruptas de
paradigmas; desistência devido ao volume intenso de trabalho; tempo longo para os primeiros
resultados, o que pode ensejar a desmotivação da equipe de implementação e dos mantenedores.
Portanto, não havendo um sistema pré-definido nesta etapa, deve-se estabelecer um
método multicritério para hierarquizar os sistemas candidatos, de modo a identificar qual o
sistema onde a implantação da MCC seja mais vantajosa. Identificado este sistema e suas
fronteiras, procede-se a sua documentação. Os seguintes critérios compõem a avaliação dos pré-
requisitos da Etapa 2: Disponibilidade da Informação/Recursos; e Estratégia de Seleção. Os
próximos itens justificam os quesitos que constituem os critérios, resumidos na Figura 5.14 e
detalhados no Apêndice F. Havendo de antemão um sistema de consenso, a aderência aos pré-
requisitos desta etapa também deve ser observada.
Critério Quesito a ser Ponderado
● Aderência ao Procedimento de Referência
● Auditoria da Etapa 1
● Dados confiabilísticos / mantenabilidade
● Custos dos sistemas candidatos
● Conhecimento da equipe de implantação
→
Disponibilidade da
Informação/Recursos
● Recursos financeiros
● Escopo e abrangência
● Similaridade com sistemas existentes
● Relação com o processo produtivo
● Documentação de engenharia
Etapa 2
Seleção do
Sistema e
Coleta de
Informações
→
Estratégia de Seleção
● Contexto operacional
Figura 5.14 – Avaliação dos Pré-Requisitos da Etapa 2.
129
Critério 1 (C1) – Disponibilidade da Informação/Recursos
Este critério avalia a disponibilidade das informações básicas e relevantes para a tomada de
decisão que fundamentará a estratégia para escolha do sistema ao qual a MCC será implantada.
Para selecionar, entre os sistemas candidatos, aquele no qual a MCC será implantada, a
norma IEC 60300-3-11 sugere que se leve em conta sua significância para a segurança,
disponibilidade e economia do processo. Métodos qualitativos e quantitativos podem ser utilizados,
baseados nas funções desenvolvidas pelos sistemas e em indicadores de criticidade e de
desempenho pertinentes ao processo. É indispensável, ainda, segundo esta norma, que sejam
documentados os métodos de seleção, os critérios utilizados e os resultados obtidos, iniciando-se
pela identificação dos sistemas.
Para que a tomada de decisão frente aos sistemas candidatos seja fundamentada
quantitativamente, é importante que os dados estatísticos de confiabilidade e mantenabilidade estejam
disponíveis e suportem uma análise estatística. Do mesmo modo, para maximizar os benefícios
advindos da implantação da MCC, é recomendável uma análise quantitativa dos custos atuais dos
sistemas candidatos para avaliar qual deles se beneficiaria mais com a implantação da MCC.
A fim de que as decisões da equipe de implementação sejam as mais acertadas possíveis,
tanto na escolha do sistema quanto na aplicação dos diagramas de decisão, é importante que a
mesma tenha um conhecimento profundo das questões técnicas, de segurança e ambientais
relacionadas aos sistemas candidatos. Em pontos específicos de aplicação da metodologia MCC,
caso este conhecimento se demonstre insuficiente, é recomendável agregar temporariamente à
equipe, pessoal com competência e habilidade para auxiliar a análise.
Nesta etapa é importante uma visão holística da implantação da MCC, para compatibilizar a
escolha do sistema com o planejamento estratégico da empresa com relação ao programa de MCC.
Deve-se prever, para todo o ciclo de vida do programa de MCC, os custos diretos e indiretos da
escolha de um ou outro sistema.
Critério 2 (C2) – Estratégia de Seleção
Neste critério, os quesitos a serem ponderados ratificam ou não os sistemas como
candidatos realmente consistentes a implantação da MCC. Os questionamentos servem para
alertar a equipe de implementação das características relevantes que o sistema deveria ter, para
minimizar o risco de insucesso da implantação da MCC. O que pode ocorrer em sistemas pouco
representativos ou com pouca documentação e informação.
O alinhamento ao planejamento estratégico da empresa não se resume apenas aos recursos
financeiros e humanos, conforme avaliado no quesito Q6 do critério 1 desta etapa (ver Apêndice F).
São importantes, também, para balizar a estratégia da seleção do sistema: os objetivos que se
pretende alcançar com a implantação da MCC; a abrangência das análises da MCC para o sistema; e
o conhecimento técnico e gerencial, sobre sistema, disponível na empresa.
130
A implantação da MCC pode ser abreviada se entre os sistemas candidatos houver algum
similar a outros, onde a MCC já foi implantada e os dados estão disponíveis para auxiliar a análise,
neste caso se poderá fazer a apropriação destes dados. Entretanto, Plucknette (2008) adverte que, a
apropriação de dados de sistema similares só poderá ser realizado quando as seguintes
circunstâncias ocorrerem concomitantemente: o item ou componente sob análise deve ser do mesmo
fabricante, modelo, material e estar sujeito ao mesmo ciclo operacional; as condições ambientais de
ambos os sistemas devem ser as mesmas; e os modos de falha específicos do local da instalação
devem ser considerados individualmente.
Os benefícios do programa de MCC são evidenciados quando: é forte a relação do sistema
com a disponibilidade do sistema global e economia do processo produtivo; e o sistema tem
implicações de segurança e/ou meio ambiente. É de se esperar, neste caso, que: haja também uma
maior documentação de engenharia do sistema, o que facilitará a definição de suas fronteiras,
subsistemas, itens e componentes para as análises requeridas pela MCC; e que se conheça mais
profundamente o contexto operacional do sistema facilitando, assim, a definição e a caracterização
das funções significantes e a programação das tarefas de manutenção.
5.6.4 Avaliação dos Pré-Requisitos da Etapa 3
A Etapa 3 do procedimento de referência trata da elaboração da FMECA para o sistema
escolhido na etapa anterior. Embora a FMECA seja uma metodologia consagrada para análise das
causas e dos efeitos dos modos de falha, algumas limitações de natureza administrativa e técnica
são observadas na sua aplicação prática. As questões administrativas segundo Antonietti (2002)
envolvem: dificuldades no relacionamento interpessoal; e falhas no planejamento e na condução
das reuniões. As questões técnicas, segundo Garcia (2006) envolvem: desconhecimento dos
aspectos teóricos e práticos da aplicação da metodologia de FMECA; falta de conhecimento
técnico dos participantes da equipe de condução da FMECA; e limitações diversas relacionadas à
atribuição dos fatores que compõem o índice de criticidade. Com o objetivo de minimizar os
inconvenientes citados anteriormente, os seguintes critérios integram a avaliação dos pré-
requisitos da Etapa 3: Disponibilidade da Informação/Recursos; e Competências e Habilidades da
Equipe. Os próximos itens justificam os quesitos que constituem cada um dos critérios, resumidos
na Figura 5.15 e detalhados no Apêndice F.
Critério 1 (C1) – Disponibilidade da Informação/Recursos
Este critério avalia os recursos disponíveis para agilizar as reuniões de FMECA e auxiliar a
equipe de implementação no levantamento das informações que compõem a planilha de FMECA.
131
Critério Quesito a ser Ponderado
● Aderência ao Procedimento de Referência
● Auditoria da Etapa 2
● Ferramenta computacional
● Documentação para FMECA
● Falhas funcionais e controles atuais
→
Disponibilidade da
Informação/Recursos
● Análise prévia (FTA / ETA)
● Conhecimento do sistema
● Treinamento
● Tamanho da Equipe x Modos de Falha
● Avaliação da criticidade (índices/critérios)
Etapa 3
Análise dos
Modos de
Falha, seus
Efeitos e sua
Criticidade
(FMECA)
→
Competências e
Habilidades da
Equipe
● Abrangência das causas e efeitos
Figura 5.15 – Avaliação dos Pré-Requisitos da Etapa 3.
O levantamento dos dados e preenchimento da planilha de FMECA é a atividade que
consome a maior parte do tempo na implantação da MCC. Durante a concepção da FMECA, para se
atingir um consenso sobre o assunto e elicitar o conhecimento/informação que irá compor as
planilhas, as abordagens tradicionais utilizam-se de reuniões e discussão em grupo. Estas reuniões
são, em geral, demoradas e tediosas e podem, eventualmente, prejudicar a análise. A utilização de
um software específico para MCC ou FMECA pode acelerar e padronizar a análise. Se este software
contar também com um ambiente virtual, onde não haja a necessidade de reuniões presenciais, os
especialistas envolvidos poderão programar melhor o seu tempo e sentirem-se mais à vontade para
proceder às análises, aumentando assim sua confiabilidade.
A análise da equipe de implantação deve incluir as proteções, instrumentação,
monitoramento e controle atrelados ao sistema. Muitas vezes, grande parte destas funcionalidades
está no software SCADA (
Supervisory Control And Data Acquisition
– Supervisão Controle e
Aquisição de Dados). Portanto, é importante que o sistema que será analisado pela equipe, conte
com uma documentação de engenharia consistente, para facilitar a análise e o preenchimento das
planilhas de FMECA. Pelo mesmo motivo, antes do início desta etapa, é importante dispor do
histórico de falhas funcionais e dos controles atuais para detectar e/ou prevenir as causas dos modos
de falha. A equipe de implementação pode se beneficiar também de análises prévias, como árvore
de falhas ou eventos (FTA e ETA respectivamente), que podem acelerar a execução da FMECA e
resultar em maior consistência nas decisões da equipe.
Critério 2 (C2) – Competências e Habilidades da Equipe
Este critério avalia o preparo da equipe de implementação para conduzir a FMECA.
132
O esquecimento de um modo de falha pode culminar com falhas imprevistas. As principais
causas deste problema são: uma equipe de FMECA mal estruturada ou que não tenha total domínio
do objeto de estudo do FMECA em questão e a desconsideração de causas relacionadas a pessoas,
métodos, equipamentos, materiais e ambiente. Durante a concepção da FMECA, a equipe de
implementação deve se certificar de que sua representatividade está adequada às análises
demandadas, com membros de todos os setores influenciados ou com influência nas decisões da
MCC (MOUBRAY, 2001; PALADY, 2004; SIQUEIRA, 2005; SMITH E HINCHCLIFFE, 2004;
STAMATIS, 1995).
Para garantir uniformidade de conhecimento da metodologia da FMECA, compreensão de
seus conceitos e a forma correta de preenchimento das planilhas, é importante que todos os
membros que participarão da sua execução tenham recebido treinamento adequado e específico em
FMECA, antes do início desta etapa.
A celeridade do processo de execução da FMECA, além da capacitação e conhecimento de
seus membros, está atrelada também ao número de pessoas envolvidas na sua execução. Siqueira
(2005) cita como exemplo que, em uma instalação típica
4
, a análise completa de cada modo de falha
leva em média 30 minutos. Cabe lembrar, também, que a demora do processo de implantação da
MCC pode postergar seus resultados, desmotivando as pessoas envolvidas e minando o
comprometimento dos níveis superiores da empresa ao programa de MCC. Os especialistas
envolvidos devem investir um número de horas relativamente elevado no desenvolvimento da
FMECA para detalhar adequadamente o sistema. Ambos os extremos envolvidos nesta questão são
preocupantes, os quais são (WIREMAN, 2005):
● Análises muito profundas (que tratam subsistemas inferiores ao menor item manutenível)
podem causar problemas gerenciais como: desmotivação da equipe, com reuniões tediosas
e custo dos especialistas envolvidos;
● Análises superficiais (que não tratam o menor item manutenível) podem esquecer modos
de falha ou efeitos importantes e comprometer a eficácia das ações recomendadas,
frustrando as expectativas de retorno do FMECA.
Portanto, antes da execução desta etapa, cabe a equipe de implementação certificar-se de
que sua composição está adequada ao tamanho do sistema e seu número de modos de falha.
A escala de valores, dos fatores que compõem a avaliação da criticidade (Severidade,
Ocorrência e Detecção), reflete de modo indireto a aceitabilidade da empresa aos efeitos do modo
de falha. Por esta razão, esta escala deve estar customizada para a empresa/sistema e aprovada pelos
níveis gerenciais. Além disto, as variáveis lingüísticas utilizadas devem ser consensuais entre os
especialistas do grupo de FMECA e demais envolvidos. Caso contrário, as análises da equipe de
4
Como instalação típica cita-se as subestações de energia e o tempo para a análise, neste caso, pressupõe a
utilização de recursos computacionais.
133
execução da FMECA podem resultar em avaliações equivocadas dos modos de falha, prioridades
incorretas e ações mal sucedidas que não impactarão da forma esperada no sistema sob análise.
Ações adicionais, além das previstas na FMECA, são invariavelmente necessárias nestes casos.
Alguns FMECA’s podem não atingir os objetivos esperados pela não compreensão de que
os modos de falha têm causas e efeitos tanto internos quanto externos à empresa, por exemplo:
atraso de fornecedores, problemas logísticos, danos ao meio ambiente, comprometimento do
processo produtivo do cliente, etc... (PALADY, 2004). Portanto, a equipe de execução da FMECA
deve estar preparada para, com uma visão holística, avaliar essas causas e efeitos internos e
externos, com influência no sistema a ser analisado.
5.6.5 Avaliação dos Pré-Requisitos da Etapa 4
A Etapa 4 exige da equipe de implementação, além de um conhecimento profundo do
sistema, uma definição clara e objetiva dos critérios para: identificar qual função é significante para
o sistema; e destas, como classificar seus modos de falha, em termos de evidência de sua ocorrência,
e os impactos na segurança, meio ambiente, economia e operação do processo produtivo.
Para facilitar a utilização dos diagramas de decisão que compõem a Etapa 4, sugere-se uma
avaliação da disponibilidade da informação e dos recursos que deveriam anteceder sua
implementação. Os próximos itens justificam os quesitos que constituem este critério, os quais estão
resumidos na Figura 5.16 e detalhados no Apêndice F.
Critério Quesito a ser Ponderado
● Aderência ao Procedimento de Referência
● Auditoria da Etapa 3
● Funções protegidas
● Critério de avaliação dos impactos
Etapa 4
Seleção das Funções
Significantes e
Classificação de seus
Modos de Falha
→
Disponibilidade da
Informação/Recursos
● Competência da equipe
Figura 5.16 – Avaliação dos Pré-Requisitos da Etapa 4.
Critério 1 (C1) – Disponibilidade da Informação/Recursos
Nesta etapa são selecionadas, com base no FMECA, as funções do sistema que seguirão na
análise da MCC e que, a partir desta etapa, serão denominadas de funções significantes. A perda de
tais funções caracteriza uma falha funcional, a qual provoca um efeito adverso para o sistema
principal, com conseqüências para: segurança, meio ambiente, operação e economia do processo
produtivo. A distinção destas conseqüências servirá para classificar as funções significantes.
134
Portanto, para implementação desta etapa a equipe deve ter um conhecimento profundo da relação
entre a função de cada subsistema, item ou componente com a falha funcional do sistema principal.
A reavaliação das funções atualmente protegidas por tarefas de manutenção garantem a
revisão do programa atual de manutenção e sua adequação a MCC. Assim, novos modos de falha
poderão ser descobertos e atividades desnecessárias de manutenção, do ponto de vista da MCC,
poderão ser eliminadas.
Os impactos de segurança, ambientais, econômicos e operacionais, admitidos pela equipe de
implementação, refletem a tolerância da empresa frente às conseqüências que um modo de falha
pode ter. Por exemplo, uma conseqüência mínima ao meio ambiente pode não ser suficiente para
classificar um modo de falha como: ESA (Evidente de Segurança e/ou Ambiental) ou OSA (Oculto
de Segurança e/ou Ambiental). Assim, a equipe pode preferir, em função da sua conseqüência,
classificá-lo como sendo: EEO (Evidente Econômico e/ou Operacional) ou OEO (Oculto
Econômico e/ou Operacional). Portanto, por ter alguma relação com a imagem e valores da
empresa, os critérios para definição dos impactos dos modos de falha devem passar pela apreciação
e aprovação dos níveis hierárquicos superiores e demais envolvidos com o sistema.
Para a MCC, a definição da significância das funções e a evidência ou não de um modo de
falha, seus efeitos ou a falha funcional a ele associada, está a cargo do operador/usuário do sistema,
o qual deve, portanto, fazer parte da equipe de implementação. A expressão evidente, referente ao
modo de falha, significa que não será necessário qualquer teste ou inspeção especial, diferente da
rotina operacional, para identificar o modo de falha ou suas conseqüências. A sinalização
automática pelo sistema de supervisão também caracteriza o modo de falha como evidente.
5.6.6 Avaliação dos Pré-Requisitos da Etapa 5
O objetivo da Etapa 5 é definir qual a tarefa de manutenção mais adequada para cada uma
das funções significantes classificadas na Etapa 4. Para a MCC, a escolha de uma tarefa de
manutenção depende de sua aplicabilidade e efetividade. Será aplicável se: prevenir os modos de
falha; reduzir a taxa de deterioração; detectar a evolução da falha; descobrir falhas ocultas; suprir
necessidades de consumíveis do processo; e reparar o item após a falha. Para ser efetiva deverá: ser
aplicável tecnicamente; ser viável com os recursos disponíveis; produzir os resultados esperados; e
ser executável a um intervalo razoável, em função do mecanismo da falha e com mínima
interferência na operação. Portanto, para que a equipe de implementação possa aplicar corretamente
os diagramas de decisão na escolha de tarefas aplicáveis e efetivas, para os modos de falha das
funções significantes, propõe-se os seguintes critérios para avaliação dos pré-requisitos desta etapa:
Disponibilidade da Informação/Recursos e Conhecimento da Falha. Os próximos itens justificam os
quesitos, resumidos na Figura 5.17 e detalhados no Apêndice F, os quais constituem a avaliação
destes critérios.
135
Critério 1 (C1) – Disponibilidade da Informação/Recursos
A escolha das tarefas de manutenção não deve estar baseada somente na sofisticação
técnica, mas também, entre outros indicadores: na redução da taxa de falhas; eficiência operacional;
e retorno financeiro. Este critério avalia a disponibilidade da informação e dos recursos para a
definição da aplicabilidade e efetividade das tarefas de manutenção.
Critério Quesito a ser Ponderado
● Aderência ao Procedimento de Referência
● Auditoria da Etapa 4
● Aplicabilidade e efetividade das tarefas
● Competência da equipe
→
Disponibilidade da
Informação/Recursos
● Custos da manutenção
● Mecanismo da falha
● Rotina operacional
Etapa 5
Seleção das
Tarefas de
Manutenção
Aplicáveis e
Efetivas
→
Conhecimento da
Falha
● Impacto na segurança e meio ambiente
Figura 5.17 – Avaliação dos Pré-Requisitos da Etapa 5.
Os critérios de aplicabilidade e efetividade das tarefas de manutenção dependem de recursos
humanos, financeiros e dos retornos esperados em relação a outras alternativas. Portanto, devem
estar alinhados com o planejamento estratégico da empresa com relação à manutenção. Daí a
necessidade de tais critérios passarem pela apreciação e aprovação dos níveis hierárquicos
superiores e demais envolvidos com o sistema.
A aplicabilidade e efetividade das tarefas de manutenção deverão ser atestadas pela equipe
de manutenção da empresa. Entretanto, algumas das tarefas de manutenção, podem ser classificadas
como sendo de serviço operacional e, neste caso, a ratificação de sua aplicabilidade e efetividade
deve contemplar a opinião de representantes da operação, uma vez que serão os operadores do
sistema, os responsáveis pela sua execução.
A análise da vantagem financeira de uma tarefa de manutenção em relação à outra, tem
relação direta com a aplicabilidade e efetividade da tarefa. Esta análise deve levar em consideração:
o orçamento do setor de manutenção; o planejamento para novas aquisições; o treinamento da mão
de obra; e os recursos logísticos.
Critério 2 (C2) – Conhecimento da Falha
Para ser aplicável e efetiva a tarefa de manutenção selecionada pela equipe de
implementação deve: respeitar os mecanismos da falha, ou seja: como a probabilidade de falha
evolui com a idade do item/sistema; o ciclo operacional do sistema; e os impactos produzidos pela
falha.
136
Conhecer o mecanismo da falha é essencial para a definição da aplicabilidade das tarefas de
manutenção, pois a tomada de decisão nestes casos dependerá, entre outros: da existência de algum
parâmetro mensurável relacionado com a evolução da falha; do aumento da probabilidade de falha
e/ou degradação ser função do tempo de operação e/ou idade; do intervalo entre a evolução da falha
potencial para funcional ser: consistente, monitorável de maneira prática e suficiente para uma ação
de manutenção o que garante, neste caso, também a efetividade da tarefa.
A rotina operacional do item/sistema está relacionada com a efetividade das tarefas de
manutenção, uma vez que, a eficiência operacional e os retornos financeiros associados são
indicadores que irão ratificá-la. Além disto, há também relação com a aplicabilidade das ações de
manutenção, pois os tempos entre falhas ou para reparo estão relacionados com a rotina operacional.
O impacto na segurança e meio ambiente, além de afetar a imagem da empresa, tem papel
fundamental na efetividade das tarefas de manutenção (SIQUEIRA, 2005). Uma falha terá impacto
na segurança e meio ambiente se: ameaçar a vida pessoal do operador; ameaçar a vida coletiva; e,
infringir uma lei ou padrão ambiental. Neste caso, além de ser aplicável, o único resultado aceitável
para a tarefa de manutenção é que ela garanta a redução da probabilidade de falha e aderência às
normas vigentes.
5.6.7 Avaliação dos Pré-Requisitos da Etapa 6
Nesta etapa, a equipe de implementação deve definir os intervalos iniciais e agrupar
adequadamente as tarefas de manutenção aplicáveis e efetivas, definidas na Etapa 5, com o objetivo
de otimizar o programa de MCC. Neste sentido, tanto a Norma SAE JA1011 quanto a IEC 60300-3-
11 reconhecem a importância dos métodos estatísticos para definição dos intervalos iniciais.
Entretanto, não havendo esta disponibilidade, cabe definir a freqüência das tarefas de manutenção
com base: nos dados históricos disponíveis, consenso, conhecimento heurístico dos mantenedores e
da equipe de implementação, e dados e recomendações do fabricante. Portanto, a Disponibilidade da
Informação/Recursos será utilizada como critério para avaliação dos pré-requisitos desta etapa. Os
próximos itens justificam os quesitos que o constituem, os quais estão resumidos na Figura 5.18 e
detalhados no Apêndice F.
Critério Quesito a ser Ponderado
● Aderência ao Procedimento de Referência
● Auditoria da Etapa 5
● Tomada de decisão (Questões Gerenciais)
● Tomada de decisão (Questões Técnicas)
Etapa 6
Definição dos Intervalos
Iniciais e Agrupamento
das Tarefas de
Manutenção
→
Disponibilidade da
Informação/Recursos
● Competências e habilidades da equipe
Figura 5.18 – Avaliação dos Pré-Requisitos da Etapa 6.
137
Critério 1 (C1) – Disponibilidade da Informação/Recursos
Independente da utilização de métodos qualitativos ou quantitativos, não há possibilidade de
definição dos intervalos iniciais e agrupamento de tarefas de manutenção de forma otimizada sem
que haja dados históricos, tanto gerenciais quanto técnicos e/ou conhecimento heurístico do sistema
e dos aspectos relacionados.
Os intervalos iniciais e as otimizações demandadas vão além dos requisitos técnicos
inerentes ao sistema. As questões gerenciais devem ser incluídas na análise, respeitando a visão
holística requerida da equipe de implementação (BLOOM, 2006). Dentro deste contexto, algumas
das questões relevantes são: tipo de processo (contínuo ou batelada); normas a serem atendidas
(Controle de Qualidade, Ambientais, Sanitárias, Segurança e Corporativas); ciclo de demanda do
mercado; e ciclo de suprimento de material de consumo. O comprometimento com tais questões irão
garantir que: os intervalos iniciais não violem nenhuma norma ou critério prático; e as
oportunidades de execução das tarefas de manutenção sejam aproveitadas para minimizar custos e
interferências no processo produtivo.
As informações técnicas inerentes ao sistema irão aumentar as chances de que as tarefas de
manutenção sejam executadas no momento mais adequado, técnica e economicamente. Neste caso,
agrupamentos de tarefas podem ser concebidos para otimizar os custos envolvidos. Este agrupamento
de tarefas e suas freqüências irão compor o manual de manutenção do sistema com base na MCC.
Para otimizar os intervalos iniciais e agrupamento de tarefas de manutenção, além das
informações técnicas e gerenciais do sistema, a equipe de implementação deve ter claros os
objetivos do programa de MCC e os aspectos a serem otimizados. Para isso, os integrantes da
equipe de implementação devem: conhecer e estar alinhados com o planejamento estratégico da
empresa, com relação à manutenção; e administrar os conflitos técnicos e gerenciais da otimização,
imbuídos da visão holística requerida.
5.6.8 Avaliação dos Pré-Requisitos da Etapa 7
Nesta etapa, a equipe de implementação deve garantir como pré-requisito, os recursos
humanos, financeiros e estruturais para: documentar e disponibilizar as informações geradas ao
longo do processo de implementação das etapas; treinar os mantenedores e operadores, dentro da
nova metodologia de gestão da manutenção proposta pela MCC; integrar as ações propostas pela
MCC no programa de gestão da manutenção da empresa/sistema; e estruturar o setor de
manutenção para execução do programa de MCC, incluindo suas realimentações e correções.
Os
seguintes critérios compõem a avaliação dos pré-requisitos da Etapa 7: Disponibilidade da
Informação/Recursos; e Planejamento para Implementação. Os próximos itens justificam os
quesitos que constituem cada um dos critérios, os quais estão resumidos na Figura 5.19 e
detalhados no Apêndice F.
138
Critério Quesito a ser Ponderado
● Aderência ao Procedimento de Referência
● Auditoria da Etapa 6
● Comprometimento da equipe
→
Disponibilidade da
Informação/Recursos
● Apoio computacional
● Recursos financeiros
● Treinamento no programa de MCC
Etapa 7
Redação do
Manual e
Implementação
→
Planejamento para
Implementação
● Integração MCC / Gestão da manutenção
Figura 5.19 – Avaliação dos Pré-Requisitos da Etapa 7.
Critério 1 (C1) – Disponibilidade da Informação/Recursos
Além dos recursos humanos, logísticos e estruturais, a implementação desta etapa, impõe
que as etapas anteriores tenham sido auditadas garantindo, assim, sua aderência ao procedimento de
referência e a disponibilidade das informações necessárias para compilação do manual da MCC.
Na fase de Redação do Manual e Implementação da MCC (Etapa 7) é possível que a equipe
de implementação já tenha se dispersado, dificultando a efetivação desta etapa. Um planejamento e
gestão adequados do processo de implantação é a solução para este problema. Este planejamento
deve garantir o engajamento de toda a equipe de implementação até a efetiva implantação do
programa de MCC no sistema de gestão da manutenção da empresa/sistema.
Nesta etapa, é importante dispor de uma estrutura computacional de apoio para geração do
manual da MCC, o qual deve contemplar todas as decisões e documentações geradas ao longo da
implementação das etapas (saídas do procedimento de referência). Caso softwares especializados
em MCC tenham sido utilizados é possível que estes, automaticamente, publiquem o manual, depois
de concluída cada etapa, e integrem as decisões tomadas ao sistema de gestão da manutenção. Caso
contrário deve-se garantir que estas tarefas sejam executadas pela equipe com os recursos
computacionais disponíveis.
Critério 2 (C2) – Planejamento para Implementação
Segundo Siqueira (2005), todos os erros da fase de implementação do programa de MCC,
podem ser atribuídos a falhas de planejamento e condução das etapas. Para que o programa de MCC
cumpra seus objetivos, é necessário garantir, antes da sua efetiva implantação: os recursos para
implementaçao das ações propostas pela MCC; e o treinamento do pessoal dentro da nova proposto
de gestão da manutenção.
Durante o processo de implantação da MCC, a equipe de implementação optou por
determinadas tarefas de manutenção em prazos otimizados. Cabe a esta etapa, a ratificação e a
realização dos recursos financeiros, humanos e de equipamentos que supram, da maneira inicialmente
139
concebida, as necessidades do programa de MCC. Além dos recursos humanos e materiais, há que se
implementar nesta etapa os mecanismos de controle e monitoramento do programa de MCC para
assegurar sua realimentação e correção de decisões mal sucedidas ou incorretas.
A fim de que o programa de MCC cumpra com seus objetivos, o planejamento deverá
pressupor o treinamento dos mantenedores e operadores dentro da nova metodologia proposta pela
MCC. A carga horária e o conteúdo deste treinamento dependem do grau de amadurecimento da
empresa. Para os mantenedores, os seguintes itens devem ser contemplados: as diferenças entre o
programa de manutenção anterior e o atual; as novas documentações exigidas e seus padrões de
preenchimento; a importância da documentação para o sucesso do programa; e a maneira prevista
para reportar as inconsistências e erros do programa de MCC. O treinamento dos operadores deve
contemplar as tarefas, classificadas no programa de MCC, como sendo de serviço operacional, ou
seja, tarefas cuja responsabilidade é do operador, o qual deverá receber no mínimo: instruções
detalhadas, considerando não ser a especialidade do operador a execução da manutenção;
treinamento adequado para entender os objetivos das atividades e como executá-las; motivação e
compensação para garantir a mudança cultural necessária à atividade; meios de comunicação para
relatar em tempo as anormalidades além de sua capacidade de solução e inclusão no sistema de
gerenciamento da manutenção; padrões de documentação para registro dos resultados, segundo os
modelos operacionais adotados na instalação; padrões de desempenho definidos com clareza para
facilitar o julgamento do operador; e recomendações para exceções, quando o item não atender ao
padrão de desempenho.
O processo de implementação da MCC pressupõe a integração das atividades recomendadas
com o sistema de gestão da manutenção da empresa, e à rotina das equipes executivas de
manutenção e operação. A integração ocorre através do plano de manutenção gerado pela MCC.
Softwares específicos para implantação da MCC automatizam este procedimento. Entretanto, caso o
mesmo não esteja disponível, a equipe de implementação deve providenciar recursos humanos e
operacionais para execução deste pré-requisito.
5.6.9 Avaliação dos Pré-Requisitos da Etapa 8
Conforme o procedimento de referência, esta etapa pertence à fase de execução do
programa de MCC. Portanto, a equipe de implementação ou os encarregados pela execução desta
etapa, que não participaram, necessariamente, da implementação da MCC, devem garantir os
recursos humanos, financeiros e estruturais para acompanhar e realimentar o programa de MCC, ao
longo de todo o seu ciclo de vida. Como critérios de aderência aos pré-requisitos desta etapa, cabe
verificar se: a gestão da manutenção está aderente às propostas do programa de MCC; e se as
informações e recursos estão disponíveis para planejar e executar a estratégia de coleta das
informações necessárias para o acompanhamento e a realimentação do programa de MCC. Os
140
próximos itens justificam os quesitos que constituem cada um destes critérios, os quais estão
resumidos na Figura 5.20 e detalhados no Apêndice F.
Critério Quesito a ser Ponderado
● Aderência ao Procedimento de Referência
● Auditoria da Etapa 7
→
Disponibilidade da
Informação/Recursos
● Divulgação e fidelidade do manual
● Índices de desempenho
● Incorporação do programa de MCC
● Normatização e controle
Etapa 8
Acompanhamento
e Realimentação
→
Aderência da MCC
● Redimensionamento de recursos
Figura 5.20 – Avaliação dos Pré-Requisitos da Etapa 8.
Critério 1 (C1) – Disponibilidade da Informação/Recursos
Além
da aderência ao procedimento de referência e o grau de conformidade da etapa anterior,
quesitos comuns às demais etapas, e
ste critério avalia também: a abrangência da divulgação do
manual de MCC; e a conformidade do programa de manutenção da empresa, para o sistema no qual
a MCC foi implantada, com as recomendações do manual.
A divulgação e a fidelidade do manual de MCC garante que o pessoal envolvido ou com
influência nas atividades da manutenção, os quais não participaram da equipe de implementação,
tenham acesso às decisões. Assim, será possível atingir o engajamento da empresa no programa de
gestão da manutenção e a incorporação do mesmo nas práticas diárias dos operadores e
mantenedores.
Critério 2 (C2) – Aderência da MCC
Este critério verifica a aderência da MCC na empresa/sistema, pré-requisito básico para que
os responsáveis pela fase de execução possam definir uma estratégia fundamentada em indicadores
de desempenho para efetivar o acompanhamento e a realimentação do programa de MCC.
O desempenho do programa de MCC está relacionado à sua completude e à exatidão e
eficácias das ações por ele propostas. Para que este desempenho seja revertido em uma vantagem
competitiva para a empresa, motivando o apoio institucional, há de se garantir a aderência do
programa de MCC e progressos mensuráveis nas ações da manutenção. O acompanhamento deste
desempenho pode ser efetivado através da utilização de indicadores, os quais devem estar alinhados
com os objetivos e interesses do programa de MCC e com a visão holística da empresa, condição
esta que garantirá a confiabilidade e abrangência dos dados mensurados.
Para que os benefícios do programa de MCC sejam evidenciados é necessário garantir sua
inclusão irrestrita à rotina dos mantenedores e operadores, o que passa também pela sua
141
incorporação ao sistema de gestão da manutenção da empresa/sistema. Contemplado este pré-
requisito, é possível monitorar e realimentar o programa de MCC a partir de seus indicadores de
desempenho e corrigir suas inconsistências e equívocos.
Para garantir o cumprimento do programa de MCC, o mesmo deve fazer parte da
normatização da empresa, com previsão de ações disciplinadoras ou corretivas, caso haja quebra de
procedimentos. O objetivo é suplantar os vícios das culturas tradicionais de manutenção e dos
procedimentos anteriores a implantação da MCC e que não se enquadram na nova proposta de
gestão da manutenção.
Tanto o sistema de gestão da manutenção, quanto os recursos logísticos da empresa, podem
não estar condizentes com as ações propostas pela MCC. A freqüência e o monitoramento requerido
das tarefas, assim como a logística de apoio à manutenção devem ser avaliadas e, caso necessário,
deve-se proceder ao redimensionamento do sistema de gestão da manutenção e do apoio logístico
para atender as novas necessidades determinadas pelo programa de MCC.
5.7 ESTRATÉGIA PARA AUDITORIA DAS ETAPAS DA MCC
Assim como na avaliação dos pré-requisitos, a auditoria também será processada a partir da
ponderação de quesitos, os quais irão compor a avaliação dos critérios correspondentes que, em
conjunto com os demais critérios da etapa sob análise, irão compor sua avaliação final. Este
processo de avaliação e composição dos conjuntos
Fuzzy
correspondentes fará parte do relatório
final de auditoria da etapa.
A necessidade da auditoria, nos moldes propostos neste trabalho, nasceu durante a fase de
aquisição do conhecimento, ao se constatar que muitos dos fatores de insucesso, de alguns
programas de MCC, ocorreram devido a: falhas e/ou inconsistências na implementação das etapas; e
falta do rigor normativo que a metodologia pressupõe. Assim, uma auditoria para certificar a
conformidade da execução da etapa, com o procedimento de referência, surgiu como pré-requisito
para evitar os fatores de insucesso relatados na bibliografia e durante a elicitação do conhecimento
junto aos especialistas.
Por se tratar de uma auditoria interna e posterior a implementação de cada etapa, pressupõe-
se que a condução do processo de auditoria, com auxílio do SBC-
Fuzzy
proposto, fique a cargo da
equipe de implementação e demais envolvidos e/ou afetados pelo programa de MCC.
Na estratégia proposta para auditoria, os quesitos submetidos à ponderação do usuário pelo
SBC-
Fuzzy
refletem: a conduta esperada da equipe de implementação, antes e durante a execução
das tarefas da etapa; e os atributos desejáveis ao final da implementação da etapa analisada, para que
a mesma cumpra as exigências do procedimento de referência. A partir da ponderação dos quesitos,
com base nas práticas adotadas e nos resultados obtidos pela equipe de implementação, obtém-se
uma imagem da conformidade e atributos da etapa, com indicadores de pontos de excelência e
deficiência, os quais servirão para: reformular o planejamento das atividades de implementação da
142
MCC; rever a execução da etapa; avaliar e comparar, os atributos da etapa implementada, com as
melhores práticas; alertar a equipe de implementação sobre a necessidade de melhorias; apontar
oportunidades para melhorias no processo de implantação da MCC; e acompanhar e aferir o
progresso do planejamento inicial.
Os critérios e seus respectivos quesitos, submetidos à ponderação do usuário, foram
concebidos com base nos seguintes princípios, a saber: heurísticas explicitadas durante o processo
de elicitação do conhecimento; relatos e conceitos manifestados na literatura, artigos pesquisados e
congressos; e normas IEC 60300-3-11, SAE JA1011 e SAE JA1012, condição necessária para o
respaldo normativo exigido de um processo de auditoria.
O critério de Confiabilidade da Análise (C1) e seus 3 primeiros quesitos são comuns a todas
as etapas, os quais são (Apêndice F): a comprovação do grau de atendimento aos pré-requisitos da
etapa; a conformidade com as saídas do procedimento de referência para implantação da MCC; e a
credibilidade da tomada de decisão. O primeiro quesito (Q1) certifica-se de que, os pré-requisitos da
etapa foram respeitados, caso não tenham sido, uma política de melhoramento dos fatores negativos
foi planejada e implementada, ambas as situações aumentam as chances de sucesso durante a
implementação da etapa. O segundo quesito (Q2) garante que a equipe atentou para a documentação
das decisões tomadas durante a implementação da etapa, a qual cumpre com as exigências de saída
do procedimento de referência, contemplando todos os subsídios necessários para as próximas
etapas. O terceiro quesito (Q3) trata da abrangência da tomada de decisão, a qual não deve ficar
restrita à equipe de implementação, mas sim contemplar o maior número possível de pessoas e/ou
setores envolvidos e/ou afetados pela implantação da MCC. Os próximos itens elucidam os critérios
e seus respectivos quesitos, que compõem a auditoria de cada etapa.
5.7.1 Auditoria da Etapa 0
Conforme mencionado na avaliação dos pré-requisitos, esta etapa não consta em nenhuma
bibliografia ou norma referente à implantação da MCC, entretanto, sua correta execução é essencial
para ratificar a conformidade dos objetivos e características institucionais com as exigências de um
programa de MCC. O critério que fundamentará a auditoria da Etapa 0 é a confiabilidade da análise
desenvolvida durante a execução da etapa. O próximo item justificam os quesitos que constituem o
critério de análise, resumido na Figura 5.21 e detalhado no Apêndice F.
Critério 1 (C1) – Confiabilidade da Análise
Além dos quesitos 1 a 3, já explicitados, os quesitos 4 e 5 verificam o grau de
conhecimento da equipe de implementação, dos benefícios e desafios de programas consolidados
de MCC, seja a partir de pesquisa bibliográfica e consulta a especialistas ou contato com
programas na fase de execução em instalações similares.
143
Critério Quesito a ser Ponderado
● Atendimento aos pré-requisitos
● Atendimento ao Procedimento de Referência
● Credibilidade da tomada de decisão
● Referencial teórico e prático
Etapa 0
Adequação da
5.7.2 Auditoria da Etapa 1
Os próximos itens justificam os quesitos que constituem cada um dos critérios que compõem a
auditoria da Etapa 1, os quais estão resumidos na Figura 5.22 e detalhados no Apêndice F.
Critério 1 (C1) – Confiabilidade da Análise
Este critério avalia se a etapa de preparação levou em consideração: o comprometimento dos
envolvidos direta ou indiretamente com os procedimentos de implantação e sua concordância com a
possibilidade de execução do plano de implantação, da maneira como concebido; e a visão holística
do contexto organizacional e seu envolvimento na concepção do plano de implantação. Estes fatores
são importantes para: garantir o engajamento dos setores da empresa afetados pelo programa de
MCC
→
Confiabilidade da
Análise
● Benchmark
Figura 5.21 – Auditoria da Etapa 0.
Critério Quesito a ser Ponderado
● Atendimento aos pré-requisitos
● Atendimento ao Procedimento de Referência
● Credibilidade da tomada de decisão
● Aprovação do planejamento
● Contextualização à empresa
→
Confiabilidade da
Análise
● Envolvimento dos interessados e/ou afetados
● Definição de responsabilidades
● Gestão da informação e divulgação dos resultados
● Atribuições do patrocinador interno
→
Recursos e
Responsabilidades
● Experiência de sistemas similares
● Participação em treinamento
● Execução de projeto piloto
● Conhecimento em gestão de projetos
→
Competências e
Habilidades da
Equipe
● Substituições com equidade de conhecimento
● Credibilidade do planejamento
● Disponibilidade da equipe
● Aderência ao projeto piloto
Etapa 1
Preparação
→
Certificação das
Decisões
● Documentação e divulgação
Figura 5.22 – Auditoria da Etapa 1.
144
MCC; evitar frustrações da equipe durante a implementação; e acomodar as expectativas de longo
prazo do programa de MCC.
Critério 2 (C2) – Recursos e Responsabilidades
Os quesitos deste critério avaliam se durante a etapa de preparação, os seguintes itens foram
contemplados: a composição da equipe, quanto ao seu tamanho (quantidade de pessoas), suas
funções e suas atribuições; e os recursos disponíveis para gestão e divulgação dos resultados dos
procedimentos de implementação das etapas. Estes elementos têm relação com o comprometimento
e envolvimento da equipe com os procedimentos de implementação das etapas, além de afetar a
celeridade e a organização do processo de implantação.
Critério 3 (C3) – Competências e Habilidades da Equipe
Este critério avalia se a equipe, formada ao longo da etapa de preparação, tem o conhecimento
e a experiência desejável para execução dos procedimentos de implementação da MCC e se houve a
preocupação com a garantia
da equidade de conhecimento, em caso de troca de algum membro da
equipe. A aderência a estes quesitos contribuirá para: aumentar a confiabilidade das decisões, tomadas
ao longo dos procedimentos para implementação das etapas; e organização do processo de
implantação da MCC, com base em técnicas consagradas de gestão de projetos.
Critério 4 (C4) – Certificação das Decisões
O objetivo deste critério é avaliar a confiabilidade do planejamento e das decisões tomadas
durante a Etapa 1. Um bom desempenho nos itens avaliados neste critério indica que a equipe de
implementação, quando do planejamento para implantação da MCC: aplicou adequadamente os
preceitos da gestão de projetos; priorizou o projeto de implantação da MCC, o que eleva seu status
dentro da empresa; utilizou os ensinamentos do projeto piloto anteriormente conduzido pela
equipe/empresa; e documentou e divulgou o planejamento para implantação de MCC, criando
mecanismos para atribuição de responsabilidades e mensuração do desempenho da equipe de
implementação.
5.7.3 Auditoria da Etapa 2
Os próximos itens justificam os quesitos que constituem cada um dos critérios que compõem a
auditoria da Etapa 2, os quais estão resumidos na Figura 5.23 e detalhados no Apêndice F.
145
Critério Quesito a ser Ponderado
● Atendimento aos pré-requisitos
● Atendimento ao Procedimento de Referência
● Credibilidade da tomada de decisão
● Conseqüências ambientais, de segurança e econômicas
→
Confiabilidade
da Análise
● Confiabilidade e Mantenabilidade
● Definição, descrição e documentação do sistema escolhido
● Consenso na escolha do sistema
● Conhecimento sobre o sistema escolhido
Etapa 2
Seleção do
Sistema e Coleta
de Informações
→
Certificação
dos Resultados
● Tamanho da equipe x Escopo e nível de detalhamento
Figura 5.23 – Auditoria da Etapa 2.
Critério 1 (C1) – Confiabilidade da Análise
O objetivo d
os quesitos 4 e 5 deste critério, além dos quesitos 1 a 3, já explicitados, é
certificar-se de que o sistema selecionado, dentre os sistemas candidatos para implantação da MCC,
possui os seguintes atributos: é aquele cuja falha funcional resulta nos maiores impactos para a
segurança e o meio ambiente; e/ou a falha funcional tem maior conseqüência econômica para a
empresa e para o processo produtivo; e/ou é aquele cuja abordagem quantitativa resultou em baixos
índices de confiabilidade e mantenabilidade.
Critério 2 (C2) – Certificação dos Resultados
O objetivo deste critério é verificar a consistência técnica e organizacional da tomada de
decisão que resultou na escolha do sistema no qual a MCC será implantada. Os principais aspectos
que podem impactar negativamente um programa de MCC e que, por esta razão, foram tratados
neste critério são: a documentação das decisões tomadas na etapa 2 referente ao sistema escolhido,
incluindo o nível de análise que será adotado; a ratificação das competências e habilidades da equipe
de implementação e da empresa, para desenvolver as análises requeridas nos procedimentos de
implantação da MCC; e a confirmação de que o sistema escolhido é o mais adequado e de que o
tamanho da equipe de implementação está adequado à complexidade do sistema escolhido.
5.7.4 Auditoria da Etapa 3
Os próximos itens justificam os quesitos que constituem cada um dos critérios que compõem a
auditoria da Etapa 3, os quais estão resumidos na Figura 5.24 e detalhados no Apêndice F.
146
Critério Quesito a ser Ponderado
● Atendimento aos pré-requisitos
● Atendimento ao Procedimento de Referência
● Credibilidade da tomada de decisão
● Atualizações e correções da FMECA
→
Confiabilidade
da Análise
● Conexão entre FMECA e plano de ação
● Nível de mantenabilidade
● Contexto operacional
● Identificação e documentação das funções
● Padrão de desempenho
→
Itens, Funções e
Falhas
Funcionais
● Documentação das falhas funcionais
● Documentação
● Nível de causalidade
● Modos de falha conhecidos, protegidos ou factíveis
● Eventos/Processos que podem resultar em uma falha
→
Modos de Falha
● Modos de falha externos a empresa/sistema
● Descrição dos efeitos
● Descrição dos efeitos x Avaliação da falha
● Danos e restauração da função
Etapa 3
Análise dos
Modos de Falha
seus E eitos e sua
Criticidade
(FMECA)
→
Efeitos e Causas
da Falha
● Descrição das causas
f
Figura 5.24 – Auditoria da Etapa 3.
Critério 1 (C1) – Confiabilidade da Análise
O objetivo d
os quesitos 4 e 5 deste critério, além dos quesitos 1 a 3, já explicitados, é
certificar-se de que a equipe de implementação previu: um procedimento documentado para
atualizar e corrigir eventuais distorções da FMECA; e um plano de ação a ser seguido na ocorrência
de um modo de falha. Estes quesitos irão garantir, na medida da sua atualização, a credibilidade da
FMECA e com procedimentos padronizados, ações mais rápidas e efetivas quando na ocorrência de
um modo de falha.
Critério 2 (C2) – Itens, Funções e Falhas Funcionais
Este critério verifica o correto preenchimento das colunas Item, Função e Falha Funcional
da FMECA e assegura que: o nível de mantenabilidade dos itens relacionados é o menor possível;
em nenhum caso faltou definir o contexto operacional (item 5.1.1 da SAE JA1011); não há exclusão
de funções (item 5.1.2 da SAE JA1011) e o formato de definição das funções está adequado (item
5.1.3 da SAE JA1011); não há funções com padrões de desempenho não aprovadas pelo usuário ou
147
proprietário (item 5.1.4 da SAE JA1011); e os estados de falha da função não estão incompletos ou
são incompatíveis com a definição da função (item 5.2 da SAE JA1011).
Critério 3 (C3) – Modos de Falha
Este critério verifica, por meio de seus quesitos, a consistência dos modos de falha incluídos
na FMECA. Assim, é possível evitar alguns dos fatores críticos na confecção da FMECA, os quais
estão relacionados com: o excesso de modos de falha, podendo resultar em reuniões de FMECA
tediosas e com a inclusão de modos de falha pouco significativos em termos estatísticos; ou o
esquecimento de modos de falha importantes, causado pela simplificação extremada do problema,
resultando em um FMECA sem aplicação prática. Com os quesitos avaliados neste critério, os
seguintes problemas são evitados: exclusão de modos de falha prováveis ou inclusão de modos de
falha improváveis na visão do usuário ou proprietário (itens 5.3.1 e 5.3.2 da SAE JA1011); inclusão
de modos de falha inadequados para identificação da política de gestão da falha (item 5.3.3 da SAE
JA1011); exclusão de modos de falha já ocorridos, atualmente gerenciados por programas de
manutenção ou que jamais ocorreram, mas que possuem uma probabilidade de ocorrência razoável
(item 5.3.4 da SAE JA1011); exclusão de modos provocados por operadores, mantenedores ou
oriundos de falha de projeto ou deterioração (item 5.3.5 da SAE JA1011); e exclusão de modos de
falha de origem externa a empresa ou sistema sob análise.
Critério 4 (C4) – Efeitos e Causas da Falha
O objetivo deste quesito é verificar se as descrições dos efeitos e das causas dos modos de
falha estão adequadas para suprir as informações necessárias às etapas seguintes do processo de
implementação. Além disto, é objeto deste critério certificar-se de que os seguintes erros de
implementação não foram cometidos: descrição do efeito amenizado por tarefa de manutenção
existente (item 5.4.1 da SAE JA1011); descrição do efeito insuficiente para avaliar as
conseqüências do modo de falha (itens 5.4.2a, 5.4.2b e 5.4.2c da SAE JA1011); descrição dos
efeitos insuficiente para definir os danos físicos e a conduta para recomposição do sistema (itens
5.4.2d e 5.4.2e da SAE JA1011); e se as causas do modo de falha não contribuem para identificar
porque o mesmo ocorreu.
5.7.5 Auditoria da Etapa 4
Os próximos itens justificam os quesitos que constituem cada um dos critérios que compõem a
auditoria da Etapa 4, os quais estão resumidos na Figura 5.25 e detalhados no Apêndice F.
148
Critério Quesito a ser Ponderado
● Atendimento aos pré-requisitos
● Atendimento ao Procedimento de Referência
● Credibilidade da tomada de decisão
→
Confiabilidade da
Análise
● Visão holística
● Caracterização dos modos de falha
● Avaliação das conseqüências
● Ratificação das funções significantes
Etapa 4
Seleção das
Funções
Significantes e
Classificação de
seus Modos de
Falha
→
Certificação dos
Resultados
● Funções não significantes
Figura 5.25 – Auditoria da Etapa 4.
Critério 1 (C1) – Confiabilidade da Análise
O
quesito 4 deste critério, além dos quesitos 1 a 3, já explicitados, tem o objetivo de
assegurar que a visão holística necessária ao processo de implantação da MCC foi preservada,
durante a definição das funções significantes, e os seguintes aspectos foram levados em conta:
prejuízos para a imagem da empresa, usuários, clientes ou terceiros causados pela perda da
função.
Critério 2 (C2) – Certificação dos Resultados
O objetivo deste critério é verificar se a seleção das funções significantes e a classificação
de seus modos de falha foi conduzida adequadamente, segue os preceitos normativos vigentes, e
os seguintes aspectos foram evitados: falta de separação das conseqüências das falhas
ocultas/evidentes, segurança/ambientais e econômicas/operacionais (itens 5.5.1.1 e 5.5.1.2 da SAE
JA1011); conseqüências alteradas por tarefa de manutenção existente (item 5.5.2 da SAE JA1011);
a definição de função significante não segue a lógica de decisão da MCC (IEC 60300-3-11, SAE
JA1011 ou SAE JA1012); e falta de documentação dos levantamentos e decisões referentes às
funções definidas como não significantes, as quais devem ser documentadas até a presente etapa.
5.7.6 Auditoria da Etapa 5
Os próximos itens justificam os quesitos que constituem cada um dos critérios que compõem a
auditoria da Etapa 5, os quais estão resumidos na Figura 5.26 e detalhados no Apêndice F.
Critério 1 (C1) – Confiabilidade da Análise
O quesito 4 deste critério, além dos quesitos 1 a 3, já explicitados, verifica se a equipe de
implementação, durante a seleção das tarefas de manutenção aplicáveis e efetivas, não motivou sua
149
escolha apenas pela disponibilidade de competências e recursos da empresa para sua execução,
sem considerar a necessidade ou justificativa para prevenir ou remediar o modo de falha. A
associação correta do mecanismo de falha, com as potencialidades e custo benefício da atividade
recomendada, é que deve guiar o processo de escolha.
Critério Quesito a ser Ponderado
● Atendimento aos pré-requisitos
● Atendimento ao Procedimento de Referência
● Credibilidade da tomada de decisão
→
Confiabilidade
da Análise
● Critério de escolha das atividades de manutenção
● Políticas de gestão da falha
● Probabilidade condicional e gestão da falha
● Viabilidade e atratividade das tarefas
● Falha Evidente de Segurança / Ambiental
● Falha Oculta de Segurança / Ambiental
● Falha Evidente Econômica / Operacional
→
Seleção e
Programação
das Tarefas
● Falha Oculta Econômica / Operacional
● Ratificação do serviço operacional
● Definição da falha potencial
● Intervalo PF
● Intervalo da tarefa x Intervalo PF
● Possibilidade de execução da tarefa
→
Serviço
Operacional
e
Inspeção
Preditiva
● Tempo de ação
● Probabilidade condicional x Restauração preventiva
● Falha prematura x Restauração preventiva
● Resistência a falha x Restauração preventiva
● Probabilidade condicional x Substituição preventiva
→
Restauração
e
Substituição
Preventiva
● Falha prematura x Substituição preventiva
● Probabilidade condicional x Inspeção funcional
● Credibilidade da inspeção funcional
● Função oculta x Inspeção funcional
● Possibilidade de execução da tarefa
● Ratificação da manutenção combinada
→
Inspeção
Funcional
e
Manutenção
Combinada
● Efetividade da manutenção combinada
● Condições atuais x Desempenho
● Falha Evidente de Segurança / Ambiental
● Falha Oculta de Segurança / Ambiental
● Falha Evidente Econômica / Operacional
● Falha Oculta Econômica / Operacional
Etapa 5
Seleção das
Tarefas de
Manutenção
Aplicáveis e
Efetivas
→
Mudança
de Projeto
e
Reparo
Funcional
● Ratificação do Reparo Funcional
Figura 5.26 – Auditoria da Etapa 5.
Critério 2 (C2) – Seleção e Programação das Tarefas
Este critério verifica a consistência da seleção e programação das tarefas de
manutenção e interpõe subsídios para assegurar-se de que os seguintes erros sejam evitados:
150
considerar as atividades já existentes como estabelecidas (item 5.6.4 da SAE JA1011); ignorar
a evolução da probabilidade condicional de falha (item 5.6.1 da SAE JA1011); ignorar a
aplicabilidade e efetividade da atividade (item 5.6.2 da SAE JA1011); não comparar a
atratividade econômica de atividades (item 5.6.3 da SAE JA1011); a tarefa programada não
reduz o risco ambiental ou pessoal a níveis aceitáveis (item 5.7.1.1 da SAE JA1011); a tarefa
programada não reduz as chances de falha múltipla em modos de falha ocultos (item 5.7.1.2
da SAE JA1011); a tarefa programada não reduz os custos em atividades com efeitos
econômicos (itens 5.7.1.3 e 5.7.1.4 da SAE JA1011);
Critério 3 (C3) – Serviço Operacional e Inspeção Preditiva
Os quesitos deste critério verificam a consistência das tarefas classificadas como sendo de
Serviço Operacional e Inspeção Preditiva, com o objetivo de detectar as seguintes incoerências de
implementação: falta de aplicabilidade e/ou efetividade das tarefas classificadas como sendo de
serviço operacional (IEC 60300-3-11); falta definição da falha potencial (item 5.2.7.1 da SAE
JA1011); falta identificação do período (PF) de desenvolvimento da falha (item 5.2.7.2 da SAE
JA1011); intervalo da inspeção maior que o menor intervalo PF previsto (item 5.2.7.3 da SAE
JA1011); impossibilidade de realizar a tarefa em intervalos menores que o PF (item 5.2.7.4 da
SAE JA1011); tempo insuficiente entre a descoberta do defeito e a evolução da falha (item 5.2.7.5
da SAE JA1011).
Critério 4 (C4) – Restauração e Substituição Preventiva
Os quesitos deste critério verificam a consistência das tarefas classificadas como
sendo de Restauração e Substituição Preventiva, com o objetivo de detectar as seguintes
incoerências de implementação: restauração de itens sem final de vida útil definida (itens
5.7.4.1 e 5.7.4.2 da SAE JA1011); restauração de itens a níveis intoleráveis pelo usuário ou
proprietário (item 5.7.4.3 da SAE JA1011); substituição de itens sem final de vida útil
definida (item 5.7.3.1 da SAE JA1011); substituição de itens cujo reparo é economicamente
viável (item 5.7.3.2 da SAE JA1011).
Critério 5 (C5) – Inspeção Funcional e Manutenção Combinada
Os quesitos deste critério verificam a consistência das tarefas classificadas como
sendo de Inspeção Funcional e Manutenção Combinada, com o objetivo de detectar as
seguintes incoerências de implementação: inspeções que não reduzem a probabilidade de
falha múltipla (item 5.7.5.1 da SAE JA1011); inspeções insuficientes para confirmar a
funcionalidade do sistema (item 5.7.5.2 da SAE JA1011); inspeções que podem deixar a
151
função oculta inoperante (item 5.7.5.3 da SAE JA1011); impossibilidade de execução da
inspeção nos intervalos especificados (item 5.7.5.4 da SAE JA1011); tarefas isoladas de
manutenção conseguem identificar e/ou corrigir a falha sem a necessidade de ações combinadas
(IEC 60300-3-11); o custo das tarefas de manutenção combinadas é maior do que o custo da falha
(IEC 60300-3-11)
.
Critério 6 (C6) – Mudança de Projeto e Reparo Funcional
Os quesitos deste critério verificam a consistência das tarefas classificadas como sendo de
Mudança de Projeto e Reparo Funcional, com o objetivo de detectar as seguintes incoerências de
implementação: ausência de análise de atividades de manutenção aplicáveis e efetivas (item 5.8.1.1
da SAE JA1011); permanência do projeto com riscos não combatidos pela manutenção (itens
5.8.1.2.1 e 5.8.1.2.2 da SAE JA1011); mudanças de projeto mais dispendiosas que a manutenção do
projeto
(itens 5.8.1.2.3 e 5.8.1.2.4 da SAE JA1011); reparos programados em itens com risco de
segurança ou com falhas evidentes viáveis de prevenção
(itens 5.8.2.1 e 5.8.2.2 da SAE JA1011).
5.7.7 Auditoria da Etapa 6
Os próximos itens justificam os quesitos que constituem cada um dos critérios que compõem a
auditoria da Etapa 6, os quais estão resumidos na Figura 5.27 e detalhados no Apêndice F.
Critério Quesito a ser Ponderado
● Atendimento aos pré-requisitos
● Atendimento ao Procedimento de Referência
● Credibilidade da tomada de decisão
● Confiabilidade e Mantenabilidade
● Critérios heurísticos
● Revisão de corretivas
→
Confiabilidade da
Análise
● Agrupamento das tarefas de manutenção
● Contexto operacional e conseqüências
● Exploração da idade
● Planejamento estratégico da empresa
→
Abrangência da
Análise
● Comunicação institucional
● Segurança e meio ambiente
● Economia e operação
● Vida útil
● Intervalo PF
Etapa 6
Definição dos
Intervalos
Iniciais e
Agrupamento
das Tarefas de
Manutenção
→
Impacto das Decisões
● Tamanho da equipe de manutenção
Figura 5.27 – Auditoria da Etapa 6.
152
Critério 1 (C1) – Confiabilidade da Análise
Os quesitos deste critério verificam a credibilidade das decisões tomadas durante a
Definição dos Intervalos Iniciais e Agrupamento das Tarefas de Manutenção. Assim, o objetivo d
os
quesitos 4 a 7 deste critério, além dos quesitos 1 a 3, já explicitados, é detectar os seguintes erros
de implementação: equacionamento errado ou não aprovado ou desconhecido pelo proprietário para
definir os intervalos de manutenção
(item 5.10.1 da SAE JA1011); transgressão de critérios
heurísticos de operadores e mantenedores; ações corretivas equivocadas, pela não aplicabilidade ou
pela baixa efetividade; e tarefas de manutenção programadas de forma desestruturada impactando
na disponibilidade do sistema.
Critério 2 (C2) – Abrangência da Análise
Este critério verifica, a partir da aplicação de seus quesitos, a abrangência da análise e das
decisões tomadas pela equipe de implementação, durante a Definição dos Intervalos Iniciais e
Agrupamento das Tarefas de Manutenção. Os seguintes erros de implementação são verificados: as
decisões tomadas não levaram em conta o contexto operacional e os riscos devidos a perda da função;
ausência de um programa de exploração da idade, para aquelas tarefas definidas sem conhecimento
dos mecanismos da falha; falta de consonância com o planejamento estratégico da empresa; e
deficiências na estruturação do novo contexto logístico e de apoio as tarefas de manutenção.
Critério 3 (C3) – Impacto das Decisões
Os quesitos deste critério verificam se a equipe de implementação, durante a Definição dos
Intervalos Iniciais e Agrupamento das Tarefas de Manutenção: preservou os princípios da MCC no
que diz respeito à periodicidade das tarefas de manutenção (princípios estes explicitados nos
respectivos quesitos – IEC 60300-3-11); e considerou e/ou dimensionou o tamanho da equipe de
manutenção de acordo com a quantidade e periodicidade das tarefas de manutenção.
5.7.8 Auditoria da Etapa 7
Os próximos itens justificam os quesitos que constituem cada um dos critérios que compõem a
auditoria da Etapa 7, os quais estão resumidos na Figura 5.28 e detalhados no Apêndice F.
153
Critério Quesito a ser Ponderado
● Atendimento aos pré-requisitos
● Atendimento ao Procedimento de Referência
● Credibilidade da tomada de decisão
● Abrangência do manual da MCC
→
Confiabilidade
da Análise
●
Encerramento
da fase de implementação
● Tarefas de manutenção
● Procedimentos para realimentação
● Integração ao programa de manutenção existente
Etapa 7
Redação do
Manual e
Implementação
→
Organização para
Implementação e
Gestão
● Treinamento
Figura 5.28 – Auditoria da Etapa 7.
Critério 1 (C1) – Confiabilidade da Análise
Os quesitos 4 e 5 deste critério, a
lém dos quesitos 1 a 3, já explicitados, verificam as
questões formais e gerenciais relacionadas à Redação do Manual e ao Planejamento para
Implementação do Programa de MCC. São verificados: o formalismo na descrição dos objetivos do
programa de MCC, explicitados em seu manual; e o encerramento da fase de implementação, o qual
deve seguir as boas práticas de gestão de projetos.
Critério 2 (C2) – Organização para Execução do Programa de MCC
Os quesitos deste critério verificam os aspectos mais relevantes da fase final de
implementação, os quais irão impactar a fase de execução do programa de MCC, estes aspectos são:
aspectos formais relativos ao manual da MCC, incluindo clareza na descrição e ciência da alta
gerência, das tarefas de manutenção e procedimentos e recomendações para revisão, realimentação e
consolidação de dados; e aspectos relativos às mudanças internas proporcionadas pelo novo
programa de manutenção proposto pela MCC, incluindo treinamento dos operadores e
mantenedores e implementação e incorporação das tarefas e controles propostos pela MCC.
5.7.9 Auditoria da Etapa 8
Os próximos itens justificam os quesitos que constituem cada um dos critérios que compõem a
auditoria da Etapa 8, os quais estão resumidos na Figura 5.29 e detalhados no Apêndice F.
Critério 1 (C1) – Confiabilidade da Análise
Os quesitos 4 e 5 deste critério, a
lém dos quesitos 1 a 3, já explicitados, verificam,
respectivamente, se após a implantação do programa de MCC se mantêm: o engajamento da
154
empresa em seus diversos setores envolvidos e/ou afetados pelo programa; e a preocupação
contínua com as questões relacionadas com a gestão da informação e do conhecimento e seu
atendimento às necessidades do programa de MCC na sua fase de execução.
Critério Quesito a ser Ponderado
● Atendimento aos pré-requisitos
● Atendimento ao Procedimento de Referência
● Credibilidade da tomada de decisão
● Incorporação da MCC
→
Confiabilidade da
Análise
● Gestão da informação/conhecimento
● Acompanhamento e realimentação
● Resultados obtidos
● Mudanças internas
● Registros históricos
→
Melhorias e
Mudanças Internas
● Melhoramento contínuo
● Freqüência das tarefas
● Ratificação das análises iniciais
● Monitoramento do programa de MCC
Etapa 8
Acompanhamento e
Realimentação
→
Planejamento e
Controle
● Adequação do suporte computacional
Figura 5.29 – Auditoria da Etapa 8.
Critério 2 (C2) – Melhorias e Mudanças Internas
Este critério avalia a concretização das mudanças internas demandadas pela MCC, para
consolidar as decisões tomadas durante as etapas anteriores (Etapa 0 a 7). Entre os itens de
especial interesse, os quais são examinados pelos quesitos deste critério, estão: o desempenho, a
aceitabilidade dos resultados e a aderência do programa de MCC; o comportamento do setor de
manutenção no que diz respeito às ações de manutenção e o registro de dados históricos; e os
subsídios para o melhoramento contínuo do programa de MCC.
Critério 3 (C3) – Planejamento e Controle
Este critério verifica a consistência do planejamento inicial e a realimentação e otimização
do programa de MCC. Os itens de interesse, examinados pelos quesitos deste critério, são:
compatibilidade entre tamanho da equipe e freqüência das tarefas de manutenção; ratificação do
planejamento inicial e controle para realimentação em caso de equívocos ou inconsistências; e
adequação dos sistemas computacionais de apoio.
155
5.8 AVALIAÇÃO DOS FATORES CRÍTICOS PARA A IMPLANTAÇÃO DA MCC
Concluída a fase de ponderação dos quesitos anteriores e posteriores a implementação
da etapa, o SBC-
Fuzzy
inicia o processo de inferência que resultará na avaliação dos critérios a
partir dos quais se tem a avaliação da etapa sob análise. A ponderação dos quesitos, em alguns
casos, depende de pesquisa junto aos mantenedores, operadores e demais envolvidos e/ou
afetados pelo programa de MCC, o que poderá ser feito, por exemplo, com auxílio da técnica
Delphi, explanada no Capítulo 4.
As ponderações do analista e as conclusões do processo de inferência, conduzidas
pelo SBC-
Fuzzy
, são mostradas no relatório final da análise, para cada uma das etapas
conforme o procedimento de referência. Este relatório apresenta, além do processo de
inferência, proposições de melhoria e regras de conduta que deveriam ser seguidas antes ou
durante o processo de implementação das etapas.
Cabe ressaltar que a avaliação dos pré-requisitos não altera a conduta e/ou os ritos do
processo de implantação da MCC. O que ocorre, é a interposição de subsídios para a tomada de
decisão da equipe de implementação para resolução de possíveis não conformidades e/ou baixa
aderência da empresa/sistema às necessidades da MCC. Ao mesmo tempo, tem-se a explicitação
do conhecimento tácito referente às características da empresa/sistema que permeiam e
influenciam os procedimentos de implantação da MCC. Assim, o relatório final de avaliação
dos pré-requisitos da etapa é um retrato das características da empresa/sistema e seu grau de
aderência à MCC e o conhecimento nele explicitado serve aos propósitos da Gestão do
Conhecimento (GC), tratada no Capítulo 3. Detalhes mais substanciais, de conteúdo e forma do
relatório final, serão melhor explicitados no Capítulo 6 deste trabalho.
5.9 CONSIDERAÇÕES E SÍNTESE DO CAPÍTULO
Neste capítulo foram abordados os principais critérios para avaliação dos pré-requisitos
e auditoria das etapas do processo de implantação da MCC, os quais subsidiam a metodologia
proposta. Tais critérios, com seus respectivos quesitos a serem ponderados, resultaram da
elicitação do conhecimento junto a especialistas, além de bibliografias e normas diversas sobre
o assunto em pauta. A estruturação e consolidação deste conhecimento no SBC-
Fuzzy
, assim
como a explicitação do processo de inferência difuso proposto, será objeto de explanação do
Capítulo 6.
A estruturação dos critérios e quesitos propostos foi possível a partir da concepção de
um procedimento de referência para implantação da MCC, o qual buscou condensar os aspectos
mais relevantes das bibliografias, normas e especialistas consultados. Tal procedimento não
156
pretende ser um modelo para implantação da MCC, mas tão somente um referencial para
orientar a estruturação deste trabalho.
O próximo capítulo abordará a consolidação da metodologia proposta em um SBC-
Fuzzy
e os mecanismos utilizados para tratamento das incertezas do processo decisório inerente.
157
CAPÍTULO 6
IMPLEMENTAÇÃO COMPUTACIONAL
6.1 INTRODUÇÃO
Este capítulo apresenta a implementação computacional do Sistema Baseado em
Conhecimento –
Fuzzy
(SBC-
Fuzzy
), desenvolvido para atuar como uma ferramenta de
consolidação da metodologia proposta e para ajudar no tratamento das incertezas inerentes à
implantação da Manutenção Centrada na Confiabilidade (MCC).
Conforme justificado nos capítulos precedentes, o SBC-
Fuzzy
foi desenvolvido seguindo
o modelo incremental. A representação do conhecimento utiliza técnicas híbridas com orientação
a objetos e regras de produção.
Nos próximos itens são explicitados, a composição da Base de Conhecimento e o processo
de inferência utilizado pelo SBC-
Fuzzy
desenvolvido para avaliação dos pré-requisitos e auditoria
da MCC.
6.2 ASPECTOS GERAIS DA IMPLEMENTAÇÃO COMPUTACIONAL
A implementação computacional do SBC-
Fuzzy
proposto recebeu o nome de DALF-MCC
(Diagnóstico Auxiliado por Lógica
Fuzzy
para a Manutenção Centrada na Confiabilidade) e seu
objetivo é auxiliar a implantação da MCC, tratando as incertezas do processo de análise e tomada
de decisão. Os procedimentos metodológicos, explicitados no Capítulo 5, foram incorporados ao
DALF-MCC e orientam o usuário na condução do processo de análise dos pré-requisitos e
auditoria da MCC, ponderando aspectos inerentes à Gestão do Conhecimento (GC) e às
heurísticas e aspectos normativos relacionados à implementação das etapas do programa de MCC.
As funcionalidades do DALF-MCC, para cada etapa do processo de implantação da MCC,
incluem: Análise dos Pré-Requisitos, Auditoria e Apoio à Implementação.
Na análise dos pré-requisitos, as características e necessidades da empresa e do sistema,
no qual a MCC será implementada, são confrontados com os requisitos exigidos pelo
procedimento de referência adotado por este trabalho, para implantação da MCC. Como resultado
deste processo, tem-se um relatório de diagnóstico que mostra a aptidão ou não da empresa e/ou
sistema, para implementar a etapa sob análise.
Na auditoria, os atributos de cada etapa implementada são comparados com aqueles do
procedimento de referência, abordados no Capítulo 5, e outros normatizados ou de consenso entre
os especialistas em MCC. Como resultado deste processo, tem-se um relatório de diagnóstico que
indica se a equipe de implementação da MCC conduziu adequadamente e obteve os resultados
158
esperados para a etapa sob análise e se está apta ou não para seguir com o processo de
implantação da MCC.
Para apoio a implementação das etapas, o DALF-MCC incorpora soluções propostas para
auxiliar o processo decisório durante a implementação de algumas etapas, as quais são
importantes para o sucesso do programa de MCC. As soluções apresentadas contemplam as etapas
3, 4 e 5 do procedimento de referência e serão explicitadas no Capítulo 7.
6.3 METODOLOGIA DE DESENVOLVIMENTO
A metodologia utilizada para desenvolvimento do DALF-MCC, mostrada na Figura 6.1,
seguiu um modelo incremental composto pelas seguintes etapas: Planejamento, Aquisição do
Conhecimento, Representação do Conhecimento e Verificação, Validação do Protótipo
Intermediário, Ciclo Incremental, e Versão Final. Os próximos itens detalham essas etapas.
Na etapa de planejamento definiu-se o domínio da aplicação, as funcionalidades
requeridas e as ferramentas computacionais utilizadas para o desenvolvimento do DALF-MCC. A
Figura 6.1 ilustra as deliberações desta etapa.
Na aquisição do conhecimento procedeu-se o mapeamento das fontes de conhecimento e a
aquisição do conhecimento explícito, de normas e bibliografias relacionadas e o conhecimento
heurístico dos especialistas que contribuíram com este trabalho. A Figura 6.1 ilustra os resultados
desta etapa, os quais o Capítulo 5 explicitou na forma de quesitos a serem ponderados pelo
usuário (ver detalhes no Apêndice F). Tais quesitos refletem o conhecimento explícito e heurístico
aquisitados nesta etapa, os quais serviram de referência para concepção da base de conhecimento
do DALF-MCC.
Concluído o primeiro ciclo de aquisição do conhecimento, iniciou-se a implementação do
DALF-MCC, que incluiu: representação, verificação e validação do conhecimento, conforme
apresentado no Capítulo 4. Seguindo uma filosofia incremental, este processo de aquisição e
implementação se repete e se aprimora a cada novo ciclo, até que a base de conhecimento
represente de forma satisfatória o conhecimento do especialista e das fontes de conhecimento
explícito utilizadas. Para o DALF-MCC, cabe ressaltar os seguintes desenvolvimentos, inerentes
as etapas supracitadas: a base de conhecimento foi implementada utilizando-se de técnicas
híbridas, com orientação a objetos e regras de produção na
Shell
FuzzyClips; a interface com o
usuário foi implementada em
Visual Basic
; e os relatórios finais de síntese e conclusão foram
implementados em HTML. Os procedimentos e desdobramentos do processo de verificação e
validação do DALF-MCC serão abordados com mais detalhes no Capítulo 8 deste trabalho.
Com a maturidade e a estruturação desejada da base de conhecimento e as funcionalidades
gerais exigidas, iniciou-se a etapa de testes de campo. Estes testes avaliaram a eficácia do DALF-
MCC, enquanto uma ferramenta, com relação a aplicação do conhecimento implementado, suas
159
funcionalidades gerais e a interface com o usuário. Detalhes da aplicação em campo do DALF-
MCC serão abordados com mais detalhes no Capítulo 8 deste trabalho.
Concluída a etapa de testes de campo e feitas as modificações e incrementos necessários, o
DALF-MCC foi concluído, ficando sujeito às manutenções inerentes ao seu ciclo de vida.
Ciclo de Vida do
DALF-MCC
• Versão final do DALF-MCC;
• Critérios para manutenção do DALF-MCC.
• Domínio do Conhecimento: Implantação da MCC;
• Funcionalidades: Manipulação de arquivos (novo, abrir, salvar); Parametrização dos conjuntos
Fuzzy
a serem utilizados; Questionamentos para avaliação dos pré-requisitos e auditoria da MCC;
Ajuda para o usuário; Relatórios de avaliação de cada etapa a ser implementada;
• Ferramentas Com
p
utacionais:
Shel
l
Fuzz
y
Cli
p
s; Interface com o usuário e
m
Visual Basi
c
e HTML.
• Conhecimento explicitado e modelado;
• Regras para implementação da Base de Conhecimento na
Shell
FuzzyClips.
Definições: domínio do conhecimento; funcionalidades
requeridas do DALF-MCC; ferramentas computacionais.
Planejamento
Estudos iniciais: SBC’s e ferramentas
computacionais inerentes; Domínios
de conhecimento potenciais.
Mapeamento das fontes de conhecimento e aquisição do
conhecimento explícito e heurístico.
Aquisição do Conhecimento
Bibliografias de Referência; Normas;
Especialistas.
• Base de Conhecimento implementada utilizando técnicas híbridas com orientação a objetos e
regras de produção na
Shell
FuzzyClips;
• Interface com o usuário em
Visual Basic
e HTML para os Relatórios;
• Estratégia de comunicação implementada entre o FuzzyClips e o
Visual Basic
;
• DALF-MCC verificado conforme critérios ex
p
licitados no Ca
p
ítulo 4.
Implementação da Base de Conhecimento na
Shell
FuzzyClips, desenvolvimento da Interface e Verificação.
Representação do Conhecimento e Verificação
Saídas da etapa de Aquisição do
Conhecimento; Estratégias para
desenvolvimento da Base de
Conhecimento e sua Interface.
• Base de conhecimento do protótipo intermediário validada;
• Formalismo e relevâncias dos questionamentos verificados e validados;
• Verificação e Validação pelos especialistas da acurácia das respostas;
• Comprovação, pelos especialistas, das funcionalidades requeridas.
Validação pelos especialistas das regras da base de
conhecimento e comprovação das funcionalidades.
Validação do Protótipo Intermediário
Saídas da etapa de Implementação
Computacional; Estratégias para
Validação do protótipo junto aos
Es
p
ecialistas.
Acréscimo de funcionalidades e incrementos na base de
conhecimento.
Ciclo Incremental
Resultados do processo de Validação
do protótipo intermediário; Novos
conhecimentos/regras para incremento
da
b
ase de conhecimento.
Testes de campo, aprovação da versão final e entrada no
ciclo de manutenção do DALF-MCC.
Versão Final
Detalhes e exigências finais do
processo de Verificação e Validação.
• Protótipo adequado e aceito para versão
final.
•
Protótipo em fase de desenvolvimento incremental,
conforme critérios ex
p
licitados no Ca
p
ítulo 4.
Figura 6.1 – Metodologia de Desenvolvimento do DALF-MCC.
160
6.4 ORGANIZAÇÃO DAS REGRAS NO DALF-MCC
Conforme abordado no Capítulo 5, o DALF-MCC é utilizado para analisar os pré-requisitos e
fazer a auditoria de cada etapa da MCC segundo determinados critérios, os quais possuem quesitos a
serem ponderados (Apêndice F). O responsável pela análise deverá ponderar cada quesito com uma
nota
crisp
(0 a 10) ou um conceito
Fuzzy
(Ruim, Baixa, Boa, Alta ou Ótima), referente à aderência de
sua empresa ou sistema àquele quesito sob análise, o qual reflete as necessidades da MCC.
Para incorporar a incerteza por imprecisão (léxica), ambos, critérios e quesitos, serão
tratados como variáveis lingüísticas
Fuzzy
, cujos termos primários compõem a avaliação de cada
etapa (pré-requisitos e auditoria). Estas variáveis lingüísticas são configuradas na tela de
Parametrização
Fuzzy
do DALF-MCC (Figura 6.2). Mais detalhes da interface do DALF-MCC
podem ser vistos no Apêndice G.
Figura 6.2 – Tela de Parametrização do DALF-MCC.
O DALF-MCC avalia os pré-requisitos e faz a auditoria de cada etapa da MCC segundo determinados critérios, os quais possuem
esitos a serem ponderados. O responsável pela análise deverá ponderar cada quesito com uma nota (0 a 10) ou um conceito
uim, Baixa, Boa, Alta ou Ótima), referente à aderência de sua empresa ou sistema àquele quesito sob análise.
nota ou conceito, atribuído a cada quesito, serão avaliados por um SBC Fuzzy
qu
(R
A
. As variáveis lingüísticas, referentes à partição
do conjunto Fuzzy, as quais serão utilizadas no processo de análise podem ser parametrizadas abaixo.
O gráfico abaixo mostra valores pré-parametrizados “default”, que representam valores médios de consenso entre especialistas em
MCC. Caso estes valores estejam adequados, para a empresa ou sistema a ser analisado, siga para a próxima etapa da metodologia
(Análise dos Pré-Requisitos, Auditoria ou Apoio a Implementação).
aso a parametrização, mostrada no gráfico abaixo, não esteja adequada para a empresa ou sistema específico a ser analisado,
altere sua parametrização utilizando os campos ao lado do gráfico, procedendo da seguinte maneira:
1) Escolha a variável lingüística a ser modificada (Ruim, Baixa, Boa, Alta ou Ótima);
2) Altere seus valores (X0, X1, X2, X3), conforme desejado;
3) Estabelecida a parametrização desejada, para cada variável lingüística, clique no botão Atualizar.
Conjunto Fuzzy atual “
default
”
C
Parametrização
dos Termos
Primários
Informações e
instruções para o
usuário com
hiperlinks
para
arquivo de ajuda
em HTML.
Todos os quesitos, referentes a cada critério, devem ser ponderados e os resultados
agregados para obtenção do conjunto
Fuzzy
representativo do critério. A ponderação de cada
quesito (Nota ou Conceito) serve também para compor o relatório final de avaliação da aderência
ou não da empresa/sistema aos requisitos de cada critério. Com base na ponderação de cada
quesito, as respectivas considerações são apresentadas ao usuário. Após a ponderação e agregação
de todos os quesitos referentes a cada critério, tem-se o conjunto
Fuzzy
representativo do critério.
Este conjunto compõe o relatório final de avaliação da aderência ou não da empresa/sistema aos
requisitos de cada etapa. Além disto, a desfuzzyficação deste conjunto resultará em uma nota
(valor
crisp
), em função da qual uma mensagem/resposta é apresentada ao usuário.
Os dados inseridos na tela de Parametrização
Fuzzy
são utilizados para a ponderação de
todos os quesitos, os quais compõem os critérios que servirão de base para avaliação dos pré-
requisitos e auditoria de todas as etapas do procedimento de implantação da MCC. Conforme
enfatizado no Capítulo 5 o processo de parametrização deve ser conduzido por um especialista em
161
MCC e no domínio da aplicação. O conhecimento/experiência deste especialista servirá de base
para a definição das funções de pertinência, as quais definirão os termos primários e, assim duas
situações poderão ocorrer:
1. A parametrização é concebida de forma condizente com o domínio da aplicação e, neste
caso, a ponderação dos quesitos irá, indiretamente, retratar o grau de maturidade e
aderência da empresa quando comparada com outras do mesmo domínio de aplicação;
2. A parametrização retrata o consenso entre o(s) especialista(s) e os membros da equipe de
implementação, levando em conta as especificidades da aplicação.
Em ambas as situações a parametrização deve ser conhecida pelos usuários para que a
ponderação dos quesitos retrate, da maneira mais íntegra possível, a realidade da empresa/sistema.
Na tela de ponderação dos quesitos (Figura 6.3) o usuário atribui uma Nota ou um
Conceito para cada quesito submetido a análise, sendo que: a Nota deve estar dentro do universo de
discurso configurado na tela de parametrização
Fuzzy
(no DALF-MCC o universo de discurso
poderá assumir qualquer intervalo entre 0 e 10); e o Conceito poderá ser qualquer um dos termos
primários
Fuzzy
disponíveis (Ruim, Baixa, Boa, Alta ou Ótima).
Figura 6.3 – Tela de Ponderação dos Quesitos.
Critérios para
avaliação da etapa
Ponderação com Nota
ou Conceito e acesso
ao arquivo de Ajuda
Quesitos a serem ponderados pelo usuário
para avaliação do Critério
Avaliação
da etapa
Critérios avaliados e nota
resultante
Avaliação
do critério
Q1 – Todas as Entradas, Controles e Mecanismos da Etapa 0 (Adequação da MCC), do
procedimento de referência para implantação da MCC, estão disponíveis.
Q2 – Existe uma documentação consistente das ações de manutenção.
Q3 – Os sistemas candidatos a implantação da MCC possuem uma documentação técnica
adequada.
Q4 – O planejamento estratégico da empresa, com relação à manutenção, está documentado
de forma auditável.
Disponibilidade da
Informação/Recursos
Condição e Desempenho
Atual da Manutenção
Sistema Computacional
de Suporte
Cultura da
Manutenção/Empresa
Gerenciamento Estratégico
da Manutenção
A conjunção de Nota e Conceito possibilita ao usuário utilizar-se do mecanismo que lhe seja
mais intuitivo para a ponderação dos quesitos. Como resultado desse processo se espera obter uma
ponderação que espelhe a realidade da empresa/sistema, da maneira mais confiável possível.
Após a composição dos conjuntos
Fuzzy
referentes à avaliação de cada critério, os
mesmos devem ser agregados para obtenção do conjunto
Fuzzy
representativo da etapa. Este
conjunto compõe o relatório final de avaliação da aderência ou não da empresa/sistema aos
requisitos da MCC. O conjunto
Fuzzy
resultante de cada etapa servirá para mostrar o contexto
geral da empresa/sistema frente aos critérios avaliados (avaliação qualitativa). A nota resultante
162
da desfuzzyficação do conjunto
Fuzzy
resultante de cada etapa, servirá para avaliar o atendimento
ou não da empresa/sistema aos requisitos da MCC avaliados a partir dos quesitos de cada critério
(análise quantitativa).
Portanto, 5 grupos de regras são utilizados pelo DALF-MCC para a avaliação dos pré-
requisitos, conforme o procedimento de referência, o mesmo valendo para a auditoria de cada
etapa do processo de implantação da MCC. Estes grupos de regras são:
1. Regras para avaliação dos critérios, a partir da ponderação dos quesitos. Nestas regras o
Antecedente é a ponderação dos quesitos feita pelo usuário (Conceito ou Nota) e o
Conseqüente é a avaliação do critério com base na ponderação de cada quesito;
2. Regras para avaliação da etapa com base na avaliação dos critérios da referida etapa
(resultante do grupo de regras 1). Neste caso, o Antecedente são conjuntos
Fuzzy
resultantes da avaliação de cada critério com base na ponderação de cada quesito e o
Conseqüente é um conjunto
Fuzzy
resultante da agregação de todos os conjuntos
Fuzzy
referentes à avaliação dos critérios;
3. Regras para composição do relatório de conclusão de cada etapa, com 3 subgrupos de regras:
3.1. O Antecedente é um Conceito ou uma Nota Fuzzyficada referente à ponderação de
cada quesito, enquanto que o Conseqüente é uma mensagem/resposta ao usuário com
base na ponderação de cada quesito;
3.2. O Antecedente é uma Nota (valor
crisp
) resultante da desfuzzyficação do conjunto
referente à avaliação de cada critério e o Conseqüente é uma mensagem/resposta ao
usuário com base na respectiva Nota. O conjunto
Fuzzy
a ser desfuzzyficado foi
formado a partir da agregação de cada termo primário, afetado pela ponderação dos
quesitos (Nota ou Conceito), pertencentes ao respectivo critério;
3.3. O Antecedente é uma Nota (valor
crisp
)
resultante da desfuzzyficação do conjunto
referente à agregação de todos os conjuntos
Fuzzy
, originados da avaliação dos
critérios (resultado das regras do grupo 2). O Conseqüente é uma mensagem/resposta
ao usuário com base no valor da Nota resultante da desfuzzyficação.
Os resultados e conclusões do processo de inferência
Fuzzy
incluindo seus desdobramentos
e as respostas às ponderações do usuário são condensados em um relatório (Figura 6.4). Os
seguintes dados são submetidos ao usuário para auxiliar sua tomada de decisão: os conjuntos
Fuzzy
relativos à avaliação dos critérios, formados após a agregação referente à ponderação dos quesitos,
com suas respectivas notas resultantes desfuzzyficadas; o conjunto
Fuzzy
relativo à avaliação da
etapa sob análise, formado após a agregação dos conjuntos
Fuzzy
referentes à avaliação dos
critérios, com sua respectiva nota resultante desfuzzyficada; e as conclusões e sugestões do DALF-
MCC relativas ao resultado final de avaliação da etapa sob análise. Resultados semelhantes, em
formato e funcionalidade, são obtidos nos relatórios relativos à avaliação dos critérios e à
ponderação de seus respectivos quesitos. Tanto para o caso da análise dos pré-requisitos quanto para
163
a auditoria de todas as etapas que compõem o procedimento de referência, incorporado ao DALF-
MCC. Mais detalhes dos relatório gerados pelo DALF-MCC podem ser vistos no Apêndice G.
Conjuntos Fuzzy
resultantes da
avaliação dos
critérios e da etapa
sob análise
Resultados da
inferência Fuzzy:
conclusões e
sugestões para o
usuário devidas a
avaliação da etapa
sob análise
Com uma Nota Final de avaliação da Etapa 0 - Adequação da MCC nos patamares atuais (5 < Nota < ou = 7) a MCC É VIÁVEL para esta empresa/sistema,
porém uma política de treinamento na metodologia de MCC deve ser considerada para maximizar os resultados do programa de MCC.
Os pontos críticos apresentados na seção de resultados, tanto na ponderação dos Quesitos quanto na avaliação dos critérios, devem ser trabalhados internamente
na empresa para propiciar um ambiente adequado para uma implementação futura da MCC. As seguintes referências podem auxiliar a condução deste processo:
BACKLUND
, Fredrik, Managing the Introduction of Reability Centred Maintenance.
BLOOM, Neil B., Reliability Centered Maintenance: Implementation Made Simple.
FUENTES, Fernando Félix Espinosa, Metodologia para Inovação da Gestão da Manutenção Industrial.
MOUBRAY, J., Reliability Centered Maintenance.
SIQUEIRA, Iony Patriota de. Manutenção Centrada na Confiabilidade: Manual de Implementação.
SMITH, Anthony M. e HINCHCLIFFE, Glenn R., RCM: Gateway to World Class Maintenance.
Figura 6.4 – Relatório de Avaliação da Etapa.
Portanto, além dos resultados da desfuzzyficação, o DALF-MCC inclui: subsídios que
auxiliam a tomada de decisão e a gestão do conhecimento inerente aos
atributos atuais da empresa
e sua relação com as necessidades e fatores críticos de sucesso da MCC; explicação sobre o
processo de inferência que culminou com as conclusões e sugestões apresentadas; comentários,
conclusões e sugestões referentes à aderência ou não da empresa às necessidades da MCC; e
recomendações para ações futuras com base na situação atual da empresa/sistema.
6.5 POSSÍVEIS CONFIGURAÇÕES DO PROCESSO DE INFERÊNCIA
FUZZY
A organização das regras, que estruturam a base de conhecimento para tratamento da
ponderação dos quesitos e conseqüente avaliação dos critérios e etapas, tanto para a análise dos
pré-requisitos quanta para a auditoria, seguiu a codificação mostrada na Figura 6.5. Esta
codificação será também utilizada neste item para explicitação da estrutura interna da base de
conhecimento do DALF-MCC e da lógica para concepção das respostas para o usuário a partir da
ponderação dos quesitos.
Et_Nº_C_Nº_Q_Nº
Etapa Critério Quesito
Número do
Critério
Número do
Quesito
Número da
Etapa
Figura 6.5 – Critério de Codificação da Base de Conhecimento do DALF-MCC.
164
Os quesitos submetidos ao usuário são asserções que retratam uma necessidade da MCC.
Cabe ao usuário atribuir uma Nota ou um Conceito, referente à aderência da empresa/sistema,
àquela asserção. Sendo assim podem ocorrer 3 situações:
1. O usuário atribui apenas Conceitos, ou seja, termos primários
Fuzzy
(Ruim, Baixa, Boa,
Alta ou Ótima) para cada quesito;
2. O usuário atribui apenas Notas, ou seja, um valor
crisp
(no DALF-MCC, qualquer
intervalo configurável entre 0 e 10) para cada quesito;
3. O usuário alterna, entre Nota e Conceito, para ponderar os quesitos referentes ao critério a
ser avaliado.
Situação 1: O usuário atribui apenas Conceitos para ponderação dos quesitos
Caso o usuário atribua apenas conceitos para ponderar os quesitos, respeitando os termos
primários permitidos (Ruim, Baixa, Boa, Alta ou Ótima), a seguinte combinação de regras pode
acontecer, a qual vale tanto para a análise dos pré-requisitos quanto para auditoria:
Rui
m
Rui
m
Baixa Baixa
Boa Boa
Alta Alta
Se Et_Nº_C_Nº_Q_Nº é:
Conceito
Ótima
Então Et_Nº_C_Nº é:
Conceito
Ótima
Tomando como exemplo a análise dos pré-requisitos da Etapa 0 (Adequação da MCC),
conforme explicitado no Capítulo 5, e supondo uma atribuição de Conceito aos quesitos
pertencentes ao critério 1, conforme abaixo, verifica-se o seguinte processo de inferência:
Critério: (C1)
–
Disponibilidade da Informação/Recursos
Quesitos: Conceitos:
(Q1)
–
Aderência ao procedimento de referência Boa
(Q2)
–
Documentação da manutenção Alta
(Q3)
–
Documentação dos sistemas candidatos Baixa
(Q4)
–
Plane
j
amento estraté
g
ico da empresa Ótima
A partir dos Conceitos atribuídos pelo usuário, as regras abaixo são ativadas na base de
conhecimento do DALF-MCC:
Se Et
_
0
_
C
_
1
_
Q
_
1 é: Boa Então Et
_
0
_
C
_
1 é: Boa
Se Et
_
0
_
C
_
1
_
Q
_
2 é: Alta Então Et
_
0
_
C
_
1 é: Alta
Se Et
_
0
_
C
_
1
_
Q
_
3 é: Baixa Então Et
_
0
_
C
_
1 é: Baixa
Se Et
_
0
_
C
_
1
_
Q
_
4 é: Ótima Então Et
_
0
_
C
_
1 é: Ótima
A partir destas regras, a inferência
Fuzzy
mostrada na Figura 6.6, é desenvolvida pelo
DALF-MCC.
Após o processo de ponderação dos antecedentes (quesitos Q1 a Q4),
implicação e agregação dos conseqüentes das regras, o que se tem é o conjunto
Fuzzy
resultante para o critério C1 (Disponibilidade da Informação/Recursos).
O baricentro geométrico ou centróide da área definida pelo conjunto
Fuzzy
, resultante
da agregação dos conseqüentes, é a Nota (valor
crisp
) atribuída ao critério C1 a partir dos
conceitos atribuídos pelo usuário aos quesitos. Este processo é comumente chamado de
165
desfuzzyficação ou condensação. Para cálculo do valor desfuzzyficado, o FuzzyClips,
máquina de inferência utilizada pelo DALF-MCC, discretiza o universo de discurso referente
ao critério analisado (C1), conforme explicitado no Capítulo 4.
Situação 2: O usuário atribui apenas Notas para ponderação dos quesitos
Caso o usuário atribua apenas notas para ponderar os quesitos, respeitando o universo de
discurso permitido (no DALF-MCC, qualquer intervalo configurável entre 0 e 10), a seguinte
combinação de regras pode acontecer (válida para a análise dos pré-requisitos e para a auditoria):
Se Et_Nº_C_Nº_Q_Nº é:
Nota:
Valor entre
0 e 10
Então Et_Nº_C_Nº é:
Conceitos afetados pela
fuzzyficação da Nota, com seu
respectivo Grau de Pertinência.
Tomando como exemplo a análise dos pré-requisitos da Etapa 0 (Adequação da MCC),
conforme explicitado no Capítulo 5, e supondo uma atribuição de Nota aos quesitos pertencentes
ao critério 2, conforme abaixo, o seguinte processo de inferência se verifica:
Critério: (C2)
–
Condição e Dese
m
p
enho Atual da Manutenção
Quesitos: Nota:
(Q1)
–
Estraté
g
ia de manutenção 1,8
(Q2)
–
Desempenho da manutenção 7,5
(Q3)
–
Recursos humanos na operação 3,5
(Q4)
–
Custos da manutenção 6
Figura 6.6 – Processo de Inferência
Fuzzy
com Atribuição de Conceitos.
Agregação
Nota = 5,745
1 2 3 4 5 6 7 8 9 10
μ
1
Condensação ou Desfuzzyficação
C1 - Disponibilidade da Informação/Recursos
==
)(∑
).(∑
1
∈∀
∈∀
Ci
UC
CiCi
UC
A
Ax
C
Ci
Ci
5.745
2
1).12(
2
1).13(
2
1).13(
2
1).24(
2
1).12(
.2,9
2
1).13(
.5,2
2
1).13(
.5,7
2
1).24(
.5
=
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Q2 - Documentação da manutenção
Ruim Baixa Boa Alta Ótima
1 2 3 4 5 6 7 8 9 10
μ
1
Conceito = Alta
Q1 - Aderência ao procedimento de referência
Ruim Baixa Boa Alta Ótima
1 2 3 4 5 6 7 8 9 10
μ
1
Conceito = Boa
Q3 - Documentação dos sistemas candidatos
Ruim Baixa Boa Alta Ótima
1 2 3 4 5 6 7 8 9 10
μ
1
Conceito = Baixa
Q4 - Planejamento estratégico da empresa
Ruim Baixa Boa Alta Ótima
1 2 3 4 5 6 7 8 9 10
μ
1
Conceito = Ótima
Ruim Baixa Boa Alta Ótima
1 2 3 4 5 6 7 8 9 10
μ
1
C1 - Disponibilidade da Informação/Recursos
C1 - Disponibilidade da Informação/Recursos
μ
1
Ruim Baixa Boa Alta Ótima
1 2 3 4 5 6 7 8 9 10
Implicação
Implicação
Implicação
Implicação
Ponderação
Ruim Baixa Boa Alta Ótima
1 2 3 4 5 6 7 8 9 10
μ
1
C1 - Disponibilidade da Informação/Recursos
Ruim Baixa Boa Alta Ótima
1 2 3 4 5 6 7 8 9 10
μ
1
C1 - Disponibilidade da Informação/Recursos
166
A partir das Notas atribuídas pelo usuário, as regras abaixo são ativadas na base de
conhecimento do DALF-MCC:
Se Et_0_C_2_Q_1 é: 1,8 Então Et_0_C_2 é: Conceitos afetados pela fuzzyficação da Nota 1,8
Se Et_0_C_2_Q_2 é: 7,5 Então Et_0_C_2 é: Conceitos afetados pela fuzzyficação da Nota 7,5
Se Et_0_C_2_Q_3 é: 3,5 Então Et_0_C_2 é: Conceitos afetados pela fuzzyficação da Nota 3,5
Se Et_0_C_2_Q_4 é: 6 Então Et_0_C_2 é: Conceitos afetados pela fuzzyficação da Nota 6
A partir destas regras, a inferência
Fuzzy
, mostrada na Figura 6.7, é desenvolvida pelo
DALF-MCC. Os antecedentes (quesitos Q1 a Q4) de cada regra são ponderados de acordo com a
Nota atribuída pelo usuário, e considerando-se as funções de pertinência associadas, resultando no
grau de pertinência de cada Nota aos termos primários correspondentes. Ou seja, a Nota (valor
crisp
) é convertida para um termo primário
Fuzzy
(Ruim, Baixa, Boa, Alta ou Ótima – processo
denominado fuzzyficação).
C2 - Condição e Desempenho Atual da Manutenção
Q1 - Estratégia de manutenção
μ
1
Após o processo de fuzzyficação dos antecedentes (Q1 a Q4) ocorre a implicação, isto é, o
processo em que os conseqüentes das regras, cujas condições são satisfeitas em algum grau de
aplicabilidade, são calculados. Este processo encerra a idéia de que: se o antecedente da regra é
verdadeiro, com algum grau de verdade, então o conseqüente também o é, com o mesmo grau de
verdade. O processo de implicação consiste, basicamente, na modificação dos conjuntos difusos
associados com os conseqüentes da regra. No modelo de inferência Fuzzy de Mamdani, utilizado
Figura 6.7 – Processo de Inferência
Fuzzy
com Atribuição de Notas.
Agregação
Nota = 4,599
1 2 3 4 5 6 7 8 9 10
μ
1
Condensação ou Desfuzzyficação
C2 - Condição e Desempenho Atual da Manutenção
==
)(∑
).(∑
1
∈∀
∈∀
Ci
UC
CiCi
UC
A
Ax
C
Ci
Ci
4.599
2
1).24(
)
2
5,0).34(
2
5,0).23(
(
2
1).13(
)
2
8,0).4,13(
2
2,0).8,12(
(
2
1).24(
.5)
2
5,0).34(
.5
2
5,0).23(
.5,2(
2
1).13(
.5,7)
2
8,0).
4,13(
.5,2
2
2,0).8,12(
.95,0(
=
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
Q2 - Desempenho da manutenção
Ruim Baixa Boa Alta Ótima
1 2 3 4 5 6 7 8 9 10
μ
1
Nota = 7,5
Ruim Baixa Boa Alta Ótima
1 2 3 4 5 6 7 8 9 10
μ
1
Nota = 1,8
Q3 - Recursos humanos na operação
Ruim Baixa Boa Alta Ótima
1 2 3 4 5 6 7 8 9 10
μ
1
Nota = 3,5
Q4 - Custos da manutenção
Ruim Baixa Boa Alta Ótima
1 2 3 4 5 6 7 8 9 10
μ
1
Nota = 6
Ruim Baixa Boa Alta Ótima
1 2 3 4 5 6 7 8 9 10
μ
1
C2 - Condição e Desempenho Atual da Manutenção
Ruim Baixa Boa Alta Ótima
1 2 3 4 5 6 7 8 9 10
Implicação
Implicação
Implicação
Implicação
Ruim Baixa Boa Alta Ótima
1 2 3 4 5 6 7 8 9 10
μ
1
C2 - Condição e Desempenho Atual da Manutenção
Ruim Baixa Boa Alta Ótima
1 2 3 4 5 6 7 8 9 10
μ
1
C2 - Condição e Desempenho Atual da Manutenção
Ponderação
167
neste trabalho (REZENDE, 2003; YEN, 1998), estes conjuntos difusos são truncados em um nível
correspondente ao grau de aplicabilidade da regra. Após a implicação, ocorre a agregação dos
conseqüentes das regras e a desfuzzyficação ou condensação, conforme já explicitado na Situação 1.
Situação 3: O usuário alterna entre Nota e Conceito para ponderação dos quesitos
Esta situação é uma composição das anteriores e, neste caso, o usuário pode atribuir, para
a ponderação dos quesitos de um critério, tanto uma Nota, respeitando-se o universo de discurso
permitido ou um Conceito, respeitando-se os termos primários disponíveis. As regras ativadas na
base de conhecimento do DALF-MCC são, também, uma composição dos casos anteriores.
Tomando como exemplo a análise dos pré-requisitos da Etapa 0 (Adequação da MCC),
conforme explicitado no Capítulo 5 e supondo uma atribuição alternada de Nota e Conceito aos
quesitos pertencentes ao critério 3, conforme abaixo, o seguinte processo de inferência se verifica:
Critério: (C3)
–
Sistema Computacional de Suporte
Quesitos: Nota:
(Q1)
–
Automação de escritório Boa
(Q2)
–
Gestão da informação 1,8
(Q3)
–
Gestão da manutenção Baixa
(Q4)
–
Afinidade/Treinamento com o sistema 3,5
(Q5)
–
Inte
g
ração com outros sistemas Alta
A partir das Notas atribuídas pelo usuário, as regras abaixo são ativadas na base de
conhecimento do DALF-MCC:
Se Et
_
0
_
C
_
3
_
Q
_
1 é: Boa Então Et
_
0
_
C
_
3 é: Boa
Se Et
_
0
_
C
_
3
_
Q
_
2 é: 1,8 Então Et
_
0
_
C
_
3 é: Conceitos afetados pela fuzz
y
ficação da Nota 1,8
Se Et
_
0
_
C
_
3
_
Q
_
3 é: Baixa Então Et
_
0
_
C
_
3 é: Baixa
Se Et
_
0
_
C
_
3
_
Q
_
4 é: 3,5 Então Et
_
0
_
C
_
3 é: Conceitos afetados pela fuzz
y
ficação da Nota 3,5
Se Et
_
0
_
C
_
3
_
Q
_
5 é: Alta Então Et
_
0
_
C
_
3 é: Alta
A partir destas regras, a inferência
Fuzzy
mostrada na Figura 6.8, é desenvolvida pelo
DALF-MCC. A ponderação dos antecedentes pelo usuário (quesitos Q1 a Q5), implicação e
agregação dos conseqüentes das regras e a desfuzzyficação ou condensação, se processam de
maneira semelhante às situações exemplificadas nas Situações 1 e 2.
Com a avaliação dos critérios, a partir da ponderação dos quesitos, o processo de
inferência do DALF-MCC avalia a etapa correspondente aos quesitos ponderados e respectivos
critérios avaliados. Neste caso, a seguinte combinação de regras pode acontecer, a qual vale tanto
para a análise dos pré-requisitos quanto para auditoria:
Se Et_Nº_C_Nº é:
Conjunto
Fuzzy
resultante
da avaliação do critério
Então Et_Nº é:
Conjunto
Fuzzy
resultante da
agregação de todos os critérios que
compõem a etapa
Para o processamento da avaliação da etapa é necessário a ponderação, por parte do
usuário, de todos os quesitos e a avaliação de todos os critérios correspondentes que a compõe.
168
Portanto, assim como foi conduzida a avaliação dos critérios 1 a 3 exemplificados nos itens
precedentes, para se ter a avaliação da Etapa 0 (Adequação da MCC), deve-se proceder de forma
semelhante à avaliação dos critérios 4 e 5 que a compõem.
C3 - Sistema Computacional de Suporte
Q1 - Automação de escritório
μ
1
Após a avaliação de todos os critérios que compõem cada etapa, o DALF-MCC processa a
inferência de modo a agregar todos os conjuntos
Fuzzy
resultantes de cada critério avaliado, e
inerentes à respectiva etapa. O resultado deste processo é um conjunto
Fuzzy
que retrata o Grau
de Aderência da Empresa/Sistema aos requisitos avaliados. Os resultados deste processo
conduzem a conclusão da aptidão ou não da empresa/sistema para avançar com os procedimentos
de implantação da MCC. Esta metodologia de inferência se aplica tanto para a fase de verificação
dos pré-requisitos, quanto para a fase de auditoria da etapa sob análise.
Para exemplificar como o DALF-MCC processa a avaliação dos pré-requisitos da Etapa 0
(Adequação da MCC), conforme explicitado no Capítulo 5, considerar-se-á: os resultados obtidos
nos itens precedentes para os critérios 1 a 3 (Situações 1 a 3); e uma avaliação simulada dos
critérios 4 e 5 necessários para compor a avaliação da Etapa 0. Para simular os resultados da
avaliação dos critérios 4 e 5, mostrados na Figura 6.9, foram consideradas as seguintes
ponderações para os quesitos que os compõe:
Figura 6.8 – Processo de Inferência
Fuzzy
com Atribuição de Nota e Conceito.
Agregação
Nota = 4,253
1 2 3 4 5 6 7 8 9 10
μ
1
Condensação ou desfuzzyficação
C3 - Sistema Computacional de Suporte
253,4
)(∑
).(∑
1
∈∀
∈∀
==
Ci
UC
CiCi
UC
A
Ax
C
Ci
Ci
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
2
1).13(
)
2
5,0).34(
2
5,0).23(
(
2
1).13(
)
2
8,0).4,13(
2
2,0).8,12(
(
2
1).24(
2
1).13(
.5,7)
2
5,0).34(
.5
2
5,0).23(
.5,2(
2
1).13(
.5,2)
2
8,0).4,13(
.5,2
2
2,0).8,12(
.95,0(
2
1).24(
.5
Q2 - Gestão da informação
Ruim Baixa Boa Alta Ótima
1 2 3 4 5 6 7 8 9 10
μ
1
Nota = 1,8
C3 - Sistema Computacional de Suporte
Ruim Baixa Boa Alta Ótima
1 2 3 4 5 6 7 8 9 10
μ
1
Implicação
Q4 - Afinidade/Treinamento com o sistema
Ruim Baixa Boa Alta Ótima
1 2 3 4 5 6 7 8 9 10
μ
1
Nota = 3,5
Implicação
Ruim Baixa Boa Alta Ótima
1 2 3 4 5 6 7 8 9 10
μ
1
C3 - Sistema Computacional de Suporte
Ruim Baixa Boa Alta Ótima
1 2 3 4 5 6 7 8 9 10
μ
1
Ruim Baixa Boa Alta Ótima
1 2 3 4 5 6 7 8 9 10
Implicação
Conceito = Boa
Q3 - Gestão da manutenção
Ruim Baixa Boa Alta Ótima
1 2 3 4 5 6 7 8 9 10
μ
1
Conceito = Baixa
Ruim Baixa Boa Alta Ótima
1 2 3 4 5 6 7 8 9 10
μ
1
C3 - Sistema Computacional de Suporte
Implicação
Ponderação
Q5 - Integração com outros sistemas
Ruim Baixa Boa Alta Ótima
1 2 3 4 5 6 7 8 9 10
μ
1
Conceito = Alta
Ruim Baixa Boa Alta Ótima
1 2 3 4 5 6 7 8 9 10
μ
1
C3 - Sistema Computacional de Suporte
Implicação
169
Critério: (C4)
–
Cultu
r
a da Manutenção/Empresa
Quesitos: Nota:
(Q1)
–
Re
g
istro das ações de manutenção 7,5
(Q2)
–
Função estraté
g
ica da manutenção Alta
(Q3)
–
Motivação da equipe 6
(Q4)
–
Experiência metodoló
g
ica Boa
(Q5)
–
Atualização e Auditoria Ótima
Critério: (C5)
–
Gerenciamento Estraté
g
ico da Manutenção
Quesitos: Nota:
(Q1)
–
Orçamento 1,8
(Q2)
–
Conformidade or
g
anizacional Boa
(Q3)
–
Aporte de recursos Alta
(Q4)
–
Apoio metodoló
g
ico 9
(Q5)
–
Terceirização Baixa
A Figura 6.10 ilustra o processo de inferência para avaliação da Etapa 0, supondo os
resultados precedentes referentes aos critérios 1 a 5.
Figura 6.10 – Processo de Inferência
Fuzzy
para Avaliação da Etapa 0.
Condensa
ç
ão ou Desfuzz
y
fica
ç
ão
Implicação
Conjuntos
Fuzzy
resultantes da Avaliação dos Critérios (C1 à C5) da Etapa 0
Nota = 5,745
1 2 3 4 5 6 7 8 9 10
μ
1
C1 - Disponibilidade da Informação/Recursos
Nota = 4,599
1 2 3 4 5 6 7 8 9 10
μ
1
C2 - Condição e Desempenho Atual da Manutenção
Nota = 6,420
1 2 3 4 5 6 7 8 9 10
μ
1
C4 - Cultura da Manutenção/Empresa
Nota = 5,037
1 2 3 4 5 6 7 8 9 10
μ
1
C5 - Gerenciamento Estratégico da Manutenção
Nota = 4,253
1 2 3 4 5 6 7 8 9 10
μ
1
C3 - Sistema Computacional de Suporte
1 2 3 4 5 6 7 8 9 10
μ
1
Etapa 0 (Adequação da MCC)
1 2 3 4 5 6 7 8 9 10
μ
1
Etapa 0 (Adequação da MCC)
1 2 3 4 5 6 7 8 9 10
μ
1
Etapa 0 (Adequação da MCC)
1 2 3 4 5 6 7 8 9 10
μ
1
Etapa 0 (Adequação da MCC)
1 2 3 4 5 6 7 8 9 10
μ
1
Etapa 0 (Adequação da MCC)
1 2 3 4 5 6 7 8 9 10
μ
1
Etapa 0 (Adequação da MCC)
Agregação
Nota = 5,188
Figura 6.9 – Conjuntos
Fuzzy
Resultantes da Avaliação Simulada de C4 e C5 da Etapa 0.
μ
1
C4 - Cultura da Manutenção/Empresa
)(∑
).(∑
1
∈∀
∈∀
Ci
UC
CiCi
UC
A
Ax
C
Ci
Ci
=
1 2 3 4 5 6 7 8 9 10
Nota = 6,420
Condensação ou Desfuzzyficação
Nota = 5,037
1 2 3 4 5 6 7 8 9 10
μ
1
Condensação ou Desfuzzyficação
C5 - Gerenciamento Estratégico da Manutenção
6.420
2
1).12(
2
1).24(
2
1).24(
2
1).13(
2
1).13(
2
1).12(
.22,9
2
1).24(
.5
2
1).24(
.5
2
1).13(
.5,7
2
1).13
.5,7
=
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
(
037,5
2
1).13(
2
1).12(
2
1).13(
2
1).24(
)
2
8,0).4,13(
2
2,0).8,12(
(
2
1).13(
.5,2
2
1).12(
.22,9
2
1).13(
.5,7
2
1).24(
.5)
2
8,0).4,13(
.5,2
2,0).8,12(
.95,0(
=
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
2
170
Conforme explanado anteriormente, ao longo do processo de inferência explicitado neste
item, são geradas mensagens para o usuário para a composição do relatório final. Detalhes da
composição deste relatório são objeto de explanação do Apêndice G.
6.6 CONSIDERAÇÕES E SÍNTESE DO CAPÍTULO
Este capítulo abordou a consolidação da metodologia proposta em um SBC-
Fuzzy
, aqui
nomeado DALF-MCC, para avaliação dos pré-requisitos e auditoria das etapas do processo de
implantação da MCC. Também foram explicitados os mecanismos utilizados para tratamento das
incertezas inerentes ao processo decisório, os quais objetivam auxiliar o usuário em sua tomada de
decisão ao longo da implementação das etapas da MCC.
Com os resultados demonstrados neste capítulo foi possível comprovar a possibilidade e a
viabilidade da utilização de SBC’s
Fuzzy
para tratar as incertezas inerentes à implantação da MCC,
tanto na fase de análise dos pré-requisitos quanto na fase de auditoria das etapas implementadas.
Estes resultados foram obtidos a partir da incorporação ao DALF-MCC de conceitos relativos à
gestão do conhecimento. Desta forma foi possível conceber mecanismos para facilitar a explicitação
do conhecimento tácito que os envolvidos, com o processo de implantação da MCC, têm da
empresa e do sistema no qual se quer implantar a MCC. A síntese e o tratamento das incertezas
inerentes ao uso deste conhecimento no processo decisório, proporcionados pelo DALF-MCC,
contribuem para: aumentar a confiabilidade do processo de tomada de decisão, tanto na fase de
análise dos pré-requisitos quanto na fase de auditoria; certificação de que a visão holística e o
atendimento as normas e/ou procedimentos de referência foram contemplados no processo de
análise; melhorar a agilidade e a eficiência do processo de implantação da MCC; e para a criação de
uma base de conhecimento para análises futuras da evolução da empresa, na aderência as
necessidades da MCC.
Além das vantagens relativas ao uso do conhecimento tácito explicitado na ponderação dos
quesitos, citadas no parágrafo anterior, cabe ressaltar também os benefícios inerentes às
funcionalidades apresentadas pelo DALF-MCC, dentre as quais: interface amigável com o usuário e
relatórios elucidativos que podem servir de instrumento para capacitação de pessoal na análise dos
pré-requisitos e auditoria das etapas de um processo de implantação da MCC; e a incorporação de
ferramentas de apoio a implementação das Etapas 3, 4 e 5 do processo de implantação da MCC (Ver
Apêndice G).
Como vantagens das funcionalidades e mecanismos supra-citados tem-se: a antecipação da
aderência da empresa/sistema às necessidades da MCC; a garantia da correta execução das etapas; e
apoio à implementação das etapas mais expressivas (Etapas 3, 4 e 5), as quais serão abordadas no
próximo capítulo e, objetivam minimizar alguns dos fatores críticos constatados durante a fase de
aquisição de conhecimento do DALF-MCC.
171
CAPÍTULO 7
FERRAMENTAS COMPUTACIONAIS DE APOIO À MCC
7.1 INTRODUÇÃO
Durante a fase de elicitação do conhecimento do DALF-MCC (Diagnóstico Auxiliado por
Lógica
Fuzzy
para a Manutenção Centrada na Confiabilidade) foi constatado que muitos dos
fatores críticos para o sucesso de programas de MCC (Manutenção Centrada na Confiabilidade)
se devem a falta de subsídios adequados para auxiliar a implementação das etapas. Esta
constatação é particularmente válida para as etapas mais expressivas do processo de implantação
da MCC, as quais são: Etapa 3 (Análise dos Modos de Falha, seus Efeitos e sua Criticidade –
FMECA); Etapa 4 (Seleção das Funções Significantes e Classificação de seus Modos de Falha); e
Etapa 5 (Seleção das Tarefas de Manutenção Aplicáveis e Efetivas).
O escopo deste capítulo é, portanto, sugerir ferramentas computacionais para auxiliar a
implementação das Etapas 3, 4 e 5, do procedimento de referência adotado neste trabalho, de
forma a minimizar os fatores críticos constatados durante a fase de aquisição de conhecimento do
DALF-MCC. As ferramentas aqui propostas foram incorporadas ao DALF-MCC e podem ser
acessadas através do menu Apoio à Implementação (Figura 7.1). Mais detalhes das ferramentas
computacionais tratadas neste capítulo são mostrados no Apêndice G.
Durante a fase de elicitação do conhecimento do DALF-MCC, foi evidenciado que muitos dos insucessos dos
programas de MCC
se devem a dificuldades na implementação de etapas relevantes, tipicamente as Etapas 3, 4 e 5 do
procedimento de referência
. Assim algumas ferramentas, foram desenvolvidas e incorporadas ao DALF-MCC para
auxiliar a implementação destas Etapas. As funcionalidades propostas podem ser acessadas clicando nos ícones
correspondentes abaixo.
Etapa 3 - Análise dos Modos de Falha seus Efeitos e sua Criticidade (FMECA):
Open-FMECA
: Software com código fonte aberto, para auxiliar o uso da técnica FMECA, desenvolvido para ser
instalado em um servidor e utilizado via navegador de internet (
browser
).
FMECA-Delphi: Software que utiliza a técnica Delphi para elicitação do Número de Prioridade de Risco (NPR), com
especialistas não presenciais, cooperando em um ambiente virtual.
NPR-Fuzzy: Software para elicitação do NPR que utiliza a Lógica Fuzzy como ferramenta de apoio a tomada de
decisão e tratamento das incertezas inerentes.
Etapa 4 - Seleção e Caracterização das Funções Significantes:
DALF-Diagramas
: Sistema Baseado em Conhecimento Fuzzy (SBC-Fuzzy) que auxilia a seleção e a caracterização das
funções significantes listadas na Etapa 3, utilizando um processo de inferência Fuzzy baseado na ponderação de Quesitos.
Etapa 5 - Seleção das Tarefas de Manutenção Aplicáveis e Efetivas:
DALF-Diagramas
: SBC-Fuzzy que auxilia a seleção das tarefas de manutenção aplicáveis e efetivas para cada uma das
funções significantes apontadas na Etapa 4, utilizando um processo de inferência Fuzzy baseado na ponderação de Quesitos.
Figura 7.1 – Tela de Acesso aos Softwares de Apoio a Implementação da MCC.
As ferramentas computacionais, propostas neste trabalho, objetivam tratar aspectos
específicos das etapas supracitadas e que podem dificultar ou inviabilizar a implementação da
MCC, tais ferramentas são:
172
Etapa 3:
• OpenFMECA: Software para auxiliar o uso da técnica FMECA desenvolvido para ser
instalado em um servidor e utilizado via navegador de internet (
browser
);
• FMECA-Delphi: Software que utiliza a técnica Delphi para elicitação do Número de
Prioridade de Risco (NPR) com especialistas não presenciais, cooperando em um
ambiente virtual;
• NPR-Fuzzy: Software para avaliação do NPR que utiliza a lógica
Fuzzy
como ferramenta
de apoio a tomada de decisão e tratamento das incertezas inerentes.
Etapa 4:
• DALF-Diagramas: Sistema Baseado em Conhecimento
Fuzzy
(SBC-
Fuzzy
) que auxilia a
seleção e a caracterização das funções significantes listadas na Etapa 3, utilizando um
processo de inferência
Fuzzy
baseado na ponderação de quesitos.
Etapa 5:
• DALF-Diagramas: parte integrante do software proposto para a Etapa 4 trata-se de um
SBC-
Fuzzy
que auxilia a seleção das tarefas de manutenção aplicáveis e efetivas, para
cada uma das funções significantes apontadas na Etapa 4. Utiliza um processo de
inferência
Fuzzy
baseado na ponderação de quesitos.
Os próximos itens e o Apêndice G apresentam em detalhes cada um dos softwares
propostos e os motivos que ensejaram seu desenvolvimento, como subsídio para minimizar os
fatores críticos inerentes ao processo de implantação da MCC.
7.2 PROPOSTAS PARA IMPLEMENTAÇÃO DA ETAPA 3
Embora a FMECA (Etapa 3 do procedimento de referência) seja uma metodologia
consagrada para análise das causas e principalmente dos efeitos dos modos de falha, algumas
limitações, de natureza administrativa e técnica, são observadas na sua aplicação prática. As
questões administrativas, segundo Antonietti (2002), envolvem: dificuldades no relacionamento
interpessoal; e falhas no planejamento e na condução das reuniões. As questões técnicas, segundo
Garcia (2006), envolvem: desconhecimento dos aspectos teóricos e práticos da aplicação da
metodologia de FMECA; falta de conhecimento técnico dos participantes da equipe de FMECA; e
limitações diversas relacionadas à atribuição dos fatores que compõem o NPR. Além da
bibliografia pesquisada, a elicitação do conhecimento com especialistas em MCC, durante o ciclo
incremental de desenvolvimento do DALF-MCC, revelou problemas semelhantes, os quais
impactam negativamente a implantação da MCC. Assim 3 ferramentas computacionais, tratadas
173
individualmente nos próximos itens, foram desenvolvidas como proposta deste trabalho para
subsidiar a implementação da Etapa 3.
7.2.1 OpenFMECA – Suporte à Implementação da FMECA
Para auxiliar e conduzir a implementação da FMECA, foi desenvolvido no Núcleo de
Desenvolvimento Integrado de Produtos (NeDIP / EMC / UFSC), em um projeto fomentado pelo
Conselho Nacional de Desenvolvimento Científico e Tecnológico (CNPq), um software chamado
de OpenFMECA. Trata-se de um software com código fonte aberto (
open source
), para ser
instalado em um servidor e utilizado via navegador de internet (
browser
). A elaboração de
software livre e, portanto, com código fonte aberto é uma das diretrizes do governo federal e
corroborada pela maioria dos estados brasileiros (CISL, 2008). Para o seu desenvolvimento foi
adotado a orientação a objeto, com modelo do ciclo de vida incremental.
Em virtude da decisão de se utilizar um navegador como interface, a programação do
OpenFMECA foi desenvolvida valendo-se de recursos de PHP, JavaScript e MySQL, permitindo que
o mesmo seja multiplataforma (possível de ser implementado em Windows, Linux e outros sistemas
operacionais). Como navegador padrão foi utilizado o Mozilla Firefox. O modelo de implementação
escolhido foi o “em camadas”. A mais próxima do usuário foi denominada “Interface”, a qual faz a
conexão entre as requisições do usuário e o sistema, além da apresentação do sistema de maneira
conveniente e intuitiva, gerando relatórios e páginas de visualização dos dados. A camada que contém
o sistema foi denominada “Domínio” e a última camada é o Banco de Dados.
Para a camada de Interface, foi utilizado o modelo de requisições de páginas “http” com
solicitações assíncronas em JavaScript, destacadamente AJAX (acrônimo para
asynchronous
Javascript and XML
). Esta decisão permitiu um maior controle sobre as ações do usuário e
possibilitou diminuir o tráfego de dados com o servidor, uma vez que apenas as informações
novas são enviadas ao cliente. A linguagem JavaScript também foi escolhida por aprimorar a
interface com o usuário do sistema, possibilitando respostas mais rápidas aos estímulos do
usuário. Como biblioteca optou-se pelo uso da XAJAX uma biblioteca PHP com código fonte
aberto, para fazer aplicações web baseadas em AJAX.
Na camada Domínio estão inseridas as regras e as estruturas de dados necessárias para
representar a FMECA, utilizando-se a linguagem PHP.
As tabelas no Banco de Dados foram desenvolvidas para dar suporte ao modelo adotado, o qual
prevê a criação de uma tabela para cada classe de objeto, com uma coluna para cada atributo e uma linha
para cada instância da classe. Quanto aos aspectos relevantes do OpenFMECA, destacam-se:
• Instalação em servidor e utilização via navegador de internet, o que trás os seguintes
benefícios:
174
→ Possibilidade de utilização em qualquer sistema computacional (computadores pessoais ou
palmtops) ou sistema operacional (Windows, Linux ou Mac) com acesso a internet por
meio de um browser (preferencialmente Mozilla Firefox);
→ Possibilidade de elaboração da FMECA de forma distribuída, ou seja, mais de uma
pessoa trabalhando na mesma FMECA, em postos de trabalho diferentes. Neste
sentido, poder-se-ia conceber a execução da FMECA de maneira não presencial,
eliminando ou minimizando a necessidade das reuniões. A proposta de conciliar a
técnica Delphi à FMECA, descrita no próximo item deste capítulo, vai de encontro
desta abordagem. O FMECA-Delphi apresenta um método para elicitação do NPR que
dispensa a necessidade de reuniões com especialistas presenciais em horários
predeterminados;
→ Utilização do
browser
como interface, o que diminui a curva de aprendizado do
usuário, visto que, usualmente, ele está familiarizado a este ambiente;
→ Possibilidade de ser utilizado de qualquer local, sem a necessidade de instalação de
software específico, não vinculando o trabalho a uma determinada máquina.
• O OpenFMECA tem seu código fonte aberto, o que permite aos usuários adaptá-lo às
necessidades da organização onde o mesmo será implementado;
• Além das abordagens tradicionais, o OpenFMECA propõe que a análise para a elaboração
da FMECA seja feita na forma de árvore. Isso permite melhor visualização da FMECA em
relação à representação em forma de tabela que, de acordo com Lee (2001), é fracamente
estruturada e semanticamente pobre;
• O OpenFMECA contribui com a gestão do conhecimento, uma vez que além dos
elementos normatizados da FMECA, permite também a inclusão de textos descritivos e,
para as próximas versões, propõem-se a inclusão de figuras ilustrativas.
A estrutura de tabelas e informações relativas à FMECA, utilizada no OpenFMECA,
segue as recomendações da SAE J1739. A interface e a estrutura do OpenFMECA são mostrados
em detalhes no Apêndice G.
7.2.2 FMECA-Delphi – Técnica Delphi para Elicitação do NPR
Uma das grandes dificuldades da avaliação da criticidade na FMECA (Etapa 3 do
procedimento de referência) é a necessidade de reunir todos os especialistas para que se
obtenha consenso quanto ao valor de cada índice. Este processo é, normalmente, feito de
maneira não estruturada, onde cada participante apresenta seu ponto de vista e, por confronto
direto, tenta-se chegar a um consenso. Além da dificuldade de coincidir a agenda de todos os
participantes, os quais usualmente são “pessoas-chave” nas empresas em suas respectivas
áreas de atuação, o processo de convergência das opiniões em uma reunião convencional
175
carrega uma série de inconvenientes, tais como (DALKEY, 1967 e DALKEY, 1968): a
presença de um participante dominante; a capacidade de persuasão de cada um; a tendência do
participante querer ter a aprovação da equipe; a resistência de mudar de opinião depois de expô-la
ao grupo; a pressão para se alcançar um consenso; e o ruído causado por material redundante ou
irrelevante que ofusca materiais relevantes.
Este trabalho propõe o uso da técnica Delphi, explicitada no Capítulo 4 e Apêndice B,
como recurso para amenizar os problemas citados no parágrafo anterior. Assim, foi desenvolvida
no âmbito do NEDIP, uma ferramenta computacional nomeada FMECA-Delphi, a qual incorpora
a técnica Delphi para possibilitar a elicitação, de maneira não presencial, dos índices (Severidade,
Ocorrência e Detecção) que compõem a avaliação da criticidade na FMECA.
A implementação do FMECA-Delphi incluiu o desenvolvimento de uma página na internet,
onde cada especialista pode manifestar sua opinião quanto aos índices avaliados. Usualmente,
apenas especialistas que fazem parte do grupo de FMECA podem emitir sua opinião. Com o uso da
técnica Delphi é possível envolver um número muito maior de participantes, aumentando o
comprometimento do corpo técnico com os resultados da FMECA, além de se ter a expectativa de
que a resposta seja menos tendenciosa e se aproxime mais da “resposta verdadeira”.
O processo de determinação dos índices inicia com o cadastramento dos participantes.
Caso os formulários sejam submetidos apenas aos membros do grupo da FMECA, presume-se que
este passo já tenha sido cumprido anteriormente. De qualquer forma, é importante traçar o perfil
de cada participante, destacando-se o tempo de experiência na área. Adicionalmente, é importante
fornecer aos participantes um texto apresentando o método proposto com as devidas instruções.
Pode-se, então, partir para a primeira iteração, a qual está subdividida em 4 passos:
1) Preenchimento do Formulário
Cada participante é solicitado a preencher um formulário com um campo para ponderar o
valor do índice que ele considera adequado e outro campo para informar o quão confiante ele está
na resposta (baseado em uma escala pré-determinada).
2) Elaboração de Estatísticas
Para cada índice questionado, calcula-se a média e o desvio padrão (alternativamente
pode-se utilizar a mediana e os
quartis
inferior e superior). Estes valores serão apresentados aos
especialistas juntamente com as justificativas na iteração seguinte.
3) Solicitação de Justificativas
Solicita-se, então, que os entrevistados que responderam o valor do índice fora da região
central (faixa de um desvio padrão abaixo e acima da média), exponham brevemente as
informações em que se basearam para estimar aquele valor.
176
4) Tratamento das Informações Apresentadas nas Justificativas
Uma vez coletadas as informações do campo da justificativa dos valores atribuídos aos
índices, o moderador pode categorizá-las e levantar a freqüência de ocorrência de cada categoria.
Estas informações, juntamente com as estatísticas do valor do índice, são apresentadas aos
entrevistados na segunda iteração do processo acima.
Caso não se alcance um consenso quanto ao valor do índice ou uma dispersão que o
moderador considere razoável, após a segunda iteração, pode-se fazer uma terceira. No entanto, não
se recomenda que sejam feitas mais de três iterações, para evitar os efeitos indesejados constatados
por Gupta e Clarke (1996), os quais são mostrados no Apêndice B. Por fim, é feita a ponderação
das respostas, baseando-se nos índices de quão confiantes os entrevistados estavam na resposta e no
tempo de experiência na área de cada um (Equação 7.1, adaptada de CARMO, 2004):
∑
∑
1
2
1
2
).(
.).(
n
i
ii
n
i
iii
sy
xsy
w
=
=
=
7.1
Onde:
• w é o valor do índice (Severidade, Ocorrência ou Detecção) ponderado pela
experiência e confiança na estimativa feita pelo especialista;
• y
i
é o número de anos de experiência do i-ésimo especialista;
• s
i
é a nota que o i-ésimo especialista atribuiu para o grau de confiança na
estimativa do valor do índice; e
• x
i
é a estimativa do valor do índice feita pelo i-ésimo especialista.
Este trabalho propõe que os valores para os índices de Severidade (S), Ocorrência (O) e
Detecção (D) sigam as orientações da SAE J1739 (SAE, 2002), enquanto que os valores do Grau
de Confiança (GC), que expressa quão confiante se está na estimativa do valor atribuído ao
respectivo índice (S, O, ou D), sigam a escala apresentada na Tabela 7.1. Desta forma pode-se dar
mais peso às respostas em que o entrevistado tenha mais experiência e esteja mais confiante, o
que aumenta os indícios para uma “resposta verdadeira”.
Quanto aos aspectos relevantes do FMECA-Delphi, destacam-se:
• O método proposto não exige simultaneamente a presença física dos participantes da
FMECA em um determinado local. Isto torna mais maleável a participação dos
especialistas que podem preencher os índices da tabela de FMECA de acordo com a sua
agenda, sem a necessidade de conciliar seus horários com outros;
• A elicitação dos índices de forma não presencial minimiza os inconvenientes das reuniões,
decorrente da interação do grupo, mostradas no Capítulo 4 e Apêndice B;
177
• Pode-se incluir na análise pessoas que não fazem parte do grupo da FMECA, o qual
normalmente é conciso com poucos ou, usualmente, apenas um representante de cada
área. Isto pode aumentar o comprometimento do corpo técnico da organização com os
resultados da FMECA, principalmente no que se refere aos planos de ações resultantes;
• Um número maior de participantes possibilita estatísticas mais representativas, além de,
possivelmente, direcionar a tendência central no sentido da “resposta verdadeira”;
• A comunicação via internet agiliza a coleta das opiniões dos especialistas e o
processamento das informações pelo moderador da FMECA.
Tabela 7.1 – Escala de Valores para Estimativa do Grau de Confiança.
Fonte: adaptada de CARMO, 2004.
Grau de Confiança Critério Classificação
O especialista tem absoluta confiança de que o índice (S, O ou D) está
avaliado corretamente.
10
Totalmente
Confiante
O especialista está totalmente confiante de que o índice (S, O ou D) está
avaliado corretamente.
9
Muito Confiante
O especialista tem muita confiança de que o índice (S, O ou D) está
avaliado corretamente.
7 ou 8
Confiante
O especialista está confiante de que o índice (S, O ou D) está avaliado
corretamente.
5 ou 6
Razoavelmente
Confiante
O especialista está razoavelmente confiante de que o índice (S, O ou D)
está avaliado corretamente.
3 ou 4
O especialista está pouco confiante de que o índice (S, O ou D) está
avaliado corretamente.
2
Pouco Confiante
O especialista não tem confiança de que o índice (S, O ou D) está
avaliado corretamente.
1
A interface e a estrutura do FMECA-Delphi são mostrados em detalhes no Apêndice G.
7.2.3 NPR-Fuzzy – Lógica
Fuzzy
para Avaliação do NPR
O NPR-Fuzzy é uma ferramenta computacional, mais precisamente um SBC-
Fuzzy
, que faz
uso da lógica
Fuzzy
para avaliar o NPR. A proposta de concepção e as funcionalidades requeridas do
NPR-Fuzzy nasceram de necessidades específicas do processo de implantação da Etapa 3 da MCC,
detectadas ao longo da interação com os especialistas durante a fase de elicitação do conhecimento do
DALF-MCC. Estas necessidades estão principalmente atreladas aos seguintes fatores: receio e/ou
incapacidade dos especialistas em avaliar quantitativamente os índices que compõem o NPR
(Severidade, Ocorrência e Detecção); e inconsistência dos termos lingüísticos normatizados para uma
avaliação qualitativa, ou seja, em algumas aplicações não há consenso entre os especialistas da faixa
de valores quantitativos representada pelos termos lingüísticos. Nestes casos é importante uma
adequação consensual prévia entre os termos lingüísticos a serem utilizados e a faixa de valores
quantitativos que os mesmos representam. Invariavelmente, esta adequação está vinculada a valores e
critérios institucionais e características específicas do sistema a ser analisado; e questões práticas e
178
conceituais inerentes a concepção/formação do NPR, tanto na proposta da SAE-J1739 quanto na
proposta da MIL-STD-1629A, entre estas se destacam:
SAE-J1739
A multiplicação dos índices de Severidade, Ocorrência e Detecção, proposta pela SAE-
J1739 para a avaliação do NPR, apresenta os seguintes inconvenientes (BOWLES, 2003):
• É possível obter um NPR relativamente baixo (S=10, O=1, D=1, NPR=10) com uma
severidade alta que pode inviabilizar todo um processo produtivo. Ao mesmo tempo, é
possível ter um NPR relativamente alto (S=5, O=5, D=5, NPR=125) com índices
moderados de Severidade, Ocorrência e Detecção. Uma análise descuidada pode concluir
intuitivamente que o primeiro caso é menos crítico do que o segundo, culminando com a
proposição de ações corretivas em detrimento de ações preventivas;
• É possível obter os mesmos valores de NPR para modos de falha distintos, por exemplo:
S=2, O=4 e D=9 resulta no mesmo NPR de S=9, O=4 e D=2, o que dificulta a
classificação e/ou priorização dos modos de falha;
• Independente da escala adotada, não é possível a obtenção de números primos maiores
que 10 na multiplicação dos 3 fatores que compõem o NPR, o que limita o conjunto de
valores válidos e gera lacunas em sua escala;
• A escala de valores, dos fatores que compõem o NPR, muitas vezes não é customizada
pelas empresas para se adequar ao objeto de estudo e/ou aos termos lingüísticos
normalmente adotados pelos especialistas do grupo de FMECA. Esta prática pode
culminar com avaliações equivocadas dos fatores que compõem o NPR.
MIL-STD-1629A
A priorização dos modos de falha com o uso da matriz de criticidade, proposta pela MIL-
STD-1629A, apresenta os seguintes inconvenientes:
• Não considera a dificuldade de detecção das causas da falha, do modo de falha ou de seus
efeitos;
• Nem sempre é possível, na prática, ter dados históricos das falhas que permitam uma
análise quantitativa adequada às necessidades da MIL-STD-1629A as quais são:
probabilidade do modo de falha, probabilidade condicional do efeito do modo de falha,
taxa de falha do componente (por 10
6
horas ou ciclos).
Para minimizar os problemas supracitados, normalmente recorre-se a considerações
heurísticas dos especialistas e não apenas ao NPR, calculado de acordo com a SAE J1739 ou a
criticidade apontada conforme recomendações da MIL-STD-1629A. No entanto, esta análise é
feita, usualmente, de forma subjetiva, sem uma regra clara, e o resultado dependerá da aversão ou
propensão do analista/especialista ao risco.
179
Vale lembrar que, modos de falha mal avaliados resultam em prioridades incorretas,
levando a ações mal sucedidas que não impactam da forma esperada no sistema sob análise.
Ações adicionais, além das previstas na FMECA são, invariavelmente, necessárias nestes casos.
Estas situações podem impactar negativamente na credibilidade e eficácia do programa de MCC,
podendo resultar, em casos críticos, no seu abandono.
O NPR-Fuzzy foi concebido nos moldes do DALF-MCC para minimizar o impacto das
incertezas e limitações apresentadas nos parágrafos anteriores para avaliação da criticidade, a qual
influencia diretamente o sucesso da implementação da Etapa 3 da MCC. Dentre os atributos e
funcionalidades do NPR-Fuzzy destacam-se:
• A possibilidade de independência na atribuição da escala de valores quantitativos aos termos
lingüísticos qualitativos utilizados na atribuição dos fatores que compõem o NPR
(Severidade, Ocorrência e Detecção). Assim, os especialistas e/ou analistas podem utilizar
termos lingüísticos atrelados a valores de consenso e adaptados a realidade e/ou exigências
da empresa/sistema. A Tabela 7.2 mostra os termos lingüísticos (termos primários)
utilizados no NPR-Fuzzy para ponderação de cada item que compõe a avaliação do NPR.
Tabelas normatizadas, extraídas da
SAE J1739/2002 e presentes do Apêndice A, também
poderão ser utilizadas para balizar a ponderação dos especialistas e/ou analistas;
Tabela 7.2 – Termos Lingüísticos (Primários) Utilizados no NPR-Fuzzy.
Severidade do Efeito (S)
Probabilidade de Ocorrência
da Falha (O)
Chances de Detecção (D)
Pequena Remota Certa
Baixa Baixa Alta
Moderada Moderada Moderada
Alta Alta Remota
Muito Alta Muito Alta Muito Remota
• A Severidade pode ser ponderada de forma Global, considerando todos os efeitos, ou de
forma Individual, considerando as especificidades de cada efeito na composição do índice
de Severidade;
• Feita a ponderação pelos especialistas e/ou analistas, o NPR-Fuzzy permite a visualização
gráfica, com o respectivo valor
crisp
correspondente, de todos os índices (Severidade,
Ocorrência e Detecção) que compõe o NPR facilitando a tomada de decisão e
classificação/hierarquização dos modos de falha;
• A avaliação do NPR é feita por um SBC-
Fuzzy
, o qual além da visualização gráfica do
NPR avaliado apresenta, também, o valor
crisp
resultante da desfuzzyficação do conjunto
Fuzzy
formado pela agregação dos termos primários utilizados na ponderação dos índices
que compõe o NPR (Severidade, Ocorrência e Detecção).
A interface e a estrutura do NPR-Fuzzy são mostrados em detalhes no Apêndice G.
180
7.3 PROPOSTAS PARA IMPLEMENTAÇÃO DA ETAPA 4
A proposta deste trabalho, para apoio à implementação da Etapa 4 do procedimento de
referência, é um SBC-
Fuzzy
denominado DALF-Diagramas
1
(Decisão Apoiada por Lógica
Fuzzy
para aplicação dos Diagramas de Decisão da MCC), desenvolvido nos mesmos moldes do
DALF-MCC. O DALF-Diagramas auxilia a aplicação dos diagramas de decisão da MCC,
tratando as incertezas inerentes ao processo. Este tratamento se dá pela incorporação de termos
primários
Fuzzy
relativos ao nível de aderência da empresa/sistema a quesitos, os quais devem ser
ponderados pela equipe de implantação da MCC, durante a implementação da Etapa 4. A
utilização de termos primários (lingüísticos)
Fuzzy
se contrapõe às respostas simplistas do tipo
“Sim” ou “Não”, propostas pelas normas e bibliografias pesquisadas, para os questionamentos dos
diagramas de decisão da MCC. Os quesitos ponderados alimentam um processo de inferência
Fuzzy
que irá indicar qual o melhor caminho a seguir no diagrama de decisão. Para estruturar o
processo decisório, o DALF-Diagramas utiliza os diagramas de decisão propostos pela IEC
60300-3-11, adotados pelo procedimento de referência detalhado no Capítulo 5.
O DALF-Diagramas incorpora soluções para tratamento de incertezas das Etapas 4 e 5
do procedimento de referência. No caso específico de Etapa 4 as seguintes funcionalidades
estão disponíveis: Identificação/Definição da Significância ou Não da Função; e Classificação
dos Modos de Falha das Funções Significantes. Além destas funcionalidades, este trabalho propõe
a inclusão, nos diagramas de decisão da Etapa 4, de mecanismos para análise do risco, uma crítica
recorrente à MCC, explicitada no próximo item.
7.3.1 Análise de Risco nos Diagramas de Decisão da Etapa 4 da MCC
O tratamento de riscos de segurança relacionados às atividades de manutenção não são
adequadamente tratados pela MCC segundo Hauge e Johnston (2001), os autores afirmam que há
um “vazio” entre a MCC e a análise de risco.
Segundo Moubray (2001), as conseqüências para a segurança e o meio ambiente são
consideradas em uma questão específica do diagrama de decisão da MCC. No caso do
procedimento de referência adotado por este trabalho, a questão referida por Moubray (2001) está
1
Para o desenvolvimento do DALF-Diagramas foram selecionadas somente ferramentas de software livre, conforme segue:
Python 2.5.1 – Linguagem de programação (
http://www.python.org/); TK 8.4 – Módulo (
built-in
) Python de Interface Gráfica
(
http://www.tcl.tk/); LXML 1.3.4 – Módulo Python para manipulação de arquivos XML (http://codespeak.net/lxml/); Numpy
1.0.3.1 – Módulo Python para processamento matemático (
http://numpy.scipy.org/); Matplotlib 0.90.1 – Módulo Python para
plotagem de gráficos (
http://matplotlib.sourceforge.net/); PIL 1.1.6 – Módulo para processamento de imagens
(
http://www.pythonware.com/products/pil/); Py2exe 0.6.6 – Módulo para "construção" de aplicativos Windows
(
http://www.py2exe.org/); Txt2tags 2.4 – Script Python para geração de documentos HTML (http://txt2tags.sourceforge.net/);
FuzzyCLIPS 6.10d – Máquina de inferência
Fuzzy
(http://www.iit.nrc.ca/IR_public/fuzzy/fuzzyClips/fuzzyCLIPSIndex.html).
A codificação e estruturação dos arquivos HTML segue o padrão W3C chamado XML -
EXtensible Markup Language
(
http://www.w3schools.com/xml/default.asp).
181
contemplada no diagrama para identificação de função significante, onde um dos questionamentos
feitos para a equipe de implementação é: A perda da função tem efeito adverso de segurança ou
ambiental? Neste caso, a conseqüência para a segurança significa a possibilidade de ferir ou matar
alguém enquanto a conseqüência ambiental indica quebra de um regulamento ou padrão.
Hauge e Johnston (2001) concordam com a observação de Moubray (2001), entretanto,
afirmam que uma técnica de análise de risco pode resultar em maior consistência durante a
aplicação dos diagramas de decisão da MCC, evitando o tratamento simplista de “Sim” ou “Não”
comumente utilizado para evidenciar ou não o risco.
As evidências apontadas por Hauge e Johnston (2001) foram ratificadas ao longo do
processo de aquisição do conhecimento do DALF-MCC. Sendo assim, este trabalho propõe no
DALF-Diagramas, a inclusão de uma sistemática mais elaborada que, utilizando a lógica
Fuzzy
,
possa suscitar nos especialistas uma análise de risco mais aprofundada quando na determinação da
significância ou não da função. A metodologia incorporada no DALF-Diagramas está baseada na
proposta de Raposo (2004). Entretanto, o DALF-Diagramas acrescenta mecanismos para
implementação da metodologia e o tratamento por lógica
Fuzzy
das incertezas do processo
decisório, com objetivo de auxiliar a tomada de decisão. A metodologia que embasa os
questionamentos do DALF-Diagramas tem o objetivo de sensibilizar os envolvidos com o
processo de implementação da Etapa 4 para a reflexão e ponderação sobre os aspectos
relacionados ao risco, os quais impactam a identificação e caracterização das funções
significantes. As reflexões e ponderações suscitadas pelo DALF-Diagramas são:
Tipo e Extensão das Conseqüências
Quanto ao tipo de conseqüência, da falha funcional ou do modo de falha, esta pode ser
caracterizada por afetar a saúde, a vida ou a segurança do operador e/ou da coletividade ou ainda
uma lei ou padrão ambiental. Quanto à extensão das conseqüências, da falha funcional ou do
modo de falha, esta pode transcender ou estar restrita aos limites do sistema/empresa.
Graduação da Severidade das Conseqüências
O objetivo deste tópico nos questionamentos do DALF-Diagramas é garantir que a equipe
de implementação da Etapa 4 reflita sobre a severidade das conseqüências, levando em conta a
graduação proposta na Tabela 7.3.
182
Tabela 7.3 – Graduação da Severidade das Conseqüências.
Fonte: adaptado de Raposo, 2004.
Severidade Quanto a Segurança das Pessoas Quanto a Saúde das Pessoas
Quanto ao Impacto no Meio
Ambiente
Nenhuma Não há impacto na segurança.
Não há impacto na saúde das
pessoas.
Não há impacto sobre o meio
ambiente.
Baixa
Danos insignificantes em
equipamentos.
Necessita de pronto atendimento e
primeiros socorros.
Danos insignificantes ao meio
ambiente.
Moderada
Danos leves e controláveis em
equipamentos (baixo custo de reparo).
Princípio de incêndio (debelado pelo
operador).
Lesões leves em funcionários,
terceiros ou moradores vizinhos.
Acidentes sem afastamento.
Doenças ocupacionais não graves.
Danos leves e controláveis ao
meio ambiente.
Crítica
Danos severos em equipamentos.
Parada de unidade ou sistema.
Incêndio restrito (debelado pela
brigada interna).
Lesões ou doenças ocupacionais
severas em funcionários, terceiros
ou moradores vizinhos.
Acidentes com afastamento.
Probabilidade de morte remota.
Danos severos ao meio
ambiente.
Requer comunicação ao órgão
ambiental.
Muito Crítica
Danos irreparáveis em equipamentos.
Parada desordenada de unidade ou
sistema.
Incêndio de grandes proporções (requer
acionar plano de ajuda externa).
Morte, lesões ou doenças
ocupacionais de várias pessoas na
planta ou na comunidade vizinha.
Danos irreparáveis ao meio
ambiente.
Grau de Risco
Consiste na avaliação do Grau de Risco inerente a falha funcional ou ao modo de falha,
com auxílio da matriz de risco, a qual relaciona a severidade das conseqüências com a freqüência
de ocorrência da falha funcional ou do modo de falha. Este trabalho utiliza a Tabela 7.4, como
referencial para ponderação da freqüência de ocorrência.
Tabela 7.4 – Freqüência de Ocorrência da Falha Funcional ou do Modo de Falha.
Fonte: adaptado de Raposo, 2004.
Categoria / Denominação
Faixa de Freqüência
Anual
Descrição
Extremamente Remota f < 10
-4
Conceitualmente possível, mas extremamente remota de
ocorrer durante a vida útil da instalação.
Remota 10
-3
< f < 10
-4
Não é esperado que ocorra durante toda a vida útil.
Possível 10
-2
< f < 10
-3
É pouco provável que ocorra durante toda a vida útil.
Provável 10
-1
< f < 10
-2
É esperado que ocorra 1 vez durante a vida útil.
Muito Provável f > 10
-1
É esperado que ocorra várias vezes durante a vida útil.
O DALF-Diagramas utiliza a matriz de risco mostrada na Figura 7.2 para relacionar a
severidade das conseqüências, com a freqüência de ocorrência da falha funcional ou do modo de falha.
Muito Provável
3 2 1 1
Provável
4 3 2 1
Possível
5 4 3 2
Remota
5 5 4 3
Extremamente Remota
5 5 5 4
Baixa Moderada Crítica Muito Crítica
Figura 7.2 – Matriz para Avaliação do Grau de Risco.
Fonte: adaptado de Raposo, 2004.
183
Outros modelos de matriz de risco podem ser encontrados em: Lima (1999), Barreiro
(1999), DNV (2003), Hauge e Johnston (2001) e Melo
et al
(2002). Tais modelos variam em
número de linhas, colunas e denominações dadas ao Grau de Risco, entretanto, todas resultam em
uma graduação de risco que permite adotar as medidas mitigadoras necessárias para sua
eliminação ou redução.
A Tabela 7.5 mostra as categorias e as considerações para a equipe de implementação da
Etapa 4 da MCC, relativas à matriz de risco. O processo de inferência do DALF-Diagramas
considera que, se o Grau de Risco for 1, 2 ou 3, a falha funcional ou o modo de falha analisado tem
implicações no meio ambiente, saúde ou segurança e deve ser submetido à análise da MCC.
Durante a implementação da Etapa 5, para qualquer Grau de Risco elicitado na Etapa 4, a
equipe de implementação deve se assegurar de que as estratégias ou tarefas de manutenção
atendam às ações sugeridas na Tabela 7.5.
Tabela 7.5 – Categorias de Risco da Falha Funcional ou do Modo de Falha.
Fonte: adaptado de Raposo, 2004.
Grau de Risco Categoria Aceitabilidade Ações
1 Crítico Não Aceitável
2 Sério Indesejável
Verificar se existe alguma estratégia ou tarefa de manutenção
p
ara evitar a falha ou reduzir o risco para grau 3. Caso não haja,
o risco deve ser mitigado com reprojetos ou controles
administrativos para um grau menor ou igual a 3, no menor
tempo possível.
3 Moderado
Aceitável com
Controles
Verificar se existe alguma estratégia ou tarefa de manutenção
para evitar a falha. Caso não haja, deve ser verificado que
procedimentos ou controles podem ser implementados.
4 Menor
Aceitável com
Avisos
Sinalização e avisos são medidas necessárias. Verificar se alguma
estratégia ou tarefa de manutenção para evitar a falha é
economicamente viável.
5 Desprezível Aceitável Nenhuma mitigação requerida.
A interface e a estrutura do DALF-Diagramas para a Etapa 4 são mostrados em detalhes
no Apêndice G.
7.4 PROPOSTAS PARA IMPLEMENTAÇÃO DA ETAPA 5
O DALF-Diagramas também é a proposta deste trabalho para o tratamento das incertezas
inerentes ao processo decisório, de aplicação dos Diagramas de Decisão da Etapa 5 do
procedimento de referência. Neste caso, o DALF-Diagramas auxilia a decisão sobre a atividade
de manutenção mais adequada para o modo de falha sob análise (ESA, EEO, OSA ou OEO). A
opção de enquadramento do modo de falha pode ser um resultado das Análises da Etapa 4 ou uma
escolha direta do usuário que, neste caso, já teria o Modo de Falha devidamente classificado.
Para estruturar o processo decisório, o DALF-Diagramas utiliza os diagramas de decisão
propostos pela IEC 60300-3-11, adotados pelo procedimento de referência detalhado no Capítulo
5. Sendo assim, as seguintes atividades de manutenção são avaliadas pelo DALF-Diagramas a
184
partir de quesitos ponderados pelo usuário: Serviço Operacional, Inspeção Preditiva, Restauração
Preventiva, Substituição Preventiva, Inspeção Funcional, Manutenção Combinada, Mudança de
Projeto e Reparo Funcional.
A interface e a estrutura do DALF-Diagramas para a Etapa 5 são mostrados em detalhes
no Apêndice G.
7.5 CONSIDERAÇÕES E SÍNTESE DO CAPÍTULO
Este capítulo abordou as ferramentas computacionais, propostas por este trabalho, para
auxiliar a implementação das etapas 3, 4 e 5 do procedimento de referência. As funcionalidades, a
interface, os benefícios dos softwares desenvolvidos, assim como os métodos para tratamento das
incertezas (lógica
Fuzzy
) foram concebidos para minimizar alguns dos fatores críticos constatados
durante a fase de aquisição de conhecimento do DALF-MCC.
As soluções apresentadas neste capítulo podem agilizar a implementação das etapas mais
exaustivas do processo de implantação da MCC (Etapas 3, 4 e 5), seja pelas funcionalidades
apresentadas ou pelo apoio ao processo decisório inerente a algumas das ferramentas. Desta forma,
será possível minimizar o impacto de fatores que são críticos para a implementação das etapas
supracitadas, entre estes: formação de equipes multidisciplinares, com restrições de disponibilidade;
dificuldades no relacionamento interpessoal; desconhecimento dos aspectos teóricos e práticos das
ferramentas inerentes ao processo de implementação das etapas da MCC, em especial a FMECA e
os diagramas de decisão; e dificuldades diversas relacionadas à tomada de decisão frente a dados
qualitativos e com elevado grau de incerteza.
Além dos aspectos práticos, as ferramentas computacionais apresentadas neste
capítulo incorporam contribuições conceituais às metodologias tradicionais de implantação da
MCC, tais como: soluções para determinação do NPR quer seja por inferência
Fuzzy
de
termos lingüísticos qualitativos (NPR-Fuzzy) ou por uma abordagem holística com
especialistas não presenciais (FMECA-Delphi e Open-FMECA); e inclusão, nos diagramas de
decisão da MCC, da análise de risco e do impacto da falha funcional na imagem da empresa
(DALF-Diagramas).
Todas as ferramentas propostas incorporam requisitos da gestão de conhecimento,
principalmente àqueles relativos à explicitação do conhecimento tácito e ao apoio à tomada de
decisão e processamento de dados com incerteza intrínseca. Assim como no DALF-MCC, foi
também um requisito de projeto das ferramentas apresentadas, a preocupação com as
seguintes funcionalidades:
interface amigável com o usuário e ajuda sensível ao contexto em todas
as fases de utilização; relatórios elucidativos que podem servir de instrumento para capacitação de
pessoal no processo de implantação da MCC; e implementação de funcionalidades que
amenizassem ou eliminassem alguns dos fatores críticos do processo de implantação da MCC,
detectados ao longo da aquisição do conhecimento do DALF-MCC.
185
CAPÍTULO 8
VERIFICAÇÃO E VALIDAÇÃO DO PROTÓTIPO
8.1 INTRODUÇÃO
Este capítulo sintetiza o processo de verificação e validação do DALF-MCC (Diagnóstico
Auxiliado por Lógica
Fuzzy
para a Manutenção Centrada na Confiabilidade) cujo
desenvolvimento, conforme explicitado no Capítulo 4, seguiu o modelo incremental.
A etapa de verificação e validação foi utilizada neste trabalho para ratificar as
características almejadas do DALF-MCC, abordadas no Capítulo 1, em relação à: interface com o
usuário; funcionalidades requeridas; e exatidão da base de conhecimento. Tais quesitos estão em
conformidade com as considerações de Gonzalez e Dankel (1993), quanto aos erros mais comuns
cometidos em SBC’s (Sistemas Baseados em Conhecimento), os quais são: falta de especificações
ou simplesmente não utilização das especificações inicialmente estabelecidas; erros de operação
do programa computacional (
bugs
); e representação incorreta do conhecimento, gerando soluções
incorretas ou impossibilidade de se alcançar a solução correta.
O processo de verificação e validação englobou tanto o DALF-MCC quanto suas
ferramentas complementares (OpenFMECA, FMECA-Delphi, NPR-Fuzzy e DALF-Diagramas)
abordadas no Capítulo 7.
8.2 VERIFICAÇÃO
O processo de verificação, com os requisitos e critérios abordados no Capítulo 4, foi
desenvolvido pelo autor, por usuários do protótipo durante sua fase de implementação e, em
alguns aspectos, pelos especialistas que validaram o DALF-MCC e suas ferramentas
complementares. Neste processo os seguintes itens foram verificados: erros na lógica de
programação; erros de comunicação/interação entre os softwares utilizados, com especial atenção
para o FuzzyCLIPS e o
Visual Basic
; funcionalidade dos atributos implementados na interface
com o usuário (
links
externos, arquivo de ajuda, menus, parametrização dos conjuntos
Fuzzy
,
restrições ao usuário); e erros de ortografia e gramática na interface com o usuário.
Após as verificações supracitadas o procedimento adotado incluiu testes de caso com
objetivo de submeter o DALF-MCC e as ferramentas complementares a situações previamente
estabelecidas, em que já se tem o conhecimento do resultado, para comprovação de sua acurácia.
No caso do DALF-MCC, todas as etapas do procedimento de referência, tanto para a
análise de pré-requisitos como para a auditoria tiveram seus critérios e quesitos submetidos a
testes de caso. Entretanto, nem todas as combinações possíveis de entrada foram testadas devido
ao grande número de possibilidades para a ponderação da aderência da empresa/sistema ao
186
quesito a ser ponderado. Vale ressaltar que, cada quesito possui 5 entradas/ponderações possíveis,
caso a ponderação utilize um conceito
Fuzzy
(Ruim, Baixa, Boa, Alta ou Ótima) e, infinitos
valores numéricos dentro do intervalo de 0 a 10, referentes ao universo de discurso, caso a
ponderação utilize uma nota (valor
crisp
). No caso de uma ponderação com nota, conforme
mostrado no Capítulo 6, a mesma é fuzzyficada, resultando no grau de pertinência da nota ao
termo primário correspondente. No processo de teste de caso foi utilizado, para ponderação dos
quesitos, conceitos e notas. Para evidenciar a inviabilidade de se testar/simular todas as entradas
possíveis do DALF-MCC basta levar em conta que, caso fossem utilizados somente conceitos
(Ruim, Baixa, Boa, Alta ou Ótima), conforme mostrado na Tabela 8.1 se teria 5
92
possibilidades
de entrada para a análise de pré-requisitos e 5
132
possibilidades de entrada para a auditoria.
Tabela 8.1 – Dados Estatísticos do DALF-MCC.
Pré-Requisitos Auditoria
Etapa
Nº de
Critérios
Nº de Quesitos
por Critério
Nº Total de
Quesitos
Nº de
Critérios
Nº de Quesitos por
Critério
Nº Total de
Quesitos
0 5 4 | 4 | 5 | 5 | 5 23 1 5 5
1 4 4 | 5 | 3 | 3 15 4 6 | 4 | 4 | 4 18
2 2 6 | 5 11 2 5 | 4 9
3 2 6 | 5 11 4 5 | 5 | 5 | 4 19
4 1 5 5 2 4 | 4 8
5 2 5 | 3 8 6 4 | 7 | 6 | 5 | 6 | 6 34
6 1 5 5 3 7 | 4 | 5 16
7 2 4 | 3 7 2 5 | 4 9
8 2 3 | 4 7 3 5 | 5 | 4 14
Total
21 - 92
27 -
132
Portanto, em virtude das impossibilidades supra-citadas, foram simuladas as entradas
necessárias para testar todas as saídas possíveis, tanto àquelas relativas a ponderação dos quesitos
quanto as relativas à avaliação dos critérios e etapas. Sendo assim, foi adotado o seguinte
procedimento:
• Quanto aos quesitos, todas as possibilidades de conceitos, para cada quesito, foram simuladas,
tanto para o caso da análise dos pré-requisitos como para o caso da auditoria. Foram também
atribuídas notas (0,5 | 2,5 | 5 | 7,5 | 9,5), de forma que sua fuzzyficação resultasse nos cinco
conceitos possíveis para cada quesito (com base na Figura 4.7). Este procedimento foi adotado
para todos os quesitos. Foi simulada, ainda, a atribuição de notas que afetasse dois termos
primários simultaneamente. Neste caso, com os termos primários parametrizados, conforme a
Figura 4.7, foram simuladas quatro notas para todos os quesitos, a saber: 1,5 (termos afetados
Ruim e Baixa); 3,5 (termos afetados Baixa e Boa); 6,5 (termos afetados Boa e Alta) e, 8,5
(termos afetados Alta e Ótima). Este procedimento totalizou 3136 entradas (Pré-Requisitos =
1288 + Auditoria = 1848). A Tabela 8.2 resume as simulações de entrada, processadas pelo
DALF-MCC, para o caso dos quesitos.
187
Tabela 8.2 – Entradas Simuladas no DALF-MCC.
Pré-Requisitos Auditoria
Total de
Quesitos
Entradas Simuladas
Total de
Entradas
Simuladas
Total de
Quesitos
Entradas Simuladas
Total de
Entradas
Simuladas
92 5 Conceitos 460 132 5 Conceitos 660
92 5 Notas (0,5 | 2,5 | 5 | 7,5 | 9,5) 460 132 5 Notas (0,5 | 2,5 | 5 | 7,5 | 9,5) 660
92 4 Notas (1,5 | 3,5 | 6,5 | 8,5 ) 368 132 4 Notas (1,5 | 3,5 | 6,5 | 8,5 ) 528
Total 14 Entradas / Quesito 1288 Total 14 Entradas / Quesito 1848
• Com as simulações processadas para os quesitos foram obtidas todas as respostas
possíveis para os critérios. Considerando-se que cada um possui 4 patamares de nota,
conforme explicitado no Capítulo 6 (0 < Nota ≤ 3 | 3 < Nota ≤ 5 | 5 < Nota ≤ 7 | 7 < Nota
≤ 10), obteve-se portanto: 21 critérios x 4 patamares de nota = 84 respostas para a análise
dos Pré-Requisitos e 27 critérios x 4 patamares de nota = 108 respostas para a Auditoria,
totalizando 192 respostas, ou seja, todas as possibilidades de saída;
• Assim como no caso anterior, obtiveram-se para as etapas todas as saídas possíveis após a
ponderação dos quesitos. As conclusões fornecidas pelo DALF-MCC para as etapas estão,
também, atreladas a 4 patamares de nota, conforme explicitado no Capítulo 6 (0 < Nota ≤
3 | 3 < Nota ≤ 5 | 5 < Nota ≤ 7 | 7 < Nota ≤ 10), obtendo-se portanto: 9 etapas x 4
patamares de nota = 36 respostas para a análise dos Pré-Requisitos e 9 etapas x 4
patamares de nota = 36 respostas para a Auditoria, totalizando 72 respostas, ou seja, todas
as possibilidades de saída.
Em relação às ferramentas complementares, todas passaram por testes de caso antes do
processo de validação, sendo que a principal preocupação foi a funcionalidade dos atributos
presentes na interface com o usuário e sua correta execução a partir do DALF-MCC.
8.3 VALIDAÇÃO
Conforme descrito no Capítulo 4, o objetivo da validação de um protótipo de SBC, no
sentido mais amplo, é determinar se o sistema realiza aquilo para o qual ele foi desenvolvido. No
modelo incremental, a validação é a etapa que fecha um ciclo de desenvolvimento do protótipo.
No caso do DALF-MCC, o processo de validação transcorreu de 3 maneiras distintas, a saber:
• Validação parcial do DALF-MCC e suas ferramentas complementares em seminários,
congressos e palestras de apresentação deste trabalho de tese;
• Aplicação do DALF-MCC em campo em uma empresa da cidade industrial de Curitiba e
sua comparação com os resultados obtidos pela metodologia proposta por Fuentes (2006);
188
• Validação por especialistas em MCC, os quais participaram do processo de aquisição do
conhecimento do DALF-MCC.
Nos próximos parágrafos, cada um destes mecanismos de validação é explicitado para
maior clareza dos procedimentos adotados e dos resultados obtidos.
Validação Parcial em Seminários, Congressos e Palestras
Esta etapa do processo se estendeu ao longo de todo o ciclo de desenvolvimento do
DALF-MCC. A intenção foi aproveitar os eventos com profissionais da área, alunos dos cursos de
graduação da Universidade Tecnológica Federal do Paraná (UTFPR) e de pós-graduação da
Universidade Federal de Santa Catarina (UFSC), para obter resultados exploratórios preliminares
e, assim, realimentar o processo de desenvolvimento do DALF-MCC. O objetivo focalizou a
validação da estrutura e da interface com o usuário.
As primeiras interações com usuários do DALF-MCC, objetivando sua validação,
ocorreram em Seminários, Aulas e Palestras na UTFPR. Neste caso, os envolvidos no processo de
validação foram alunos do último ano dos cursos de Engenharia Industrial Elétrica, ênfase
Eletrotécnica, e Tecnologia em Gestão Comercial do Departamento Acadêmico de Eletrotécnica
(DAELT). Em ambos os cursos os alunos cursaram, no mesmo semestre ou no anterior, a
disciplina de Gestão da Manutenção. Para inquirir a opinião dos participantes durante esta fase foi
utilizado o questionário apresentado no Apêndice C deste trabalho, particularmente as questões
relativas à Análise da Interface e parte das questões relativas aos Aspectos Gerais (questões 1 a 4).
A Tabela 8.3 sintetiza os resultados deste procedimento.
Tabela 8.3 – Resultado do Questionário de Validação (Alunos - UTFPR).
Questões Respondidas (52 participantes)
Interface (%) Aspectos Gerais (%)
Resposta
Q1 Q2 Q3 Q4 Q5 Q6 Q1 Q2 Q3 Q4
Sim 100 100 59,6 80,8 76,9 100 100 67,3 100 *
Não 0 0 28,9 0 0 0 0 0 0 *
Parcialmente 0 0 11,5 19,2 23,1 0 0 32,7 0 *
* Resposta discursiva facultativa.
Os resultados desta etapa do processo de validação (Tabela 8.3) apontam para a dificuldade
dos alunos com relação a utilização da tela de Parametrização
Fuzzy
do DALF-MCC (Q3 da
Análise da Interface). Esta dificuldade foi atribuída a inexperiência para inferir sobre a melhor
parametrização dos termos primários e, a tentativa equivocada de configurar um determinado termo
de forma não permitida pelo DALF-MCC. As respostas a Questão 4 dos Aspectos Gerais revelou a
necessidade de treinamento na ferramenta e em MCC como sugestão de consenso.
189
Os comentários e opiniões dos participantes desta fase do processo de validação,
permitiram, além da correção de diversos
bugs
, a identificação de melhorias estruturais e estéticas
na interface com o usuário. Foi possível, também, identificar faltas e inconsistências até então
imperceptíveis no arquivo de ajuda que, na sua versão atual está mais consistente e adequado,
inclusive para usuários não especialistas em MCC ou lógica
Fuzzy
. Vale ressaltar que, para a
utilização do DALF-MCC não é necessário conhecer os procedimentos para implantação da
MCC, nem tão pouco a teoria sobre a lógica
Fuzzy
. No entanto, o DALF-MCC possui em seu
arquivo de ajuda os subsídios para aprofundamento nestes dois domínios, se o usuário desejar.
Outra oportunidade de validação do DALF-MCC ocorreu durante o 22º Congresso
Brasileiro de Manutenção promovido pela Associação Brasileira de Manutenção (ABRAMAN)
em Florianópolis, entre 17 e 21/09/2007. Nesta oportunidade, alguns especialistas interessados no
tema deste trabalho foram convidados a utilizar e opinar sobre DALF-MCC e suas ferramentas
complementares até então desenvolvidas. Foram avaliados, nesta ocasião, os seguintes itens:
linguagem utilizada na interface; facilidade de aplicação e utilização do DALF-MCC e suas
ferramentas complementares; suficiência e consistência das informações presentes na interface
com o usuário e no
help
; habilidade e capacitação dos mantenedores, e demais envolvidos no
processo de implantação da MCC, para responder aos questionamentos apresentados e a
abrangência dos questionamentos com relação à análise dos pré-requisitos para implantação da
MCC, lembrando que, nesta oportunidade, ainda não havia a intenção de incluir a Auditoria da
MCC no DALF-MCC. Esta necessidade foi vislumbrada justamente neste evento, durante as
entrevistas com os participantes do processo. Para inquirir a opinião dos participantes durante esta
fase foi utilizado, na íntegra, o questionário apresentado no Apêndice C deste trabalho. A Tabela
8.4 sintetiza os resultados deste procedimento.
Tabela 8.4 – Resultado do Questionário de Validação (Especialistas - Congressos).
Questões Respondidas (15 participantes)
Interface (%) Processo de Inferência (%) Aspectos Gerais (%)
Resposta
Q1 Q2 Q3 Q4 Q5 Q6 Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q1 Q2 Q3 Q4 Q5
Sim 100 86,7 66,7 80 80 100 100 93,3 93,3 100 80 100 100 100 80 100 * 86,8
Não 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 * 0
Parcialmente 0 13,3 33,3 20 20 0 0 6,7 6,7 0 20 0 0 0 20 0 * 13,3
* Resposta discursiva facultativa.
Os resultados desta etapa do processo de validação (Tabela 8.4) apontam para um
percentual maior de dificuldade com relação a utilização da tela de Parametrização
Fuzzy
do
DALF-MCC (Q3 da Análise da Interface), comparado com o caso da validação com alunos da
UTFPR. A maior dificuldade neste caso foi a tentativa de impor uma determinada função de
pertinência aos termos primários de forma não permitida pelo DALF-MCC. As respostas a
190
Questão 4 dos Aspectos Gerais revelou a necessidade de treinamento no DALF-MCC e suas
ferramentas complementares.
Os comentários e opiniões dos participantes desta fase do processo de validação,
permitiram, identificar: erros conceituais, tanto na interface quanto no arquivo de ajuda; a
necessidade de acréscimo de critérios, até então ignorados, bem como melhorias na formulação
dos quesitos. Também foi constatada a necessidade de se alterar a ordem de apresentação do
relatório, aspecto este também observado posteriormente pelo orientador deste trabalho. Assim, o
resultado final da avaliação da etapa foi inserido no início do relatório, antes dos resultados
parciais do processo de inferência que culminou na avaliação da respectiva etapa, o que facilitou o
acesso à informação almejada, evitando que o usuário tenha que percorrer todo o relatório para
visualizá-la. Na versão atual, isso somente é necessário se o usuário desejar obter detalhes do
processo da avaliação da etapa, o que inclui os resultados parciais da avaliação dos critérios e da
ponderação dos quesitos relacionados.
Aplicação em Campo
A aplicação do DALF-MCC e suas ferramentas complementares em campo foi
viabilizada, primeiramente, por intermédio do trabalho de conclusão de curso de GOBER
et al
(2008) orientado pelo autor, no DAELT da UTFPR. Neste trabalho, a seguinte estratégia foi
adotada:
1) Em um grupo selecionado de empresas de Curitiba e região metropolitana, foi aplicada a
Sistemática para Seleção da Concepção de Manutenção (SSCM) proposta por Fuentes
(2006). Participaram deste processo, operadores e mantenedores das empresas
selecionadas;
2) Em um dos casos, a SSCM revelou a aptidão da empresa em adotar a MCC como
metodologia para gestão da manutenção. Mais especificamente, a aplicação da SSCM
revelou que: 74% dos requisitos exigidos pela MCC poderiam ser atendidos pela empresa
com facilidade e, destes, 50% seriam de atendimento imediato, isto é, o que a empresa já
utilizava para gestão de sua manutenção já atenderia às necessidades da MCC;
3) Nesta empresa foi, então, aplicado o DALF-MCC (Etapa 0) para comparar seus
resultados com àqueles sugeridos pela SSCM proposta por Fuentes (2006).
Na aplicação da SSCM, a avaliação mostrou, como pontos positivos, o envolvimento das
pessoas nas mudanças e o espírito de equipe dos mantenedores. No DALF-MCC, os quesitos
relacionados com estes itens (Critério 2, 3 e 4 da Etapa 0) obtiveram uma avaliação “Alta”.
Um ponto negativo revelado pela SSCM foi com relação à falta de atributos da empresa
relacionados à gestão de projetos. Tais atributos também foram evidenciados pelo DALF-MCC
191
em quesitos específicos (Critério 5 da Etapa 0), resultando na conclusão de que este fato
representa um “risco” para o sucesso do programa de MCC.
Com relação ao nível de cultura/maturidade para mudanças, a empresa recebeu da SSCM
um conceito “bom e suficiente”. Na aplicação do DALF-MCC, os quesitos relacionados à cultura
e maturidade da manutenção (Critério 4 da Etapa 0) obtiveram, na sua avaliação, um conceito
“satisfatório” para a implantação da MCC.
As ferramentas complementares para implementação da MCC propostas pelo DALF-
MCC, as quais não possuem equivalentes na SSCM, receberam do gerente de manutenção da
empresa um parecer positivo. Neste caso, a ferramenta utilizada foi o OpenFMECA, uma vez que
o gerente já tinha conhecimento da técnica FMECA e, deliberadamente, utilizou o referido
software para comprovar suas funcionalidades.
Assim, a aplicação do DALF-MMC revelou, a partir da ponderação dos quesitos pelos
mantenedores, que a empresa/sistema dispõe da maioria dos requisitos exigidos para iniciar a
implementação da MCC. Tal resultado ratificou, portanto, a conclusão da SSCM proposta por
Fuentes (2006), servindo como critério para a validação parcial do DALF-MCC.
Todos os usuários do DALF-MCC que participaram e/ou contribuíram com o trabalho de
conclusão de curso, relatado neste item, também responderam ao questionário de validação do
DALF-MCC apresentado no Apêndice C. A Tabela 8.5 sintetiza os resultados deste processo.
Tabela 8.5 – Resultado do Questionário de Validação (Aplicação em Campo).
Questões Respondidas (12 participantes)
Interface (%) Processo de Inferência (%) Aspectos Gerais (%)
Resposta
Q1 Q2 Q3 Q4 Q5 Q6 Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q1 Q2 Q3 Q4 Q5
Sim 100 83,3 100 91,7 100 83,3 100 91,7 91,7 91,7 83,3 100 100 100 100 100 * 91,7
Não 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 * 0
Parcialmente 0 16,7 0 8,3 0 16,7 0 8,3 8,3 8,3 16,7 0 0 0 0 0 * 8,3
* Resposta discursiva facultativa.
A equipe que desenvolveu a aplicação em campo recebeu um treinamento prévio sobre o
DALF-MCC, treinamento este repassados pela equipe, de maneira informal, para os membros da
empresa que participaram da aplicação em campo. Isso se refletiu em um aumento do percentual
de avaliações positivas com relação a utilização e entendimento da interface com o usuário. Das
respostas obtidas e seus respectivos comentários foi possível sintetizar as seguintes observações:
• Nem todos os participantes conheciam a metodologia de gestão da manutenção proposta
pela MCC. Neste aspecto, os comentários revelaram a importância do arquivo de ajuda
propiciado pelo DALF-MCC, acessado a partir dos diversos
hiperlinks
disponíveis na
interface com o usuário;
• Foram constatados alguns
bugs
na interface com o usuário, por exemplo: a tecla Tab
estava selecionando os objetos da tela de maneira não seqüencial; na versão utilizada
192
havia permissão para se utilizar a vírgula para a separação de casa decimais, no caso da
ponderação dos quesitos com uma Nota, gerando um erro no processo de inferência do
FuzzyCLIPS; alguns
hiperlinks
não estavam funcionais ou, ao abrirem o arquivo de ajuda
(.html), posicionavam o cursor em um ponto diferente do solicitado pelo usuário. Estes e
outros
bugs,
constatados ao longo da aplicação em campo, foram corrigidos na versão
atual do DALF-MCC;
• Foi solicitado que, na tela de parametrização
Fuzzy
, fosse possível anular 2 termos. A
justificativa foi de que na ponderação dos quesitos se trabalharia com 3 termos (Baixa,
Boa e Alta) referentes à aderência da empresa/sistema aos requisitos da MCC. Isso
reduziria as dúvidas, durante a ponderação, agilizando o processo e contribuindo para a
convergência dos resultados, quando o número de participantes é grande. Tal consideração
foi julgada procedente pelo autor e sua implementação está sendo proposta como trabalho
futuro. A proposta é que o usuário possa escolher o número e o nome dos termos
primários que deseja utilizar (de 2 a 5). O campo (
combo box
) com a listagem dos termos
primários, na ponderação dos quesitos, seria automaticamente atualizado de acordo com as
escolhas do usuário. Os campos utilizados para ponderação dos quesitos (Nota e Conceito)
poderiam, também, gravar os valores digitados no momento da perda do foco do referido
campo. Na versão atual, estes valores são gravados somente após a avaliação do critério.
Caso o usuário mude de tela, sem avaliar o critério, os valores são perdidos.
Com relação, especificamente, às ferramentas complementares OpenFMECA e FMECA-
Delphi, estas foram utilizadas em campo no âmbito do projeto MitiSF6, desenvolvido no Núcleo
de Desenvolvimento Integrado de Produtos (NeDIP) do Departamento de Engenharia Mecânica
(EMC) da UFSC. Este projeto, patrocinado pela ELETROSUL, buscou estudar e sistematizar os
processos de manutenção dos disjuntores que utilizam o
Hexafluoreto de Enxofre (SF
6
), como
elemento dielétrico e de extinção do arco elétrico, com o objetivo de estabelecer um modelo de
referência para utilização e manuseio do SF
6
. Com a aplicação no MitiSF6 foi possível constatar,
no caso do OpenFMECA, sua viabilidade e praticidade aliadas à sua facilidade de utilização
devido a sua interface intuitiva, aspectos estes ratificados pelos diversos usuários que participaram
do projeto e utilizaram o OpenFMECA. No caso do FMECA-Delphi, foram constatados alguns
inconvenientes que dificultam sua operacionalidade frente a um volume de dados muito grande e
onde a divergência de opiniões é muito acentuada. Neste caso, foi constatado nos testes de campo
que: a grande quantidade de valores fora da faixa central resultou em um volume expressivo de
informação na segunda iteração (acredita-se que este fato ocorreu devido ao conhecimento
superficial que alguns participantes tinham do sistema avaliado); foi constatado que as
informações presentes na interface com o usuário não foram suficientes para elucidar todas as
dúvidas, ou os participantes não leram todas as informações (neste caso foi verificada a
necessidade de um treinamento prévio dos participantes). Tais fatores, da forma como foi
concebido o processamento da informação pelo moderador, tornam o processo lento, de difícil
193
convergência e muito dependente do tratamento manual dos dados. Esses inconvenientes foram
também evidenciados por Campos (2004) e, sua melhoria, constitui objeto das propostas de
trabalho futuro desta tese.
Validação por Especialistas em MCC
Diversos especialistas participaram direta ou indiretamente do processo de desenvolvimento
e validação deste trabalho (membros da ABRAMAN, professores da UTFPR e da UFSC e
colaboradores das empresas participantes das aplicações em campo). Entretanto, a etapa final do
processo de validação do DALF-MCC, em sua versão atual coube, em grande parte, ao professor e
especialista em MCC Iony Patriota de Siqueira
1
. O professor Iony, além de contribuir para a
consecução desta tese com sua experiência e conhecimento de 30 anos em manutenção foi, também,
o principal apoio externo a este trabalho, participando ativamente do processo de aquisição de
conhecimento e validação do DALF-MCC. Os especialistas que participaram do processo de
validação tiveram a sua disposição o texto da tese (Capítulos 1, 5, 6 e 7, em versões anteriores a
atual) e um manual para instalação e execução do DALF-MCC (Apêndice D). As considerações e
contribuições dos especialistas foram consolidadas a partir do questionário para validação
apresentado no Apêndice C, onde foram avaliados: a interface com o usuário, a coerência e
consistência da base de conhecimento do DALF-MCC, a partir dos relatórios resultantes do
processo de inferência, bem como a completude dos questionamentos formulados ao usuário frete às
exigências de um programa de MCC. A Tabela 8.6 sintetiza os resultados deste procedimento, e os
pontos relevantes deste processo são relatados nos próximos parágrafos.
Tabela 8.6 – Resultado do Questionário de Validação (Especialistas em MCC).
Questões Respondidas (5 participantes)
Interface (%) Processo de Inferência (%) Aspectos Gerais (%)
Resposta
Q1 Q2 Q3 Q4 Q5 Q6 Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q1 Q2 Q3 Q4 Q5
Sim 100 100 80 100 100 100 100 80 80 100 80 100 100 100 80 100 * 100
Não 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 * 0
Parcialmente 0 0 20 0 0 0 0 20 20 0 20 0 0 0 20 0 * 0
* Resposta discursiva facultativa.
1
Iony Patriota de Siqueira (SIQUEIRA, 2005) é mestre em Engenharia de Produção pela Universidade Federal
de Pernambuco (UFPE), onde defendeu sua Dissertação sobre Manutenção Centrada na Confiabilidade. É pós-
graduado em Informática pela Universidade Católica de Pernambuco, com especialização em Sistemas de
Informações, e bacharelado em Engenharia Elétrica pela UFPE, com curso de extensão em Manutenção
Centrada na Confiabilidade, pelo EPRI (
Electric Power Research Institute
)
Solutions
. É consultor, pesquisador e
professor da UNIBRA TEC e UFPE / GPSID (Grupo de Pesquisa em Sistemas de Informação e Decisão do
CNPq), onde ministra as cadeiras de Integração de Dados e Processos, Modelagem de Negócios e Engenharia de
Requisitos, além de Manutenção Centrada na Confiabilidade, no Curso Superior em Tecnologia de Redes e
Ambientes Operacionais, e no Curso de Pós-Graduação em Engenharia de Software e Gestão da Manutenção.
No ano de 2003, recebeu o prêmio máximo (
hors concours
) do Seminário Internacional de
Mantenimiento Y
Servicios Asociados En Sistemas Eléctricos
– SIMSE 2003, e o primeiro lugar (menção honrosa) do Grupo de
Operações do Seminário Nacional de Geração e Transmissão de Energia, promovido pelo
International Council
on Electric Power Systems
– CIGRÉ. (http://buscatextual.cnpq.br/buscatextual/visualizacv.jsp?id=K4796921U8)
194
Alguns especialistas divergiram quanto a necessidade da Etapa 0 do procedimento de
referência, alegando que a MCC seria adequada para todas as empresas/sistemas em quaisquer
circunstâncias. Neste ponto, o autor concorda que o nível de abrangência e profundidade das
análises promovidas pela MCC pode se adaptar ao contexto da empresa/sistema, discordando,
entretanto, que a equipe de implementação da MCC não deva se preocupar com as restrições
técnicas e gerenciais impostas pelas especificidades da aplicação. Muitos programas de MCC, e
casos de aplicações isoladas de suas ferramentas, citados na literatura (ANTONIETTI, 2002;
BACKLUND, 2003; BLANCO, 2007; JOHNSTON, 2002; RAJOTTE e JOLICOEUR, 2001;
RIBEIRO e ALVES, 2005; VIZZONI
et al
, 1999; WALTRICH e TONDELLO, 2007),
fracassaram ou experimentaram dificuldades em sua implementação e execução por
desconsiderarem a necessidade da aderência da empresa/sistema aos requisitos da MCC. Em tais
circunstâncias, mudanças na estratégia inicial de implantação ou da própria metodologia MCC
foram necessárias para minimizar os problemas experimentados, ratificando a necessidade de
existência da Etapa 0, tanto no procedimento de referência quanto no DALF-MCC.
Algumas considerações, relativas à parametrização
Fuzzy
, indicaram que a mesma deve
ser personalizada para o domínio da aplicação. Tal consideração, de certo modo, já tinha sido
contemplada ao longo deste trabalho quando, no Capítulo 5, foi ressaltado que o processo de
parametrização deve ser conduzido por um especialista em MCC e no domínio da aplicação. É
este conhecimento/experiência que deve servir de base para a definição das funções de
pertinência, as quais definirão os termos primários que compõem o conjunto
Fuzzy
de referência.
É proposta desta tese, para trabalhos futuros, incorporar um método que utilize a técnica Delphi,
tal qual o FMECA-Delphi, para elicitar os parâmetros do conjunto
Fuzzy
de referência. Dessa
maneira, seria possível parametrizar os termos primários, de forma que os mesmos convergissem
para um valor de consenso entre os especialistas, uma vez que tal parametrização é muito
dependente das especificidades do domínio da aplicação. Outra hipótese seria incorporar ao
DALF-MCC um banco de dados com valores padronizados e de consenso, para os termos
primário, válidos para domínios de aplicação específicos.
Foi consenso entre os especialistas, como virtude do DALF-MCC, o embasamento
normativo tanto para a fase de análise de pré-requisitos como para a auditoria. Esta característica
foi planejada durante a fase de formulação do procedimento de referência, o qual, além da
bibliográfia clássica da MCC, baseou-se também nas principais normas e guias (NOWLAN e
HEAP, 1978; SMITH, 1993; SMITH e HINCHCLIFFE, 2004; MOUBRAY, 2001; NASA, 2000;
IEC 60300-3-11, 1999; SAE JA 1011, 1999; SAE JA 1012, 2002; ABS, 2004). Vale ressaltar que
o DALF-MCC não segue uma única norma, guia ou bibliografia, sendo aderente a todas aquelas
referenciadas como base para concepção do procedimento de referência (Capítulo 5).
Outra característica positiva do DALF-MCC, relatada pelos especialistas, foi a inclusão
das questões relativas à auditoria da MCC. A falta de auditoria no procedimento de implantação
da MCC é um dos fatores que resultam no seu insucesso e, mesmo apesar disso, é um aspecto
195
pouco tratado na literatura e nos artigos científicos. Conforme relatado anteriormente, a idéia de
tratar a auditoria da MCC surgiu durante a validação parcial, ocorrida durante o 22º Congresso
Brasileiro de Manutenção promovido pela ABRAMAN. A decisão de incluir a auditoria no
processo de inferência do DALF-MCC revelou-se um fator importante para sua credibilidade e
completude, ratificado na validação pelos especialistas.
A decisão de se utilizar a lógica
Fuzzy
como mecanismo para tratamento das incertezas do
processo decisório foi referendada de forma unânime pelos especialistas. Segundo os participantes
do processo de validação, a falta de dados estatísticos e o alto grau de incerteza na ponderação dos
quesitos inviabilizariam a utilização de métodos probabilísticos clássicos ou frequentistas. Nesta
mesma linha de raciocínio, foi amparado o NPR-Fuzzy, uma das ferramentas complementares
incorporadas ao DALF-MCC e, neste caso, foi apoiada a sugestão do autor para incorporá-lo
como complemento (
plugin
) do OpenFMECA em trabalhos futuros.
Nos ciclos iniciais de validação do DALF-MCC, com os especialistas, foi vislumbrado os
benefícios que um SBC-
Fuzzy
poderia trazer para a definição da significância da função, no
correspondente diagrama de decisão da MCC. Esta sugestão resultou no desenvolvimento do
DALF-Diagramas, uma das ferramentas complementares do DALF-MCC que, além de auxiliar a
seleção e a caracterização das funções significantes, também pode ser utilizado para auxiliar a
seleção das tarefas de manutenção aplicáveis e efetivas. Esta ferramenta se mostrou muito útil
para a execução das etapas 4 e 5 do procedimento de referência, estruturando o processo de
decisão e tratando as incertezas inerentes, características ratificadas pelos especialistas.
8.4 CONSIDERAÇÕES E SÍNTESE DO CAPÍTULO
O processo de verificação e validação do DALF-MCC, abordado neste capítulo, foi de
substancial contribuição para o aprimoramento do protótipo e ratificação de suas
potencialidades. Novas perspectivas de estudo foram vislumbradas e as intervenções
implementadas aumentaram a robustez, as funcionalidades e a credibilidade do DALF-MCC e
suas ferramentas complementares.
Como resultado do processo de validação e testes de campo foi possível inferir que:
• O DALF-MCC contribui positivamente para a tomada de decisão durante os
procedimentos de implementação e auditoria da MCC. Tal constatação foi possível a partir
de sua utilização em campo e da opinião dos especialistas;
• Foi consenso entre os especialistas de que o DALF-MCC e suas ferramentas
complementares representam algo novo e que pode de fato auxiliar o processo de
implantação da MCC;
• A utilização da lógica
Fuzzy
para tratamento das incertezas e incompletudes do
conhecimento, inerente a implementação das etapas da MCC, se mostrou eficiente. Sendo
196
a ponderação, com base em dados qualitativos, a partir da utilização de variáveis
lingüísticas, adequada aos objetivos deste trabalho. Além disso, salienta-se a possibilidade
da ponderação com valores
crisp
, o que aumenta a funcionalidade da interface com o
usuário;
• A abordagem utilizada, fundamentada em normas e no conhecimento heurístico dos
especialistas envolvidos, associada aos cuidados e a atenção dispensada ao procedimento
de verificação e validação, contribuíram para a completude e robustez da base de
conhecimento e credibilidade dos resultados alcançados;
• O DALF-MCC e suas ferramentas complementares são de fácil utilização. Contribuíram
para tanto, a interface intuitiva e a abrangência do arquivo de ajuda.
197
CAPÍTULO 9
CONSIDERAÇÕES FINAIS
9.1 INTRODUÇÃO
Os aspectos norteadores deste trabalho originaram-se de constatações vislumbradas em
artigos técnico-científicos, bibliografias especializadas e em observações de campo. Tais
constatações ensejaram, e podem ser resumidas, através dos seguintes questionamentos:
• Porque alguns programas de Manutenção Centrada na Confiabilidade (MCC) fracassam
ou experimentam dificuldades na busca dos resultados inicialmente almejados
(ANTONIETTI, 2002; ALKAIM, 2003; BACKLUND, 2003; JOHNSTON, 2002;
VIZZONI
et al
, 1999)?
• Tais fracassos não estariam relacionados a implantações despretensiosas, sem o devido
preparo, habilidade e competência da equipe de implantação associados a um insuficiente
rigor metodológico e normativo?
• As questões mercadológicas que relacionam a MCC de maneira exagerada e sem critérios
como solução para a gestão de ativos, não estariam influenciando tal resultado?
• Como seria possível antever a aderência de uma empresa/sistema às necessidades de um
programa de MCC para, assim, evitar os dissabores de uma adesão despreparada a tal
metodologia de gestão da manutenção?
A resposta a tais questionamentos e anseios culminou com a proposição desta tese. Já as
pesquisas referenciais, as proposições e os desenvolvimentos relatados ao longo deste trabalho,
tornaram possível a interposição dos recursos metodológicos necessários para suplantar as
preocupações supracitadas. As considerações e recomendações advindas deste processo são
mostradas nos próximos itens.
9.2 SOBRE OS OBJETIVOS E QUESTÕES DE PESQUISA PROPOSTOS
Os resultados obtidos, dentro das especificidades definidas no escopo deste trabalho,
abordados no Capítulo 1, permitiram aferir o sucesso no cumprimento do seu objetivo geral. O
Sistema Baseado em Conhecimento
Fuzzy
(SBC-
Fuzzy
) proposto, desenvolvido e validado,
conforme os capítulos precedentes, ratifica esta assertiva. Além disso, ao longo desse processo,
obtiveram êxito os seguintes aspectos, relacionados aos objetivos específicos inerentes ao
contexto deste trabalho:
• A investigação das principais metodologias para implantação da MCC (NOWLAN e
HEAP, 1978; SMITH, 1993; SMITH e HINCHCLIFFE, 2004; MOUBRAY, 2001;
198
NASA, 2000; IEC 60300-3-11, 1999; SAE JA 1011, 1999; SAE JA 1012, 2002; ABS,
2004), permitiu concluir sobre seus aspectos divergentes, fato este que resultou na
concepção de um procedimento de referência para implantação da MCC. Com isso, os
conceitos, estratégias, ferramentas e necessidades da MCC foram evidenciados e
estruturados seguindo uma abordagem adaptada da IDEF0 (
Integration DEFinition
–
Definição Integrada), conforme mostrado no Capítulo 5;
• O SBC-
Fuzzy
desenvolvido (Diagnóstico Auxiliado por Lógica
Fuzzy
para a Manutenção
Centrada na Confiabilidade – DALF-MCC) mostrou-se uma estratégia eficiente e
inovadora na opinião dos especialistas que o validaram, para identificação dos atributos da
empresa/sistema relacionados com as necessidades e pré-requisitos da MCC;
• Conforme evidenciado nos procedimentos de validação (Capítulo 8), a lógica
Fuzzy
se
mostrou adequada para equacionamento das incertezas por imprecisão, inerentes a análise
qualitativa desenvolvida para confrontar os atributos da empresa/sistema com as
necessidades da MCC;
• Os critérios e seus respectivos quesitos, planejados como mecanismos de explicitação do
conhecimento tácito, tiveram sua completude e adequação normativa ratificados pelos
especialistas (Capítulo 8). Isso se reverteu em credibilidade para o processo de inferência
do DALF-MCC, na avaliação dos pré-requisitos e auditoria da MCC;
• O processo de inferência
Fuzzy
, que contemplou as variáveis heurísticas de análise,
resultou em diagnósticos e conclusões satisfatórios para apoiar a tomada de decisão
durante a implementação das etapas da MCC e sua auditoria;
• Os indicadores de validação do DALF-MCC, relacionados à interface com o usuário,
funcionalidades requeridas e exatidão da base de conhecimento (estruturados no
questionário do Apêndice C), bem como, a metodologia a ele incorporada, foram aceitos
pelos especialistas que participaram do processo de validação e dos testes de campo;
• A aplicação em campo do DALF-MCC, mostrada no Capítulo 8, foi importante para
ratificar os resultados do processo de validação com os especialistas e descobrir
bugs
na
interface com o usuário;
• Os softwares complementares, tratadas no Capítulo 7, apesar de não fazerem parte da
proposta inicial deste trabalho, foram consideradas pelos especialistas como ferramentas
aplicáveis e efetivas para auxiliar a implementação das etapas da MCC.
Do contexto e dos resultados supracitados emerge a resposta para a questão principal,
norteadora deste trabalho, elaborada no Capítulo 1, tal resposta é: O DALF-MCC, com sua base
de conhecimento, seus mecanismos para tratamento de incertezas fundamentados na lógica
Fuzzy
e suas ferramentas complementares é um instrumento adequado para conduzir e
orientar a implantação e a auditoria de um programa de MCC, tratando as incertezas por
199
imprecisão ou de natureza léxica do processo decisório. Os procedimentos de verificação, e
validação explicitados no Capítulo 7, ratificam tal asserção.
9.3 SOBRE AS CONTRIBUIÇÕES TÉCNICO-CIENTÍFICAS DA PESQUISA
A parcela de contribuição científica formal desta tese está registrada, conforme
apresentado no Apêndice E, sob a forma de artigos apresentados em eventos nacionais,
internacionais e revistas, além de um trabalho de conclusão de curso orientado pelo autor. Porém
sua maior contribuição científica reside no fato de esta ser uma pesquisa aplicada, concebida
dentro dos rigores de uma pesquisa científico-tecnológica, objetivando a solução de um problema
e uma peculiaridade até então não abordados no referencial bibliográfico pesquisado.
O problema tratado foi a implantação da MCC, de forma consistente com os objetivos da
empresa e aderente às suas limitações e especificidades. A sua peculiaridade caracteriza-se pela
abordagem, não da implementação das etapas, mas sim pela avaliação de seus pré-requisitos e sua
auditoria. A solução proposta é capaz, entretanto, de em etapas expressivas do procedimento de
implantação (Etapas 3, 4 e 5) auxiliar a solução de problemas específicos evidenciados ao longo
do processo de aquisição do conhecimento do DALF-MCC, relatados no Capítulo 7. Cabe
salientar que não existia, nos objetivos específicos iniciais, a intenção de se desenvolver
ferramentas para apoio a implementação das etapas da MCC. Tal mescla de oportunidade e
desafio foi vislumbrada ao longo do processo de desenvolvimento da tese, atendendo a uma
reivindicação dos especialistas, os quais, de modo cooperativo, contribuíram com seu
conhecimento para a implementação de tais ferramentas.
Ficou evidenciado, ao longo deste trabalho e, também, durante o processo de sua
validação, que a proposta desta tese não se restringe a um domínio e/ou aplicação específica de
MCC, mas sim, trata-se de uma metodologia genérica para auxiliar a implantação da MCC em
quaisquer aplicações. Tal constatação ficou evidenciada não somente pelas considerações dos
especialistas, mas também pelo desempenho do DALF-MCC nas aplicações em campo, conforme
mostrado no Capítulo 8.
As contribuições almejadas de maneira prospectiva no Capítulo1 foram ratificadas e
substanciadas no transcorrer dos desenvolvimentos que resultaram na consecução deste
trabalho. Nesse sentido, criou-se um mecanismo para diagnosticar e resguardar os programas
de MCC dos fatores responsáveis por seus insucessos e suas dificuldades executivas, focado:
na ratificação da aderência das características da empresa/sistema aos requisitos de um
programa de MCC; na interposição de
barreiras para resguardar o programa de MCC dos efeitos
dos fatores técnicos e gerenciais que o afetam negativamente; no diagnóstico e orientação do
processo decisório com o auxílio de um SBC-
Fuzzy
, de forma a minimizar os riscos de insucesso;
na proposição de indicadores que possibilitem realimentar o processo de implantação e promover
as correções necessárias.
200
O tratamento de dados qualitativos e com forte viés heurístico, aludidos no Capítulo 1, foi
contemplado pelo DALF-MCC. Além disso, foi possível viabilizar um repositório do
conhecimento heurístico relativo à implantação da MCC. A interação desse conhecimento,
manifestado nas inferências do DALF-MCC, resulta em um diagnóstico representativo das
habilidades e competências da empresa para tratar as peculiaridades do processo decisório, frente
aos fatores que são críticos para o sucesso de um programa de MCC.
9.4 SUGESTÕES PARA TRABALHOS FUTUROS
Utilizando-se de um processo de inferência
Fuzzy
, tal qual o desenvolvido neste trabalho, é
possível criar ferramentas para implementação de todas as etapas do procedimento de referência,
assim como foi proposto para as etapas 3, 4 e 5. Tais ferramentas iriam auxiliar a equipe de
implementação, tanto nas questões documentais do processo quanto nas questões relativas ao apoio
à tomada de decisão, frente a incertezas. As seguintes funcionalidades poderiam ser incorporadas:
• Para a Etapa 2 (Seleção do Sistema e Coleta de Informações), um SBC-
Fuzzy
, a partir da
ponderação de variáveis qualitativas, poderia definir qual o equipamento/sistema onde a
implantação da MCC seria mais viável para a empresa respeitando suas habilidades e
competências. Tal sistema poderia, inclusive, proporcionar uma análise econômico-
financeira e de dimensionamento de recursos, objetivando maximizar os ganhos para a
empresa;
• Para Etapa 6 (Definição dos Intervalos Iniciais e Agrupamento das Tarefas de Manutenção),
um SBC-
Fuzzy
ou um SBC híbrido (
Fuzzy
/ Probabilístico) poderia inferir sobre o intervalo
ótimo, para realização das tarefas de manutenção e, também, sobre seu agrupamento ideal.
Tal processo de inferência se daria a partir da ponderação com base em variáveis
lingüísticas, utilizando-se da experiência de operadores e mantenedores, ou dados
estatísticos de históricos de falha e/ou bancos de dados genéricos;
• Para a Etapa 8 (Acompanhamento e Realimentação), poderiam ser disponibilizados
mecanismos para sistematizar a re-análise de cada modo de falha não incluído no
programa inicial da MCC, como rotina da manutenção.
Propõem-se também, para trabalhos futuros, os seguintes incrementos de funcionalidade
ao DALF-MCC e suas ferramentas complementares:
• Incorporação de uma ferramenta para geração automática de um plano de implantação
baseado nas habilidades e competência da empresa, elicitadas a partir da ponderação dos
quesitos, para os casos onde a MCC se mostrou inviável para implantação imediata. Tal
ferramenta também poderia ser aplicada para os casos em que a MCC se mostrou viável,
porém neste caso, o objetivo seria compor um plano de implantação da MCC, constando no
mínimo de: estratégia para alocação de recursos, planejamento orçamentário, objetivos, metas,
201
cronograma, agregando questões objetivas dirigidas ao decisor da empresa e/ou equipe de
implantação;
• Incluir as seguintes funcionalidades/melhorias ao processo de ponderação dos quesitos: na tela
de Parametrização
Fuzzy
, permitir ao usuário a possibilidade de alterar a quantidade e o nome
dos termos primários que deseja utilizar, o que poderia reduzir as dúvidas, durante a
ponderação, agilizando o processo e contribuindo para a convergência dos resultados quando o
número de participantes é grande. Neste caso, o campo (
combo box
) com a listagem dos
termos primários na ponderação dos quesitos, deve ser automaticamente atualizado de acordo
com as escolhas do usuário; os campos utilizados para ponderação dos quesitos (Nota e
Conceito) poderiam, também, gravar os valores digitados no momento da perda do foco
(função
onKillFocus
do
Visual Basic
). Na versão atual estes valores são gravados somente
após a avaliação do critério,
conseqüentemente, caso o usuário mude de tela, sem avaliar o
critério, os valores são perdidos; permitir ao usuário a possibilidade de retirar do processo de
inferência, a análise de quesitos que não se aplicam a empresa e/ou sistema; incluir
mecanismos que possibilitem a atribuição de pesos diferentes para cada quesito a ser
ponderado;
• O FMECA-Delphi e o NPR-Fuzzy poderiam ser incorporados como complementos
(
plugin
) ao OpenFMECA, para auxiliar a implementação da Etapa 3 da MCC. Além disso,
propõe-se o acréscimo das seguintes funcionalidades, as quais foram vislumbradas em
decorrência da aplicação em campo do OpenFMECA: outros formatos de relatórios, tais
como: relatórios das tarefas por tempo, apresentando os planos de ação classificados
cronologicamente, e relatório das tarefas por responsável, classificando as ações por
mantenedor; nos textos explicativos permitir a inclusão de figuras ilustrativas para as
causas, modos de falha e efeitos; definir políticas de restrição de acesso; elaboração da
FMECA utilizando análise
bow-tie
; estudar a possibilidade de se desenvolver toda a
análise da FMECA utilizando-se a técnica Delphi como no FMECA-Delphi; e, portar o
código e a interface para a língua inglesa, a fim de aumentar o número de usuários
potenciais e colaboradores da comunidade de software livre;
• No caso do FMECA-Delphi, estudar a possibilidade de automatizar o processamento da
informação pelo moderador. Tal melhoria iria corrigir os inconvenientes, constatados em
campo, que dificultam sua operacionalidade frente a um volume de dados muito grande e
onde a divergência de opiniões é muito acentuada;
• Incorporar ao DALF-MCC um método que utilize a técnica Delphi, tal qual o FMECA-
Delphi, para elicitar os parâmetros do conjunto
Fuzzy
de referência. Outra hipótese seria
incorporar ao DALF-MCC um banco de dados com valores padronizados e de consenso,
para os termos primários, válidos para domínios de aplicação específicos. Assim, seria
possível parametrizar os termos primários de forma que os mesmos convergissem para
202
um valor de consenso entre os especialistas, uma vez que, tal parametrização é muito
dependente das especificidades do domínio da aplicação.
Quanto aos aspectos conceituais vislumbram-se as seguintes possibilidades de
continuidade dos estudos promovidos neste trabalho:
• Aplicação de técnicas híbridas
Fuzzy
-Bayesianas para tratamento das incertezas em domínios
onde coexistam aleatoriedade e imprecisão. Este é o caso típico onde os dados estatísticos
relacionados à análise de falhas são inconsistentes, no todo ou para parte da aplicação. Essa
técnica poderia seria útil, particularmente, para a implementação das etapas 5 e 6 da MCC. A
mesma razão poderia viabilizar a utilização da técnica de Raciocínio Baseado em Casos;
• Aplicar as soluções metodológicas e de tratamento de incertezas, aplicados neste trabalho,
para a implementação de outras metodologias de gestão da manutenção, tais como, as
citadas por Fuentes, (2006). Desta forma poder-se-ia viabilizar, em uma única estrutura
computacional, a proposta de Fuentes (2006) para identificar a melhor metodologia de
gestão da manutenção e, após determinada tal metodologia, ferramentas mais específicas,
como o DALF-MCC, poderiam ratificá-la, implementá-la e auditá-la.
Desta forma, acredita-se que, os conceitos abordados neste trabalho podem contribuir com
soluções científicas relevantes para o estudo da engenharia do conhecimento, aplicada a tomada
de decisão durante a implantação e auditoria da MCC, bem como às atividades inerentes a este
processo. Desta forma cumpre-se a finalidade da pesquisa científica aplicada, almejada no
Capítulo 1.
203
REFERÊNCIAS
ABEL, Mara, Apostila do Curso de Sistemas Especialistas. Disponível em:
http://marabel.inf.ufrgs.br/Publico/Disciplinas/SistEspecialistasN/Inf1038-2003.pdf acessado em
28/02/2005.
ABNT – Associação Brasileira de Normas Técnicas. NBR-5462 Confiabilidade e
Mantenabilidade. ABNT/CB-03 – Eletricidade, Publicada em 30/11/1994.
ABRAMAN – Associação Brasileira de Manutenção. Documento Nacional de 2007. 22°
Congresso Brasileiro de Manutenção, Florianópolis – SC, Setembro de 2007.
ABS – American Bureau of Shipping. Guidance Notes on Reliability Centered Maintenance.
USA, 2004.
ALIBERAS, J., PINTÓ, R., GÓMEZ, R., Tres Enfoques de la Investigación sobre Concepciones
Alternativas. Editora Enseñanza de las Ciencias, 1996.
ALKAIM, João Luiz, Metodologia para Incorporar Conhecimento Intensivo às Tarefas de
Manutenção Centrada em Confiabilidade Aplicada em Ativos de Sistemas Elétricos. Tese de
Doutorado apresentada ao programa de Engenharia de Produção da UFSC, Florianópolis, 2003.
ANTONIETTI, Leandro Escagion, Análise Específica das Dificuldades de Implementação do
FMEA em uma Indústria Mecânica de Autopeças. Universidade Federal de Itajubá - Instituto de
Engenharia Mecânica - Departamento de Produção, 2002.
BACKLUND, Fredrik, Managing the Introduction of Reability Centred Maintenance: RCM as
a Method of Working within Hydropower Organizations. Tese de Doutorado apresentada ao
Department of Business Administration and Social Sciences da Luleå University of Technology,
Division of Quality & Environmental Management, Suécia, 2003.
BÁRDOSSY, A., DUCKSTEIN, L., Fuzzy Rule-Based Modeling with Applications to
Geophysical, Biological and Engineering Systems. CRC Press, 1995.
BARREIRO, S. R, Aplicação da Manutenção Centrada em Confiabilidade (MCC) para
Formulação do Plano de Manutenção do Sistema de Compressão de Gás Residual da Unidade
PSA. Dissertação de Mestrado apresentada ao Programa de Pós-Graduação em Engenharia
Mecânica da UFBA, Salvador, 1999.
BENJAMINS, V. R., FENSEL, D., Problem Solving Methods. International Journal of Human-
Computer Studies, 1998.
BERTLING, Lina, ALLAN, Ron, ERIKSSON, Roland, A Reliability Centred Asset
Maintenance Method for Assessing the Impact of Maintenance in Power Distribution
Systems. IEEE Transactions, 2003.
BEYON, Davis P., Expert Database Systems - A Gentle Introduction. London, Editora McGraw-
Hill, 1991.
BITTENCOURT, Guilherme, Inteligência Artificial: Ferramentas e Teorias. Editora da UFSC,
Florianópolis-SC, 2ª Edição, 2001.
BLANCO, Santiago Sotuyo. Los 10 Mandamientos del RCM: Claves para el Éxito de un
Proyecto de Implementación RCM. 22º Congresso Brasileiro de Manutenção, ABRAMAN, 2007.
204
BLOOM, Neil B., Reliability Centered Maintenance: Implementation Made Simple. Editora
McGraw-Hill Inc., 2006.
BOEHM, B., BROWN, J. R., KASPAR, H., LIPOW, M., MACLEOD, G. J., MERRIT, M. J.,
Characteristics of Software Quality. Editora North-Holland Publishing Company, New York, 1978.
BOFF, L. H., Gestão do Conhecimento - Notas de Aula. Programa de Pós-Graduação em
Computação, Porto Alegre, 2001.
BOOSE, J. H., BRADSHAW, J. M., Expertise Transfer and Complex Problems: Using
AQUINAS as a Knowledge Acquisition Workbench for Knowledge-Based Systems. em
Knowledge Acquisition Tool for Expert Systems, San Diego, California, Editora Academic Press
Limited, 1988.
BOWLES, John B., An Assessment of RPN Prioritization in a Failure Modes Effects and
Criticality Analysis. University of South Carolina, Columbia, 2003.
BRAGA, Washington Filho, Apostila do Curso de Termodinâmica - DEM PUC/RJ. Disponível
em:
http://leblon.mec.puc-rio.br/~wbraga/fentran/termo/termo1.htm acessado em 21/06/2005.
CAMPOS, Pio Filho, Método para Apoio à Decisão na Verificação da Sustentabilidade de uma
Unidade de Conservação, Usando Lógica
Fuzzy.
Tese apresentada ao Programa de Pós-
Graduação em Engenharia de Produção da Universidade Federal de Santa Catarina, como requisito
parcial para obtenção do título de Doutor em Engenharia de Produção, Florianópolis, 2004.
CARMO, Annibal José Roris Rodriguez Scavarda, Metodologia Evocativa para Mapeamento
Causal e sua Perspectiva na Gerência de Operações com Aplicações via Internet em Gestão da
Cadeia de Suprimento e Administração de Serviços. Tese apresentada ao Programa de Pós-
Graduação em Engenharia Industrial da Pontifícia Universidade Católica do Rio de Janeiro, como
requisito parcial para obtenção do título de Doutor em Engenharia Industrial, Rio de Janeiro, 2004.
CARVALHO, Lucimar Fossatti de, Análise dos Métodos de Aquisição do Conhecimento e
Desenvolvimento de um Sistema Baseado na Metodologia KADS. Dissertação de Mestrado
apresentada ao Programa de Pós-Graduação em Engenharia Elétrica e Informática Industrial do
CEFET-PR, Curitiba, 1995.
CASTILLO E. V., Aplicação de Ontologia e Sistema Especialista para Diagnóstico de Falhas
em Transformadores de Potência. Dissertação de Mestrado apresentada ao Programa de Pós-
Graduação em Engenharia Elétrica da UFSC, Florianópolis, 2003.
CHANDRASEKARAN, B., Generic Tasks in Knowledge-based Reasoning: High Level
Building Blocks, IEEE Expert, 1988.
CHANDRASEKARAN, B., JOSEPHSON, J. R., BENJAMINS, V. R., What are Ontologies, and
Why do We Need Them? Intelligent Systems, IEEE, Vol. 14, 1999.
CISL – Comitê de Implementação do Software Livre no Governo Federal. Disponível em:
http://www.softwarelivre.gov.br/ acessado em 31/05/2008.
CLANCEY, W. J. The Knowledge Level Reinterpreted: Modeling How Systems Interact.
Machine Learning Journal, Boston, 1989.
CLEAL, D. M.; HEATON, N.O., Knowledge - Based System. England, Editora Ellis Horwood, 1988.
205
COX, E., The Fuzzy Systems Handbook: A Practitioner's Guide to Building, Using, and
Maintaining Fuzzy Systems. A. P Professional, 1994.
DALKEY, Norman C., Delphi. Second Symposium on Long-Rang Forecasting and Planing.
Almagordo, New Mexico, 1967.
DALKEY, Norman C., The Delphi Method: An Experimental Study of Group Opinion. Santa
Monica: The Rand Corporation, 1968.
DALKEY, N.; BROWN, B.; COCHRAN, S., The Delphi Method III: Use of Self Ratings to
Improve Group Estimates. Santa Monica: The Rand Corporation, 1969.
DAMSKI, J. C. B., LIMA, J. G. M., GIORNO, F. G., VALENTE, A. S. M., Sistemas Especialistas
no Brasil: Um Enfoque Pragmático. Brasília, SUCESU, 1993.
DNV – Det Norske Veritas, Metodologia para Análise Preliminar de Perigo. Rio de Janeiro,
2003.
DAVENPORT, T.; PRUSAK, L., Working Knowledge: How Organizations Manage What
They Know. Boston, Editora HBS Press, 1998.
DURKIN, John, Expert Systems: Design and Development. New Jersey, Editora Prentice Hall, 1994.
ESHELMAN, L.; BOOSE, J.; GAINES, B., MOLE: A Tenacious Knowledge Acquisition Tool.
Knowledge Acquisition Tool for Expert Systems, San Diego, California, Editora Academic Press
Limited, 1988.
FEIGENBAUM, E. A., Themes and Case Studies of Knowledge Engineering. Expert Systems in
the Micro Eletronic Age. Edinburg, Editora Edinburg University Press, 1979.
FERNANDES, Anita Maria da Rocha, BASTOS, Rogerio Cid, Análise da Shell FuzzyCLIPS
como Ferramenta para Desenvolvimento de Sistemas Especialistas Difusos. Revista Alcance,
Itajaí, V.1, p.16 - 24, 2001.
FERNANDES, Anita Maria da Rocha, Inteligência Artificial - Noções Gerais. Editora Visual
Books, Florianópolis, 2003.
FERNANDES, Anita Maria da Rocha, Inteligência Artificial Aplicada à Saúde. Editora Visual
Books, Florianópolis, 2004.
FUENTES, Fernando Félix Espinosa, Metodologia para Inovação da Gestão da Manutenção
Industrial. Tese submetida à Universidade Federal de Santa Catarina como requisito parcial para a
obtenção do grau de doutor em Engenharia Mecânica, Florianópolis, Outubro 2006.
GARCIA, Pauli Adriano de Almada, Uma Abordagem Fuzzy com Envelopamento dos Dados da
Análise dos Modos e Efeitos de Falha. Tese de Doutorado apresentada a UFRJ - Universidade
Federal do Rio de Janeiro, 2006.
GASCHNIG, J., HAYES-ROTH F., WATERMAN, D. A., LENAT, D. B., Evaluation of Expert
Systems: Issues and Case Studies. Building Expert Systems, Editora Addison Wesley,
Massachusetts, 1983.
GENARO, Sérgio, Sistemas Especialistas: O Conhecimento Artificial. Editora LTC-Livros
Técnicos e Científicos, Rio de Janeiro e São Paulo, 1986.
206
GIARRATANO, Joseph, RILEY, Gary, Expert Systems - Principles and Programming. Boston,
Editora USA International Thomson Publishing, 3ª Edição, 1998.
GIL, A. C., Como Elaborar Projetos de Pesquisa. Editora Atlas, 3ªed., São Paulo, 1996.
GOBER, Cristiano José; SILVA, Luís Carlos Santos da; SANTOS, Rogério José dos. Aplicação de
Ferramentas Computacionais para Definição de uma Metodologia de Gestão da Manutenção.
2008, 132f. Trabalho de Conclusão de Curso – Curso Superior de Tecnologia em Gestão Comercial
Elétrica, Universidade Tecnológica Federal do Paraná, Curitiba, 2008.
GONZALEZ, Avelino J.; DANKEL, Douglas D., The Engineering of Knowledge Based Systems
- Theory and Practice. New Jersey, Editora Prentice Hall, 1993.
GRUBER, T. R., A Translation Approach to Portable Ontology Specifications. Em Knowledge
Acquisition, 1993.
GUIDA, G. e SPAMPINATO, L., Assuring Adequacy of Expert Systems in Critical Application
Domains: A Constructive Approach. em The Reliability of Expert Systems, de HOLLNAGEL,
E., Editora Ellis Horwood Limited, England, 1989.
GUPTA, Uma G.; CLARKE, Robert E., Theory and Applications of the Delphi Technique:
A Bibliography. (1975-1994). Technological Forecasting and Social Change. 53, 1996. Pg.
185-211.
HARMON, P.; MAUS, R.; MORRISSEY, W., Expert Systems Tools & Applications. New York,
Editora John Wiley & Sons, 1988.
HART, Anna, Knowledge Acquisition for Expert Systems. 2ª Edição, Editora McGraw-Hill, 1992.
HAUGE, B. S.; JOHNSTON, D. C., Reliability Centered Maintenance and Risc Assessment.
Annual Reliability and Mainteinability Symposium, IEEE Proceedings, 2001.
HEIJST, G., SHREIBER, A. T., WIELINGA, B. J., Using Explicit Ontologies in KBS
Development. International Journal of Human-Computer Studies, 1997.
HOLLNAGEL, Erik, The Reliability of Expert System. Editora Ellis Horwood Ltd, 1989.
IEC-60300-3-11. Dependability Management – Part 3-11: Application Guide – Reliability
Centred Maintenance. Primeira Edição, IEC – International Electrotechnical Commission, 1999.
IEC-60706-4 Guide on Maintainability of Equipment. Part 4 – Section 8: Maintenance and
Maintenance Support Planning. Primeira Edição, IEC – International Electrotechnical
Commission, 1992.
JOHNSTON, Donald C., Measuring RCM Implementation. Annual Reliability and
Mainteinability Symposium, IEEE Proceedings, 2002.
KARDEC, Allan; XAVIER, Júlio de Aquino Nascif, Manutenção: Função Estratégica. Rio de
Janeiro, Editora Qualitymark, 2003.
KELLY, G. A., Psychology of Personal Constructs. New York, Editora W. W. Norton, 1955.
LAUDON, Kewneth C.; LAUDON, Jane P., Gerenciamento de Sistemas de Informação. Editora
LTC - Livros Técnicos e Científicos, 3ª Edição, 2002.
207
LEBOWITZ, M., Experimental with Incremental Concept Information. UNIMEM, Machine
Learning p.103-138, 1988.
LEE, B., Using Bayes Belief Networks in Industrial FMEA Modeling and Analysis. Proceedings
of International Symposium on Product Quality and Integrity, Philadelphia, PA, 2001.
LIEBOWITZ, J., Useful Approach for Evaluating Expert Systems. em Expert Systems, 1986.
LIEBOWITZ, J., WILCOX, L. C., Knowledge Management and its Integrative Elements. Boca
Raton, Editora CRC Press, 1997.
LIMA, J. C. de Araujo e, Manual de Análise de Risco e de Confiabilidade. Petrobras – Reduc,
Rio de Janeiro, 1999.
LINSTONE, Harold A., TUROFF, Murray, The Delphi Method: Techniques and Applications.
2002. Disponível em:
http://www.is.njit.edu/pubs/delphibook. Acesso em: 05/12/2007.
LIRA, G. da S. de; FANTINATO M., Engenharia e Representação do Conhecimento.
Disponível em:
http://www.din.uem.br/~ia/conhecimento/index.htm acessado em 03/06/2005.
LUCATELLI, Marcos Vinícius, Proposta de Aplicação da Manutenção Centrada em
Confiabilidade em Equipamentos Médico-Hospitalares.
Tese de Doutorado apresentada ao
Programa de Pós-Graduação em Engenharia Elétrica da UFSC, Florianópolis, 2002.
MAMDANI, E.H; ASSILIAN, S. An Experiment in Linguistic Synthesis with a Fuzzy Logic
Controller. IEE Transaction, Man-Machine Studies, v. 7, n. 1, p. 1-13, 1975.
MARCOT, B., Testing Your Knowledge Base. AI Expert, 1987.
McCARTHY, J., MINSKY, M. L., ROCHESTER, N., SHANNON, C. E., A Proposal for the
Dartmouth Summer Research Project on Artificial Intelligence. Ano de publicação 1955,
Disponível em:
http://www-formal.stanford.edu/jmc/history/dartmouth/dartmouth.html acessado em
01/02/2005.
McDERMOTT, J., Preliminary Steps Toward a Taxonomy of Problem-Solving Methods., S.
Marcus Editor, Automating Knowledge Acquisition for Expert Systems, Kluwer Academic, 1988.
MELO, Carlos Haddad de, JUNIOR, João Marcus Sampaio Gueiros, MORGADO, Cláudia do
Rosário Vaz, Avaliação de Riscos para Priorização do Plano de Segurança. Congresso Nacional
de Excelência em Gestão da Universidade Federal Fluminense, Niterói, Rio de Janeiro, 2002.
MICHEL, Bernardo Amarante, Método de Representação de Processos em Forma de Fluxo –
IDEF0. Documento do Grupo de Modelagem de Informações para Suporte ao Desenvolvimento de
Produtos - MISDP do Departamento de Engenharia Mecânica da Universidade de Caxias do Sul, 2002.
MIL-STD-1629 A, Military Standard Procedures for Performing a Failure Mode, Effects and
Criticality Analysis. Department of Defense, USA. 1980.
MIL-STD-2173(AS), Military Standard – Reliability Centered Maintenance Requirements of
Naval Aircraft, Weapons Systems and Support Equipment. Department of Defense, USA. 1986.
MONCHY, François, A Função da Manutenção: Formação para a Gerência da Manutenção
Industrial. São Paulo, Editora Durban, 1989.
208
MOTTA, E. Reusable Components for Knowledge Models. PhD Thesis, Knowledge Media
Institute, The Open University, UK, 1998.
MOUBRAY, J., Reliability Centered Maintenance. New York, Editora Industrial Press, Revisão
da 2ª Edição, 2001.
MUSEN, M. A.; FAGAN, L. M.; COMBS, D. M.; SHORTLIFFE E. H. Use of a Domain Model to
Drive an Interactive Knowledge-Editing Tool. International Journal of Man-Machine Studies, 1987.
NAVAIR 00-25-403. Guidelines for the Naval Aviation Reliability Centered Maintenance
Process. US Navy’s Naval Air Systems Command (NAVAIR), 2005.
NASA - National Aeronautics and Space Administration. Reliability Centered Maintenance
Guide For Facilities And Collateral Equipment. NASA, 2000.
NASSAR, Silvia Modesto, Tratamento de Incerteza: Sistemas Especialistas Probabilísticos.
Apostila do Programa de Pós-Graduação do Departamento de Informática da Universidade Federal
de Santa Catarina (UFSC), Florianópolis, 2004.
NBR 5462.
Confiabilidade e Mantenabilidade. Rio de Janeiro, Editado pela Associação Brasileira
de Normas Técnicas (ABNT), 1994.
NONAKA, I., TAKEUCHI, H., The Knowledge Creating Company. Editora Elsevier, 1997.
NOWLAN, F. S., HEAP, H. F., Reliability Centered Maintenance. National Technical
Information Service, USA, Report Nº AD/A066-579, 1978.
ORTIZ, João Carlos Ross, Gestão do Conhecimento na Gestão da Manutenção: Uma Avaliação
Prática. Monografia apresentada a Universidade Tecnológica Federal do Paraná como requisito
parcial para obtenção do grau de Especialista no Programa de Pós-Graduação em Gerencia da
Manutenção, Curitiba, 2004.
PALADY, Paul, FMEA - Análise dos Modos de Falha e Efeitos (Prevendo e Prevenindo
Problemas Antes que Ocorram). Instituto IMAN, 3ª Edição, 2004.
PLUCKNETTE, Douglas J., When and How to Template an RCM Analysis. Disponível em:
http://www.reliabilityweb.com/ acessado em 25/01/2008.
POLYA, George, How to Solve It. 2ª Edição, Editora Princeton University Press, 1957.
PRESSMAN, Roger S., Software Engineering: A Practitioner's Approach. 6ª Edição, Editora
McGraw - Hill, 2004.
PROTÉGÉ-2000. User’s Guide. Disponível em:
http://protege.stanford.edu/ acessado em 10/03/2005.
PUERTA, R., EDGAR, J. W. TU, S. W., MUSEN, M. A., A Multiple Method Knowledge
Acquisition Shell for the Automatic Generation of Knowledge Acquisition Tools. 1996.
RABUSKE, Renato Antônio. Inteligência Artificial. Editora da UFSC, Florianópolis-SC, 1995.
RAJOTTE, Claude, JOLICOEUR, Alain, Reliability Centered Maintenance Implementation in
Hidro-Québec Transmission System. Annual Reliability and Mainteinability Symposium, IEEE
Proceedings, 2001.
RAPOSO, José Luis Oliveira, Manutenção Centrada em Confiabilidade Aplicada a Sistemas
209
Elétricos: Uma Proposta para Uso de Análise de Risco no Diagrama de Decisão. Dissertação
de Mestrado apresentada ao Programa de Pós-Graduação em Engenharia Elétrica da UFBA,
Salvador, 2004.
RAUSAND, Marvin, HØYLAND, Arnljot, System Reliability Theory: Models, Statistical
Methods, and Applications. Editora Wiley-Interscience, 2ª Edição, 2003.
REZENDE, Solange Oliveira, Sistemas Inteligentes - Fundamentos e Aplicações. São Paulo,
Editora Manole, 2003.
RIBEIRO, R. T.; ALVES, N. F., Manutenção Centrada em Confiabilidade Aplicada em
Instalações de Gás Natural do Gasoduto Bolívia Brasil. Disponível em:
http://www.gasnet.com.br/artigos/artigos_view2.asp?cod=527 acessado em 15/01/2005.
RIBEIRO, S., CUNHA, H., Introdução aos Sistemas Especialistas. LTC - Livros Técnicos e
Científicos, Rio de Janeiro e São Paulo, 1987.
RICH, Elaine, KNIGHT, Kevin. Inteligência Artificial. Editora McGraw - Hill, 2ª Edição, 1993.
RUSSELL, Stuart J., NORVIG, Peter, Artificial Intelligence: A Modern Approach. Editora
Prentice Hall, 2ª Edição, 2004.
SAE - JA1011. Evaluation Criteria for Reliability Centered Maintenance (RCM) Processes.
Society of Automotive Engineers, 1999.
SAE - JA1012. A Guide to the Reliability Centered Maintenance (RCM) Standard. Society of
Automotive Engineers, 2002.
SAE - J1739. Potential Failure Mode and Effects Analysis in Design (Design FMEA), Potential
Failure Mode and Effects Analysis in Manufacturing and Assembly Processes (Process
FMEA), and Potential Failure Mode and Effects Analysis for Machinery (Machinery FMEA).
Society of Automotive Engineers, 2002.
SANTIAGO Jr., José Renato Sátiro, Gestão do Conhecimento: A Chave para o Sucesso
Empresarial. Editora Novatec, 2004.
SCHREIBER, A. T. The KADS Approach to Knowledge Engineering. Knowledge Acquisition
Journal, 1992.
SCHREIBER, G.; AKKERMANS, H.; ANJEWIERDEN, A.; HOOG, R.; SHADBOLT, N.; DE
VELDE, W. V.; WIELINGA, B., Knowledge Engnineering and Management: The
CommonKADS Methodology. Editora MIT Press, Cambridge, Massachussets, 2002.
SEIXAS, Eduardo de Santana, Confiabilidade, Mantenabilidade e Disponibilidade. Apostila do
Curso de Especialização em Gerência da Manutenção, oferecido pelo Departamento Acadêmico de
Eletrotécnica da UTFPR (Universidade Tecnológica Federal do Paraná), Curitiba, 2004.
SHAW, I. S., SIMÕES, M. G., Controle e Modelagem
Fuzzy
. FAPESP. São Paulo, 2002.
SILVA, Jonny Carlos da, Expert System Prototype for Hydraulic System Design Focusing on
Concurrent Engineering Aspects. Tese de Doutorado apresentada ao Programa de Pós-Graduação
em Engenharia Mecânica da UFSC, Florianópolis, 1998.
SILVA, E. L, MENEZES, E. M., Metodologia da Pesquisa e Elaboração de Dissertação. 4ªed.
Florianópolis: LED/ PPGEP/UFSC, 2005.
210
SIQUEIRA, Iony Patriota de., Manutenção Centrada na Confiabilidade - Manual de
Implementação. Rio de Janeiro, 1ªed., Editora Qualitymark Ltda., 2005.
SIQUEIRA, Iony Patriota de., Measuring the Impacts of an RCM Program on Power System
Performance. IEEE/Power Engineering General Meeting, San Francisco, 2005a.
SIQUEIRA, Iony Patriota de., Grupos Multiempresariais de Manutenção Centrada na
Confiabilidade: Estudo de Caso no Setor Elétrico. Trabalho apresentado no 22º Congresso
Brasileiro de Manutenção, promovido pela ABRAMAN, 2007.
SMITH, A. M., Reliability Centered Maintenance. Boston Editora McGraw Hill, 1993.
SMITH, A. M., HINCHCLIFFE, G. R., RCM – Gateway to World Class Maintenance. Editora
Elsevier Butterworth-Heinemann, 2004.
SMITH, S., KANDEL, A., Verification and Validation of Rule Based Expert Systems. Editora
CRC Press, 1993.
SOMMERVILLE, Ian, Software Engineering. New York, 7ª Edição, Editora Addison Wesley, 2004.
STAMATIS, D. H., Failure Mode and Effect Analysis – FMEA from Theory to Execution.
Editora ASQC Quality Press, 1995.
STUDER, R.; BENJAMINS, V. R.; FENSEL, D., Knowledge Engineering: Principles and
Methods. Data & Knowledge Engineering Journal, Amsterdam, 1998.
SWARTOUT, W.; GIL Y.; VALENTE, A., Representing Capacities of Problem Solving Methods.
Em Proceedings of 1999 IJCAI Workshop on Ontologies and problem solving methods, 1999.
TEIXEIRA A., Multicriteria Decision on Maintenance: Spares and Contract Planning.
European Journal of Operational Research 129, 2001.
TERRA, José Cláudio Cyrineu, Gestão do Conhecimento: O Grande Desafio Empresarial.
Editora Negócio, 4ª Edição, 2001.
TSANG A., A Strategic Approach to Managing Maintenance Performance. Journal of Quality
in Maintenance Engineering. Vol. 4 No. 2, pp. 87-94. 1998
VERMESAN, A. I.; BENCH C. T., Techniques for the Verification and Validation of
Knowledge-Based Systems: A Survey Based on the Symbol/Knowledge Level Distinction.
Editora John Wiley & Sons, 1995.
VIZZONI, E.; ROSÁRIO, G. J.; OLIVEIRA, J. J. C.; FRANCESCHETT, J. G.; JANEIRO, M. P.;
CASTRO, R. T., Projeto Piloto de Manutenção Centrada em Confiabilidade (MCC)
Subestação de Adrianópolis - Setor de 500 kV. Trabalho apresentado no 14º Congresso Brasileiro
de Manutenção, promovido pela ABRAMAN, 1999.
WALTRICH, Sandro; TONDELLO, Cendar, O Processo de Manutenção Centrada na
Confiabilidade (MCC) como Prática Potencial de Gestão do Conhecimento. 22º Congresso
Brasileiro de Manutenção, ABRAMAN, 2007.
WATERMAN, Donald A., A Guide to Expert Systems. Editora Addison Wesley, 1986.
211
WIELINGA, B. J.; VELDE, Van De W.; SCHREIBER, G.; AKKERMANS, H., The
CommonKADS Framework for Knowledge Modelling. Publicado em: Proceedings of the 7ª
Banff Knowledge Acquisition for Knowledge-Based Systems Workshop, Banff, Canada 1992.
WIREMAN, Terry, Developing Performance Indicators for Managing Maintenance. New
York, Editora Industrial Press, 2ª Edição, 2005.
WORLEDGE, D., A Breakthrough in Reducing RCM Costs. Nuclear News, 1993, Vol. 36 N° 9,
Páginas 41-45.
YEN, J., LANGARI, R. Fuzzy Logic: Intelligence, Control and Information. Editora Prentice
Hall, New Jersey, 1998.
Referências de Internet:
Python 2.5.1 – Linguagem de programação (
http://www.python.org/).
TK 8.4 – Módulo (
built-in
) Python de Interface Gráfica (http://www.tcl.tk/).
LXML 1.3.4 – Módulo Python para manipulação de arquivos XML (
http://codespeak.net/lxml/).
Numpy 1.0.3.1 – Módulo Python para processamento matemático (
http://numpy.scipy.org/).
Matplotlib 0.90.1 – Módulo Python para plotagem de gráficos (
http://matplotlib.sourceforge.net/).
PIL 1.1.6 – Módulo para processamento de imagens (
http://www.pythonware.com/products/pil/).
Py2exe 0.6.6 – Módulo para "construção" de aplicativos Windows (
http://www.py2exe.org/).
Txt2tags 2.4 – Script Python para geração de documentos HTML (
http://txt2tags.sourceforge.net/).
FuzzyCLIPS 6.10d – Máquina de inferência
Fuzzy
(http://www.iit.nrc.ca/IR_public/fuzzy/).
SourceForge.net (
http://sourceforge.net/).
W3C | XML -
EXtensible Markup Language
(http://www.w3schools.com/xml/default.asp).
212
213
APÊNDICE A
MANUTENÇÃO CENTRADA NA CONFIABILIDADE
Apresenta aspectos suplementares relacionados ao Capítulo 2
214
215
APÊNDICE A
MANUTENÇÃO CENTRADA NA CONFIABILIDADE
A.1 GUIA PARA PREENCHIMENTO DA PLANILHA DE FMECA
Este item elucida os principais conceitos inerentes ao preenchimento da planilha de
FMECA (
Failure Modes, Effects and Criticality Analysis
ou Análise dos Modos de Falha seus
Efeitos e sua Criticidade), a qual pode ser vista na Figura A.1.
Figura A.1 – Planilha de FMECA adotada no Procedimento de Referência.
Fonte: ada
p
tado de SAE J1739.
Resultados das
Ações
Item
Função
Falha
Funcional
Modo
de
Falha
Efeito
do
Modo
de
Falha
Severidade (S)
Causas
do
Modo
de
Falha
Ocorrência (O)
Controles
Atuais
Detecção (D)
NPR (S.O.D)
Ações
Recomendadas
Responsável
e
Data de
Término
Programada
Ações
Adotadas
Severidade (S)
Ocorrência (O)
Detecção (D)
NPR (S.O.D)
A FMECA é uma técnica analítica que tem como propósito identificar, priorizar e eliminar
falhas potenciais de um sistema, projeto e/ou processo antes que estas atinjam o usuário final
(Omdahl, 1988). Ela teve sua origem no departamento de defesa dos Estados Unidos (DOD –
Department of Defense
), em 1949, com a norma militar MIL-P-1629 (
Military Procedure MIL-P-
1629: Procedures for Performing a Failure Mode, Effects and Criticality Analysis
). A FMECA se
distingue da FMEA (
Failure Modes Effects and Analysis
) pelo fato de agregar um índice de
criticidade que orienta a prioridade nas ações a serem executadas pela organização.
Os próximos parágrafos apresentam os conceitos que devem ser ponderados para o
preenchimento de cada uma das colunas que compõem uma planilha de FMECA (Figura A.1).
A.1.1 Função
Aquilo que se deseja que o item/ativo/sistema faça dentro de um padrão de desempenho
especificado. Ver Figura A.2.
Considerações Normatizadas e Bibliográficas:
● IEC 60300-3-11/1999 (Pg. 17 item 3.1.15) → Ação característica normal de um item.
● SAE JA1011/1999 (Pg. 04 item 3.13) e SAE JA1012/2002 (Pg. 06 item 3.13) → Aquilo que o
proprietário ou usuário do ativo físico ou sistema deseja que o mesmo faça.
216
● SAE J1739/2002 (Pg. 31 item 5.2.9) → A descrição da função deve levar em conta normas
aplicáveis de desempenho, de material, de processo, ambientais e de segurança.
● Moubray, 2001 (Pg. 22 item 2.1) → A descrição da função deve consistir de um verbo, um
objeto e um padrão desejado de desempenho.
Exemplo:
● Câmara de Extinção (Disjuntor SF
6
) → Conter o SF
6
, em uma faixa de pressão de 5,5 a 7 bar.
● Anel de Vedação “
O-Ring
” (Disjuntor SF
6
) → Manter o SF
6
dentro dos níveis de pureza
especificados pela IEC 60376.
P (Falha Potencial)
F (Falha Funcional)
Degradação
da Função
Função
Margem de
Deterioração
Normal
Defeito
Falha
Desempenho
Ciclo de Vida
Intervalo de Inspeção
Intervalo PF
Figura A.2 – Estágios Evolutivos da Falha.
A.1.2 Falha Funcional
Incapacidade de um item/ativo/sistema executar uma função específica dentro dos padrões
desejados de desempenho. Estado anormal da função do item/ativo/sistema. Ver Figura A.2.
Conceitos Correlatos:
● Falha Potencial → Condição identificável e mensurável que indica uma Falha Funcional
pendente ou em processo de ocorrência.
● Categorias de Falha Funcional:
→ Evidente: Detectável pelo operador durante sua atividade normal.
→ Oculta: Não é detectável pelo operador durante sua atividade normal.
217
→ Múltipla: Combinação de falha oculta mais uma segunda falha ou evento que a torne
evidente.
● Defeito → Desvio, além das características especificadas para um item/ativo/sistema, o qual é
detectável e não causa perda total da função requerida.
Considerações Normatizadas e Bibliográficas:
● IEC 60300-3-11/1999 (Pg. 17 item 3.1.17) → Falha na qual um item não consegue
desempenhar uma ou mais de suas funções requeridas.
● SAE JA1011/1999 (Pg. 04 item 3.14) e SAE JA1012/2002 (Pg. 06 item 3.14) → Um estado no
qual um ativo físico ou sistema é incapaz de desempenhar uma função específica com o
desejável nível de desempenho.
● Moubray, 2001 (Pg. 47 item 3.2) → Incapacidade de um ativo cumprir com a sua função com
um padrão de desempenho aceitável pelo usuário.
● ONS Resolução 140/02 de 25/03/2002 (Pg. 24, termo 7.257) → Falha: Efeito ou conseqüência
de uma ocorrência acidental em uma instalação ou equipamento que acarreta sua
indisponibilidade operativa em condições não programadas, impedindo-o de funcionar, e,
portanto, de desempenhar suas funções em caráter permanente ou em caráter temporário.
Falha MAIOR de um Disjuntor: falha completa de um disjuntor que acarreta a perda de uma ou
de várias funções fundamentais e exige normalmente uma intervenção num prazo de 30
minutos.
Falha MENOR de um Disjuntor: falha de um disjuntor que acarreta a perda de uma ou de
várias funções, mas que não originam falha maior.
Exemplo:
● Câmara de Extinção (Disjuntor SF
6
) → Não conter o SF
6
, em uma faixa de pressão de 5,5 a 7 bar.
● Anel de Vedação “
O-Ring
” (Disjuntor SF
6
) → Não manter o SF
6
dentro dos níveis de pureza
especificados pela IEC 60376.
A.1.3 Modo de Falha
Evento ou fenômeno físico que provoca a transição do estado normal para o estado
anormal (Figura A.2, ponto F). Durante o preenchimento da planilha de FMECA a pergunta que
se responde para o modo de falha é “O quê causou a Falha Funcional?” (SAE JA1012, Pg. 14 item
8). Ver Figura A.3.
218
Considerações Normatizadas e Bibliográficas:
● IEC 60300-3-11/1999 (Pg. 17 item 3.1.12) → Um dos possíveis estados de falha de um item,
para uma dada função requerida.
● SAE JA1011/1999 (Pg. 04 item 3.12) e SAE JA1012/2002 (Pg. 06 item 3.12 e Pg. 14 item 8)
→ Um evento ou condição física, que causa uma falha funcional.
● SAE J1739/2002 (Pg. 31 item 5.2.10) → Maneira como uma máquina/equipamento falha ao
executar sua função.
● Moubray, 2001 (Pg. 53 item 4.1) → Qualquer evento que cause uma falha funcional.
● ONS Resolução 029/V2.0 de abril de 2003 (Pg. 12) → Modos de Falha – São as situações
definidas como sendo os "defeitos" do sistema, tais como, sub-tensões, sobre-tensões,
ilhamentos, sobrecargas, déficits de geração, etc.
Exemplo:
● Câmara de Extinção (Disjuntor SF
6
) → Trincas na porcelana.
● Flange do Contato Fixo (Disjuntor SF
6
) → Acabamento inadequado da ranhura do flange.
P (Falha Potencial)
F
(Falha Funcional)
MF – Modo de Falha
Causas Efeitos
O que acontece quando
um MF se apresenta?
Por que o MF
ocorreu?
O quê causou a
Falha Funcional?
Figura A.3 – Síntese: Causas, Modo de Falha e Efeitos.
A.1.4 Efeitos do Modo de Falha
São os resultados para o sistema decorrentes da ocorrência de um modo de falha. Durante o
preenchimento da planilha de FMECA a pergunta que se responde para o efeito do modo de falha é
“O que acontece (item/ativo/sistema) quando um modo de falha se apresenta?”. Ver Figura A.3.
219
Conceitos Correlatos:
Uma descrição típica de Efeito do modo de falha deve conter informações suficientes para
avaliar os seguintes aspectos:
● Evidência da Falha → Como é observado o efeito.
● Impacto na Segurança → Que risco apresenta para as pessoas.
● Impacto Ambiental → Que danos traz ao meio ambiente.
● Reflexo Operacional → Como afeta a produção.
● Resultado Econômico → Qual seu impacto financeiro.
● Forma de Reparo → Como retornar a função ao normal após a falha.
● Características Compensatórias → Quais as características projetadas para reduzir o efeito.
Considerações Normatizadas e Bibliográficas:
● IEC 60300-3-11/1999 (Pg. 17 item 3.1.11) → Efeito imediato de cada modo de falha nos itens
funcionalmente significantes (Figura A.4) e nas funções requeridas destes itens.
Figura A.4 – Identificação de Funções Significantes.
Fonte: adaptado de IEC 60300-3-11.
● SAE JA1011/1999 (Pg. 04 item 3.9) e SAE JA1012/2002 (Pg. 06 item 3.9 e Pg. 19 item 9) →
Aquilo que acontece quando um modo de falha ocorre.
● SAE J1739/2002 (Pg. 31 item 5.2.11) → Trata-se do impacto do modo de falha no sistema,
subsistema ou componente.
● Moubray, 2001 (Pg. 73 item 4.5) → Os efeitos descrevem o que acontece quando um modo de
falha ocorrer.
220
Exemplo:
● Câmara de Extinção (Disjuntor SF
6
) → Vazamento de SF
6
.
→ Redução da pressão interna do SF
6
.
→ Abertura de arco elétrico nas partes condutoras internas.
→ Impossibilidade de fechamento do disjuntor.
● Anel de Vedação “
O- Ring
” (Disjuntor SF
6
) → Aumento da umidade interna da câmara de extinção.
→ Contaminação do SF
6
com subprodutos de reações internas.
→ Perda das características dielétricas e de extinção do SF
6
.
→ Descargas parciais.
A.1.5 Severidade (S)
Refere-se à gravidade ou o quão severo são os Efeitos do modo de falha.
Considerações Normatizadas:
● SAE J1739/2002 (Pg. 32 item 5.2.12) → Índice associado ao mais alto grau de
seriedade/gravidade do efeito do modo de falha.
Sugestão para Avaliação da Severidade:
A Tabela A.1 apresenta sugestões de critérios com seus respectivos Índices para avaliar a
Severidade dos Efeitos do modo de falha (SAE J1739, 2002).
Tabela A.1 – Sugestões de Critérios para Avaliar a Severidade dos Efeitos do Modo de Falha.
Fonte: SAE J1739, 2002 – Tabela 8, Pg. 34. (FMECA de Máquinas).
Severidade (S) do
eito do Modo de Falha
Impacto na Função devido à
Severidade dos Efeitos do Modo de Falha
Classificação
Ef
Perigoso Sem Aviso Impacto na segurança, saúde ou meio ambiente. A falha ocorrerá sem aviso. 10
Perigoso Com Aviso Impacto na segurança, saúde ou meio ambiente. A falha ocorrerá com aviso. 9
Muito Alto
Impacto muito alto. A Função é perdida e é necessário um longo período de
tempo para restauração da normalidade.
8
Alto
Impacto alto. Parte da Função é perdida e é necessário um longo período de
tempo até a restauração da normalidade.
7
Moderado
Impacto moderado. Parte da Função é perdida e é necessário um período de
tempo moderado até a restauração da normalidade.
6
Baixo Impacto baixo. A Função é prejudicada necessitando ser verificada. 5
Muito Baixo
Impacto moderado. Parte da função é prejudicada necessitando ser
verificada.
4
Pequeno
Impacto reduzido. A falha demora algum tempo para ser reparada, mas não
afeta a função.
3
Muito Pequeno Impacto insignificante. A falha pode ser reparada rapidamente. 2
Nenhum Não se verificam efeitos na segurança, saúde ou meio ambiente. 1
221
A.1.6 Causas
As Causas descrevem por que o modo de falha do item/ativo/sistema ocorreu, resultando
na falha funcional. Durante o preenchimento da planilha de FMECA a pergunta que se responde
para as causas do modo de falha é “Por que o modo de falha ocorreu?”. Ver Figura A.3.
Considerações Normatizadas:
● SAE J1739/2002 (Pg. 33 item 5.2.14) → É um indicativo de fragilidade de projeto ou de
processo que resulta no modo de falha.
A.1.7 Ocorrência (O)
Refere-se à freqüência com que as causas do modo de falha ocorrem ou o quão provável é
a ocorrência dos cenários (causas do modo de falha – cadeia causal que resulta nos efeitos).
Considerações Normatizadas e Bibliográficas:
● SAE J1739/2002 (Pg. 33 item 5.2.15) → Probabilidade de que a causa da falha ocorra em um
determinado período de tempo.
Sugestão para Avaliação da Ocorrência:
As Tabelas A.2 e A.3 apresentam sugestões de critérios com seus respectivos Índices para
avaliar a Ocorrência das causas da falha (SAE J1739, 2002).
Tabela A.2 – Sugestões de Critérios para Avaliar a Ocorrência da Causa da Falha.
Fonte: SAE J1739, 2002 – Tabela 5, Pg. 23. (FMECA de Processo).
Probabilidade de Ocorrência (O)
da Causa da Falha
Taxa de Falha (λ) Provável ao Longo do Ciclo de Vida Classificação
≥ 100 por mil itens 10
Muito Alta: Falhas Persistentes
50 por mil itens 9
20 por mil itens 8
Alta: Falhas Freqüentes
10 por mil itens 7
5 por mil itens 6
2 por mil itens 5
Moderada: Falhas Ocasionais
1 por mil itens 4
0,5 por mil itens 3
Baixa: Relativamente Poucas Falhas
0,1 por mil itens 2
Remota: Falha Improvável ≤ 0,01 por mil itens 1
222
Tabela A.3 – Sugestão de Critérios para Avaliar a Ocorrência da Causa da Falha.
Fonte: SAE J1739, 2002 – Tabela 8, Pg. 34. (FMECA de Máquinas).
Critérios avaliar a Probabilidade de Ocorrência (O) da Causa da Falha
Obs.: Utilizar 1 dos 3 Critérios.
Númer
o de Falhas
em função do Tempo
em Operação (horas)
Número de Falhas
em função do Ciclo
Operacional (ciclos)
Confiabilidade baseada no Tempo Requerido
pelo Usuário [C(t) %]
Classificação
1 em 1 1 em 90 C(t) < 1% → MTBF ≡ 10% do tempo em operação 10
1 em 8 1 em 900 C(t) = 5% → MTBF ≡ 30% do tempo em operação 9
1 em 24 1 em 36.000 C(t) = 19% → MTBF ≡ 60% do tempo em operação 8
1 em 80 1 em 90.000 C(t) = 37% → MTBF igual ao tempo em operação 7
1 em 350 1 em 180.000
C(t) = 61% → MTBF 2 vezes maior do que o tempo
em operação
6
1 em 1.000 1 em 270.000
C(t) = 78% → MTBF 4 vezes maior do que o tempo
em operação
5
1 em 2.500 1 em 360.000
C(t) = 85% → MTBF 6 vezes maior do que o tempo
em operação
4
1 em 5.000 1 em 540.000
C(t) = 90% → MTBF 10 vezes maior do que o
tempo em operação
3
1 em 10.000 1 em 900.000
C(t) = 95% → MTBF 20 vezes maior do que o
tempo em operação
2
1 em 25.000 1 em mais de 900.000
C(t) = 98% → MTBF 50 vezes maior do que o
tempo em operação
1
A.1.8 Controles Atuais
São as medidas preventivas e de detecção que já tenham sido tomadas e/ou são
regularmente utilizadas no item/ativo/sistema/processo para evitar a ocorrência das causas do
modo de falha.
A.1.9 Detecção (D)
Refere-se à probabilidade de que as características de projeto e os procedimentos de
verificação irão detectar as causas do modo de falha a tempo de prevenir uma falha funcional.
Expressa o quão difícil é detectar os eventos da cadeia causal que resultam nos efeitos do modo de
falha.
Quando esta análise está orientada para o processo, refere-se à probabilidade de que um
conjunto de controles de processo tenha condições de detectar e isolar uma falha antes que esta se
transfira para o processo subseqüente ou para o cliente/consumidor final.
Considerações Normatizadas:
● SAE J1739/2002 (Pg. 35 item 5.2.17) → É um índice associado ao melhor mecanismo de
detecção disponível na máquina/processo.
223
Sugestão para Avaliação dos Mecanismos de Detecção:
A Tabela A.4 apresenta sugestões de critérios com seus respectivos Índices para avaliar a
probabilidade de Detecção das causas da falha (SAE J1739, 2002 – Tabela 9, Pg. 35).
Chances de
Detecção (D)
Critério para avaliar a Probabilidade de Detecção (D) da Causa da Falha Classificação
Quase
Impossível
Os dispositivos de controle existentes não irão detectar uma causa/mecanismo
potencial e subseqüente modo de falha. Ou não existe um dispositivo de
controle relacionado com esta causa/mecanismo.
10
Muito Remota
A possibilidade que os dispositivos de controle existentes detectem a
causa/mecanismo potencial e subseqüente modo de falha é muito remota.
9
Remota
A possibilidade que os dispositivos de controle existentes detectem a
causa/mecanismo potencial e subseqüente modo de falha é remota.
8
Muito Baixa
A possibilidade que os dispositivos de controle existentes detectem a
causa/mecanismo potencial e subseqüente modo de falha é muito baixa.
7
Baixa
A possibilidade que os dispositivos de controle existentes detectem a
causa/mecanismo potencial e subseqüente modo de falha é baixa.
6
Média
A possibilidade que os dispositivos de controle existentes detectem a
causa/mecanismo potencial e subseqüente modo de falha é moderada.
5
Moderadamente
Alta
A possibilidade que os dispositivos de controle existentes detectem a
causa/mecanismo potencial e subseqüente modo de falha é moderadamente alta.
4
Alta
A possibilidade que os dispositivos de controle existentes detectem a
causa/mecanismo potencial e subseqüente modo de falha é alta.
3
Muito Alta
A possibilidade que os dispositivos de controle existentes detectem a
causa/mecanismo potencial e subseqüente modo de falha é muito alta.
2
Quase Certa
A possibilidade que os dispositivos de controle existentes detectem a
causa/mecanismo potencial e subseqüente modo de falha é quase certa.
1
Tabela A.4 – Sugestões de Critérios para Avaliar a Detecção da Causa da Falha.
Fonte: SAE J1739, 2002 – Tabela 9, Pg. 35. (FMECA de Máquinas).
A.1.10 NPR (S.D.O)
O NPR (Número de Prioridade de Risco) pode ser utilizado para comparar a criticidade de
diferentes modos de falha e assim priorizar as ações corretivas para os casos mais críticos. É o
produto dos índices de Severidade (S), Ocorrência (O) e Detecção (D):
NPR = Severidade x Ocorrência x Detecção
A.2 MCC Aplicada ao Gasoduto Bolívia Brasil (GASBOL)
Este item aborda os aspectos técnicos e práticos que culminaram com a adoção da
Manutenção Centrada na Confiabilidade (MCC) como forma de gestão da manutenção do
Gasoduto Bolívia Brasil (GASBOL).
224
A Transportadora Brasileira Gasoduto Brasil Bolívia S.A. (TBG) iniciou em 2000 um
programa de estudos baseado na metodologia de MCC com o objetivo de analisar suas principais
e mais críticas instalações e sistemas segundo esta metodologia, visando garantir uma alta
confiabilidade por meio da manutenção. Estes estudos permitiram aos participantes conhecer em
profundidade os sistemas e dispositivos das instalações; mapear através da FMEA os principais
modos de falha das funções dos diversos sistemas e dispositivos; avaliar as conseqüências das
falhas e seu impacto sob o ponto de vista de segurança, meio ambiente e operação; determinar as
atividades de manutenção (preventiva, preditiva e detectiva) necessárias à manutenção da
confiabilidade; identificar oportunidades de melhorias de projeto da instalação visando o
incremento de sua confiabilidade; identificar necessidades de implementação de procedimentos de
operação e manutenção ou modificação nos existentes (RIBEIRO e ALVES, 2005).
A TBG estabeleceu inicialmente suas rotinas de manutenção preventiva e preditiva
baseada nas práticas comuns adotadas por empresas similares, nas recomendações dos fabricantes
de seus equipamentos e instalações, nas determinações das normas ASME (
American Society of
Mechanical Engineers
), ABNT (Associação Brasileira de Normas Técnicas), PETROBRAS,
requisitos legais e experiência de seu corpo técnico (RIBEIRO e ALVES, 2005).
Em setembro de 1999, durante o 14º Congresso Brasileiro de Manutenção, promovido
pela ABRAMAN (Associação Brasileira de Manutenção), Vizzoni
et al
(1999) apresentou um
trabalho relatando a experiência do grupo de manutenção de Furnas Centrais Elétricas S.A. que
realizou um estudo de MCC na Subestação de Adrianópolis no Paraná. Constata-se pela Tabela
A.5 que as experiências em MCC no Brasil naquela época ainda eram poucas e muito recentes.
Tabela A.5 – Ferramentas para Promoção da Qualidade.
Fonte: VIZZONI
et al
, 1999.
Ferramentas para Promoção da Qualidade (% de Respostas)
Ano MCC 5S CCQ TPM Outros
2001 17,35 37,90 11,42 14,61 18,72
1999 5,62 40,45 16,29 20,79 16,85
1997 2,89 46,24 12,14 18,50 20,23
1995 - 39,83 17,37 21,61 21,19
A partir deste trabalho, a TBG iniciou um projeto piloto para implantação da MCC na
Estação de Entrega (EE) da REPLAN. Após os estudos iniciais para entendimento dos aspectos
teóricos e práticos da implantação da MCC, procedeu-se conforme descrito a seguir (RIBEIRO e
ALVES, 2005):
• Conhecimento das Instalações: nesta primeira etapa, todos os participantes, das diversas
especialidades, apresentam a teoria de operação e funcionamento dos diversos sistemas e
componentes abrangendo aspectos de automação, mecânica, segurança e operação. Nesta
etapa todos os participantes equalizam o conhecimento sobre as instalações e de seu
funcionamento;
•
Definição dos Sistemas: após seu estudo, a instalação foi dividida em sistemas com
identificação de suas entradas e saídas;
225
• Elaboração da Planilha de Informação: nesta etapa, a mais demorada, foram identificadas as
diversas funções dos sistemas e seus componentes, as possíveis falhas, os modos de falha
envolvidos e as conseqüências resultantes de cada falha;
•
Aplicação do Diagrama de Decisão: a partir das conseqüências dos modos de falhas, aplicou-
se o Diagrama de Decisão e identificou-se a relevância destas falhas sob o aspecto de
segurança, impacto ao meio ambiente e da operação da instalação. Estes dados são os
elementos iniciais de preenchimento da Planilha de Decisão;
•
Elaboração da Planilha de Decisão: a metodologia determina que, conforme a relevância das
conseqüências identificadas, estabeleçam-se as tarefas de manutenção necessárias para
eliminar ou mitigar estas conseqüências. Onde as conseqüências não são relevantes pode-se
optar por não executar nenhuma atividade preventiva, reparando ou substituindo o item
quando este falhar. Por outro lado, onde a execução de atividades da manutenção não for
suficiente, pode ser necessário, dependendo da relevância da conseqüência e dos custos
envolvidos, modificar o projeto da função através da substituição ou melhoria dos
componentes envolvidos. Esta planilha foi elaborada pelo grupo com o auxílio do Diagrama
de Decisão;
•
Montagem do Relatório Final: Ao término do estudo foi elaborado um relatório onde foram
apresentados os descritivos de funcionamento da EE, o plano mestre de manutenção, a relação
de melhorias (ou reprojetos) e demais recomendações e conclusões do estudo;
Segundo Ribeiro e Alves (2005), nas seis áreas estudadas foram identificados 309 modos
de falha. Deste total, 107 (35%) eram falhas ocultas, ou seja, os componentes poderiam falhar e
somente a percepção desta falha ocorreria se um outro evento (algumas vezes, de grandes
conseqüências) ocorresse. Foram levantados 90 modos de falha que necessitariam serem
verificados periodicamente (busca de falhas) a fim de se garantir a confiabilidade da EE. Foram
determinados 68 modos de falha possíveis de serem evitados ou minimizados através de ações
preventivas (restauração, troca, inspeção ou monitoramento).
Apesar da EE da REPLAN ser desabitada, o estudo de MCC proporcionou uma evidência
da importância da inspeção visual periódica, objetivando identificar situações anormais de
operação que não são detectadas pela Central de Supervisão e Controle no Rio de Janeiro. O
relatório deste estudo foi apresentado ao corpo gerencial que, a partir dos resultados alcançados e
do depoimento dos participantes, decidiu estabelecer um programa de estudos das principais
instalações do GASBOL (RIBEIRO e ALVES, 2005).
Ribeiro e Alves (2005) citam os principais benefícios alcançados a partir da implantação
da MCC na TBG, relacionados a seguir:
• Compreensão por parte da equipe, do funcionamento e dos modos de falha dos sistemas
envolvidos na análise, melhorando sua capacidade de análise e diagnóstico para detecção e
226
determinação das falhas resultando em tempos de parada de componentes e sistemas (ou da
EE) menores;
• O fato de o próprio colaborador envolvido na manutenção participar na elaboração e
determinação das atividades de manutenção da instalação gera um maior comprometimento
do mesmo com o cumprimento e eficácia destas ações;
• As planilhas de informações geradas pelos grupos de trabalho constituem-se em uma fonte de
informação importante, auxiliando na resolução de problemas de manutenção e servindo como
documento de referência para treinamentos;
• O plano mestre de manutenção gerado a partir do estudo dos modos de falha, procura agregar
valor ao processo de manutenção, evitando atividades que não possam ser garantidas quanto à
sua efetividade;
• Como estratégia de manutenção, fica clara a preservação das funções da instalação e não do
equipamento, pela realização de intervenções preventivas somente onde se justifica,
racionalizando recursos e diminuindo intervenções;
• A metodologia permite mapear as funções que possuem falhas ocultas que possam acarretar
conseqüências relevantes que de outra forma não seriam consideradas pelas metodologias de
manutenção tradicionalmente executadas;
• Com o melhor conhecimento da instalação e de suas falhas, também é possível uma definição
mais precisa dos sobressalentes críticos necessários à manutenção da disponibilidade do sistema;
• A aplicação da metodologia prevê que, onde não for possível minimizar ou mitigar as
conseqüências relevantes através da aplicação isolada ou combinada de atividades de
manutenção, modificações ou melhorias de projeto devem ser implementadas, para aumentar a
confiabilidade do sistema;
• Sempre com a visão de preservar as funções da instalação, os estudos de MCC identificam onde
existem necessidades de implementação de novos procedimentos operacionais e de manutenção
ou modificação dos existentes, inclusive para incorporar atividades de busca de falhas.
Em estruturas de manutenção já consolidadas e com os planos de manutenção já
determinados pelos métodos tradicionais (recomendações de fabricantes e fornecedores,
determinações legais e normativas e experiência do corpo técnico), os resultados dos estudos de
MCC são apresentados na forma de redução de quantidade de Homens/Hora empenhados em
manutenção preventiva e conseqüentemente em redução dos custos de manutenção. Estas
reduções podem alcançar até 40% (MOUBRAY, 2001).
No caso da TBG, os estudos de MCC foram realizados em instalações onde os planos de
manutenção ainda não estavam implementados ou que ainda não haviam completado um ciclo.
Esta forma de implantação é denominada “Base Zero”. Desta forma, os principais resultados
apresentados são traduzidos por altos índices de confiabilidade e baixo número de falhas
(RIBEIRO e ALVES, 2005).
227
APÊNDICE B
SISTEMAS BASEADOS EM CONHECIMENTO
Apresenta aspectos suplementares relacionados ao Capítulo 4
228
229
APÊNDICE B
SISTEMAS BASEADOS EM CONHECIMENTO
B.1 MODELOS PARA DESENVOLVIMENTO DE SOFTWARE
a)
Seqüencial Linear
O modelo seqüencial linear, cascata ou
waterfall
, também conhecido como ciclo de vida
clássico, é o modelo mais antigo e o mais amplamente utilizado. Ele sugere uma abordagem
seqüencial de atividades para o desenvolvimento do software com ciclos de realimentação, isto é,
pode-se retomar a qualquer atividade anteriormente executada e reiniciar o processo a partir dela. O
processo é modelado segundo um ciclo convencional de engenharia e segue o seguinte fluxo de
atividades: (1) análise e definição de requisitos, (2) projeto, (3) geração e teste de código, (4)
implantação e teste do sistema, e (5) operação e manutenção. Apesar de sua grande utilização, ele
apresenta alguns problemas, como sua inflexibilidade na partição do projeto em estágios distintos e
“estados de bloqueios” nos quais alguns membros da equipe necessitam esperar que outros
membros completem suas tarefas para que eles possam iniciar as suas. Isso pode levar a atrasos no
projeto que comprometam a produtividade, o que costuma ser impraticável nos dias atuais, pois, a
grande concorrência força a produção de software em um curto intervalo de tempo
(SOMMERVILLE, 2004 e PRESSMAN, 2004).
Segundo Gonzalez e Dankel (1993), as etapas do ciclo de vida, no desenvolvimento de
programas computacionais, utilizando o modelo seqüencial linear, cascata ou
waterfall
,
podem ser
seguidas conforme a Figura B.1.
Etapa 1
Análise
Etapa 2
Especificação
Etapa 3
Projeto
Etapa 4
Implementação
Etapa 5
Teste
Etapa 6
Manutenção
Figura B.1 – Etapas de Desenvolvimento de Software Utilizando o Modelo Seqüencial.
Fonte: GONZALES e DANKEL, 1993.
Segundo Rezende (2003), as características dos SBC’s fazem com que alguns modelos de
processo de desenvolvimento tenham difícil aplicação. O modelo seqüencial é um exemplo, uma
vez que a natureza iterativa da obtenção de conhecimento, a complexidade da validação e dos testes
e a complexidade de obtenção completa do comportamento desses sistemas no início do projeto são
fatores determinantes da dificuldade de sua utilização. Para Gonzalez e Dankel (1993) muitas vezes
a abrangência sobre o domínio do conhecimento é muito grande, o que torna muito complexo e
rígido este modelo, não permitindo realimentações e mudanças de paradigma ao longo do ciclo de
desenvolvimento do SBC.
230
b) Espiral
O modelo espiral combina os aspectos controlados e sistemáticos do modelo seqüencial
linear com aspectos de prototipagem, possibilitando o desenvolvimento rápido de versões
incrementais de software. Suas atividades são executadas seqüencialmente na forma de uma espiral,
partindo de seu centro e girando no sentido horário, Figura B.2. A cada volta completa, uma nova
interação é iniciada e um novo ciclo de tarefas é executado. A espiral é segmentada em regiões (de
três a seis) seguindo a seguinte ordem (SOMMERVILLE, 2004 e PRESSMAN, 2004):
• Comunicação com o usuário: envolve atividades e tarefas para estabelecer a comunicação
entre o desenvolvedor e o usuário;
•
Planejamento: envolve atividades e tarefas necessárias para definir recursos, prazos e outras
informações relacionadas ao projeto;
•
Análise de risco: envolve atividades e tarefas para avaliar os riscos, tanto técnicos quanto
gerenciais;
•
Engenharia: envolve atividades e tarefas para construir uma ou mais representações da
aplicação;
•
Construção e liberação: envolve atividades e tarefas necessárias para construir, testar,
instalar e fornecer apoio ao usuário;
•
Avaliação pelo usuário: envolve atividades e tarefas para obter realimentação do usuário,
com base na avaliação das representações do software criadas durante o estágio de
engenharia e implementas durante o estágio de instalação.
Manutenção e Evolução
Melhoria
Desenvolvimento de Novos Produtos
Desenvolvimento Conceitual
Construção e
Entrega
Engenharia
Análise de Risco
Planejamento
Avaliação pelo
Usuário
Comunicação
com o Usuário
de Pontos de
da do Projeto
Eixo
Entra
Figura B.2 – Etapas de Desenvolvimento de Software Utilizando o Modelo Espiral.
Fonte: PRESSMAN, 2004.
As voltas mais internas da espiral são dedicadas ao projeto de desenvolvimento conceitual do
produto, cujo resultado final pode ser um primeiro protótipo ou apenas a modelagem do sistema. As
próximas voltas são dedicadas ao desenvolvimento de novos atributos do produto cujos resultados são
versões cada vez mais complexas do sistema. As voltas seguintes são dedicadas a melhoria do
produto, cujo objetivo é efetuar ajustes finais no sistema e concluí-lo. Por fim, as demais voltas são
231
dedicadas à manutenção e evolução do produto. O início de cada projeto é marcado na espiral e
nomeado ponto de entrada do projeto. Como se trata de uma espiral, normalmente o ponto de entrada
de um projeto é o término de outro. Sendo assim, um eixo é traçado na espiral determinando o local
em que os pontos de entrada serão marcados (SOMMERVILLE, 2004 e PRESSMAN, 2004).
c) Baseado em Componentes
O modelo de desenvolvimento baseado em componentes, Figura B.3, busca desenvolver um
sistema a partir de componentes previamente desenvolvidos. Caracterizado naturalmente por um
processo evolucionário, necessita de uma abordagem interativa, o que lhe confere muitas das
características do modelo espiral. Este modelo é sustentado principalmente pela orientação a objetos
que enfatiza a criação de classes que encapsulam tanto os dados quanto os algoritmos para
manipulá-los, e, se adequadamente projetadas e implementadas são reusáveis em diferentes
aplicações (SOMMERVILLE, 2004 e PRESSMAN, 2004).
No modelo de desenvolvimento baseado em componentes, a atividade de engenharia começa
com a identificação das classes adequadas. Isso é obtido pelo exame dos dados a serem manipulados
pela aplicação e dos algoritmos a serem aplicados para efetuar a manipulação. Classes criadas em
projetos anteriores de engenharia de software são armazenadas em uma biblioteca ou repositório de
classes. Uma vez identificadas as classes adequadas, essa biblioteca é examinada para determinar se as
mesmas já existem. Em caso afirmativo, são reusadas. Se uma classe apropriada não é encontrada, é
então desenvolvida e inserida no repositório (SOMMERVILLE, 2004 e PRESSMAN, 2004).
Construção e
Entrega
Engenharia
Análise de
Risco
Planejamento
Avaliação pelo
Usuário
Comunicação
com o Usuário
Identificar os
componentes
adequados
Construir a enésima
interação do sistema
Inserir os novos
componentes na
biblioteca
Procurar
componentes na
biblioteca
Extrair os
componentes se
estiverem disponíveis
Construir
componentes se
não estiverem
disponíveis
B.3 – Desenvolvimento de Software com Modelo Baseado em Componentes.
Fonte: PRESSMAN, 2004.
d)
Modelo Geral para Desenvolvimento de SBC’s
Dentro da seqüência de etapas percorridas durante a evolução e o desenvolvimento dos SBC’s,
Figura B.4, independente do modelo adotado, tem-se obrigatoriamente, distribuídas ao longo de todo o
ciclo de desenvolvimento dos SBC’s, a passagem pelas seguintes fases (REZENDE, 2003):
232
1) Planejamento do SBC - Nessa fase é identificado o domínio do conhecimento, selecionada a
equipe de desenvolvimento do SBC e a ferramenta a ser utilizada no desenvolvimento do
sistema. O domínio de conhecimento deve ser plenamente entendido por toda a equipe para
uma melhor interação com o EH.
2) Aquisição do Conhecimento (AC) - Esta fase refere-se à identificação, conceituação e
formalização do conhecimento. Tem como objetivo adquirir os conhecimentos que serão
armazenados na Base de Conhecimento, ou seja, é a fase de execução do planejamento
realizado na etapa anterior.
3) Implementação do SBC - Nesta fase é realizada a codificação do sistema através de
linguagens ou ferramentas adequadas, documentado o sistema, gerado manuais e
implementado a interface do SBC. Nesta fase o conhecimento adquirido deve ser
representado formalmente. Para isso, utiliza-se a estrutura de Representação do
Conhecimento (RC) selecionada na Fase 1.
4) Validação e Refinamento do SBC - Esta fase envolve a validação e a verificação do sistema,
atividades complementares, necessárias para avaliar e assegurar a qualidade do SBC. Após a
avaliação das características dinâmicas do SBC o sistema é refinado, corrigindo algum
conhecimento incorreto ou ausente no modelo executável.
1) Planejamento do SBC
2) Aquisição do
Conhecimento
3) Implementação do SBC
4) Validação e
Refinamento do SBC
Documentar
o SBC
Validação e
Verificação
do SBC
Representar o
Conhecimento na
Ferramenta
Formalização
Conceituação
Implementar
a Interface do
SBC
Identificação
Refinar o
SBC
icar
mínio
Selecionar a
Ferramenta para
Desenvolvimento
Selecionar a
Equipe de
Desenvolvimento
Identif
o Do
Figura B.4 – Processo de Desenvolvimento de um SBC.
Fonte: REZENDE, 2003.
Segundo Rezende (2003) é importante ressaltar que, idealmente, a Etapa 1 ocorre apenas
uma vez ao longo do ciclo de vida do SBC, porém as Etapas 2, 3, e 4 compõem uma etapa contínua
de melhoramento do sistema.
B.2 AQUISIÇÃO E ELICITAÇÃO DO CONHECIMENTO – TÉCNICAS MANUAIS
a) Baseadas em Análise de Protocolo
Para Rezende (2003), técnicas baseadas em entrevistas compartilham os seguintes problemas:
233
• Especialistas são valiosos para as empresas e, por conta disso, são muito requisitados e
atarefados, não dispondo de tempo para o processo de AC;
• O entrevistado tende a se sentir avaliado no processo de entrevista, podendo acabar se
inibindo e omitindo importantes partes do seu conhecimento;
• O especialista retrata seu trabalho em vez de executá-lo, podendo não se lembrar do
conhecimento empregado, ou apresentar justificativas que não correspondam verdadeira-
mente ao conhecimento utilizado ao resolver o problema.
Métodos de acompanhamento visam entender o processo de raciocínio do especialista. O
Engenheiro do Conhecimento (EC) usa essas técnicas para descobrir qual conhecimento está sendo
usado e como ele está sendo usado pelo especialista em suas tarefas (REZENDE, 2003).
Na Análise de Protocolo, o EC pode utilizar uma amostra representativa de casos resolvidos
e solicitar ao especialista que explique como os resolveu. Ou o especialista é solicitado a realizar
uma tarefa real e, ao mesmo tempo, verbalizar o seu pensamento sob observação do EC que, mais
tarde, deve interpretar, organizar e analisar o processo de decisão do especialista e transpô-lo para
uma representação que possa ser revista pelo especialista. A Tabela B.1 mostra as vantagens e
desvantagens deste método (REZENDE, 2003).
Tabela B.1 – Vantagens e Desvantagens da AC Baseada em Análise de Protocolo.
Fonte: REZENDE, 2003.
Vantagens Desvantagens
O especialista considera de modo consciente as
heurísticas usadas no processo de decisão.
Muitas vezes, o especialista usa conhecimento
subjetivo ou tácito na resolução dos problemas e não
encontra palavras para verbalizá-lo.
O EC observa e analisa o comportamento do
especialista, durante o processo de decisão.
O especialista pode se desviar da tarefa de resolver o
problema para se concentrar na tarefa de buscar uma
explicação para as suas decisões.
O especialista expressa o conhecimento utilizado no
momento e no ambiente em que o está utilizando e as
dúvidas podem ser esclarecidas mais tarde.
Não existe garantia que o EC selecionará tarefas que
cubram todo o espectro de problemas necessário para a
criação da base de conhecimento.
b)
Brainstorming
A técnica conhecida como
Brainstorming
, consiste em reunir especialistas da mesma área e
promover um debate para que eles forneçam idéias e sugestões para o projeto. O EC faz o registro
dos fatos e estes, posteriormente, são analisados pelo grupo.
c)
Tomada de Decisão
A técnica de Tomada de Decisão acontece em comum acordo entre os especialistas que se
reúnem para deliberar sobre um determinado assunto. O objetivo é encontrar a melhor solução
obtida através de simples votação.
234
d)
Baseadas em Modelos
Segundo Rezende (2003), por muito tempo, as técnicas apresentadas anteriormente foram as
dominantes dentro da área de Engenharia do Conhecimento. Embora até hoje elas sejam
extremamente úteis, o seu uso exclusivo confere um caráter muito maior de arte, ao processo de AC,
do que propriamente de engenharia.
A técnica de aquisição baseada em modelos é fortemente baseada no reuso de componentes
de conhecimento, isto é, descrições estruturadas do conhecimento genérico envolvido na resolução
do problema objetivando a formulação de um modelo geral do conhecimento de uma determinada
aplicação (REZENDE, 2003).
Uma questão-chave a respeito da modelagem do conhecimento diz respeito ao tipo de
conhecimento enfocado inicialmente na construção do modelo. Segundo a bibliografia pesquisada,
algumas das alternativas são: Modelo de Domínio, Modelo de Tarefa e Modelo de Métodos de
Resolução de Problemas.
d1)
Modelo de Domínio
Descreve as entidades do domínio, suas relações e seu comportamento. O modelo do
domínio descreve o conhecimento estático e genérico da aplicação, podendo ser utilizado por mais
de um agente. No nível mais básico, o conhecimento do domínio é declarado por meio da ontologia
do domínio, que descreve o conhecimento declarativo e estático daquele domínio, a ser acessado por
todos os agentes que atuam sobre ele (ABEL, 2005).
O termo ontologia pode ser definido como uma especificação formal e explícita de um
conjunto de conceitos compartilhados. Os conceitos, neste caso, referem-se àqueles selecionados
como relevantes em um determinado domínio. Explícito significa que, o conjunto de conceitos
utilizados e as restrições aplicadas são previamente e explicitamente definidas. Formal refere-se ao
fato de que se espera que uma ontologia seja processável por computador, o que exclui definições em
linguagem natural, por exemplo. Finalmente, uma ontologia é compartilhada porque descreve um
conhecimento consensual, que é utilizado por mais de um indivíduo e aceito por um grupo (STUDER
et al
, 1998). Segundo Damski
et al
(1993) uma ontologia de domínio é definida através de:
• Um vocabulário de conceitos, ou termos do domínio.
• Os tipos que esses conceitos podem ter, ou seja, a tipologia do domínio, que definem não
só os tipos de dados, mas as restrições de valores que os termos devem respeitar.
• As relações de classe e subclasse ou de particionamento dos conceitos, que irão formar as
taxonomias
1
e partonomias
2
daquele domínio.
1
Taxonomias é a maneira como se organiza classes e sub-classes dentro da ontologia.
2
Partonomia é uma ligação semântica de como os conceitos podem ser organizados.
235
d2) Modelo de Tarefa
Descreve genericamente quais as características do problema e das soluções. O modelo da
tarefa expressa os objetivos da aplicação de uma forma precisa e sistemática e as atividades
necessárias para atingi-los. Expressa como um objetivo pode ser atingido e como diversos objetivos
são inter-relacionados (ABEL, 2005).
Segundo Schreiber (1992) uma tarefa é normalmente descrita através de dois componentes:
a definição da tarefa, que expressa qual o objetivo a ser atingido (caráter declarativo), e o corpo da
tarefa que especifica como atingir aquele objetivo (caráter procedimental). O modelo da tarefa
descreve ainda como um objetivo pode contribuir para alcançar outro objetivo, permitindo a
decomposição de uma tarefa em outras mais simples, construindo a estrutura de uma tarefa.
O modelo da tarefa, ao contrário do modelo do domínio, é específico para uma aplicação e
tipo de problema. Nele, são especificados os dados de entrada, as ações de inferência possíveis e as
condições para que o objetivo seja atingido (ABEL, 2005).
d3)
Modelo de Métodos de Resolução de Problemas
Os métodos de solução de problemas permitem modelar o componente dinâmico do
conhecimento do domínio. É uma forma de relacionar uma tarefa e o modelo do domínio a fim de
atingir determinado objetivo. Métodos de solução de problemas foram inspirados no processo de
solução de problema de especialistas humanos. Eles não refletem, por exemplo, o método dedutivo
que permite executar uma regra, mas sim o conhecimento de controle que diz como selecionar a
regra adequada a cada momento e como combinar as deduções de um conjunto de regras
(CLANCEY, 1989; BENJAMINS e FENSEL, 1998; STUDER
et al
, 1998).
Um método de solução de problemas é um modelo abstrato de inferência que pode ser
reconhecido ou reaplicado em tarefas similares em diferentes domínios. Não é, porém, tão genérico
ou equivalente aos métodos de inferência implementado nos sistemas especialistas de primeira
geração, como encadeamento progressivo ou regressivo. Corresponde a uma generalização de um
padrão de raciocínio específico, mas não é um raciocínio genérico que possa ser aplicado em
diferentes classes de problemas (BENJAMINS e FENSEL, 1998).
Métodos de solução de problemas têm sido, isoladamente, o mais intenso tópico de pesquisa
em Engenharia de Conhecimento recentemente. Consistem de um problema mal equacionado
cientificamente, pela pobre compreensão dos mecanismos cognitivos de solução de problema. Sua
compreensão e a geração de um modelo formal pode levar ao desenvolvimento de um conjunto de
metodologias mais maduras para construção de sistemas que utilizem conhecimento
(STERNBERG, 1994).
Entre as ferramentas de modelagem mais conhecidas podem ser citadas: Métodos
Limitados a Papéis (McDERMOTT, 1988), Tarefas Genéricas (CHANDRASEKARAN,
1988), KADS -
Knowledge Acquisition and Design Structure
(WIELINGA
et al
, 1992) e
236
Protegé II (MUSEN
et al
, 1987). Elas se baseiam primordialmente na diferenciação do tipo de
conhecimento envolvido na resolução de um dado problema. Contudo, cada uma delas
considera um diferente conjunto de tipos de conhecimento como fundamento de modelagem.
No KADS a implementação do sistema é responsabilidade do projetista, onde informações
adicionais relativas a detalhes de implementação são acrescentadas ao modelo de
conhecimento (REZENDE, 2003). Mais recentemente, Motta (1998) propôs uma nova técnica
de modelagem, denominada TMDA (
Task / Method / Domain / Application
), que procura
integrar consistentemente os tipos de conhecimento utilizados nas outras técnicas. TMDA se
fundamenta na idéia de que uma base de conhecimento de um SBC pode ser caracterizada em
termos da tarefa a ser resolvida, do método escolhido para resolver a tarefa, do domínio do
problema e da aplicação. Heijst
et al
(1997) identificam genericamente dois tipos de
modelagens adotadas pelas técnicas de aquisição baseadas em modelos Figura B.5.
•
Bottom-up
: refere-se ao processo de construção em que uma estrutura é imposta sobre um
conhecimento já adquirido sobre a aplicação;
•
Top-down
: refere-se ao processo de refinamento onde um modelo abstrato é selecionado
ou construído, e depois instanciado com conhecimento específico da aplicação.
Adquirir
conhecimento
Impor estrutura
ao conhecimento
j
á elicitado
Bottom-up
Selecionar ou
Construir o
modelo inicial
Instanciar o
modelo inicial
Top-down
Figura B.5 – Técnicas de Modelagem
Bottom-up
e
Top-down
.
Fonte: HEIJST
et al
, 1997.
Pode-se dizer que as duas formas de modelagem usam algum tipo de modelo inicial do
conhecimento, apesar de este modelo ser, no primeiro caso, bem fraco. A melhor forma de ver as duas
interpretações é como um contínuo entre extremos que varia de um suporte de modelo inicial fraco a
um suporte de modelo inicial forte (HEIJST
et al
, 1997).
Segundo Rezende (2003) na técnica
bottom-up
, o conhecimento pode ser adquirido,
inicialmente, por meio do uso de algumas das técnicas de AC mencionadas até aqui. Em seguida, ele é
trabalhado e complementado para formular os diferentes tipos de modelos de conhecimento. Estes são
utilizados para formular o modelo genérico de resolução de problemas que, por fim, é adaptado para
atender a aplicação específica. A técnica
top-down
tem sido o maior foco de pesquisa atualmente. Ela
assume a existência de bibliotecas de modelos gerais do conhecimento que podem ser selecionados e
integrados para produzir o modelo do conhecimento da aplicação. Este modelo geral de conhecimento
estrutura a base e serve de guia para a AC, indicando quais informações necessitam serem obtidas das
237
fontes disponíveis (REZENDE, 2003). No processo de construção e refinamento de modelos, cinco
atividades são executadas, como ilustrado na Figura B.6 (HEIJST
et al
, 1997):
Modelo
Inicial
Modelo Inicial
Instanciado
Modelo
Executável
Construção do
Modelo Inicial
Instanciação do
Modelo Inicial
Compilação do
Modelo Instanciado
Refinamento do
Modelo Instanciado
Valida
ç
ão
Figura B.6 – AC no Paradigma
Top-down
.
Fonte: HEIJST
et al
, 1997.
• Construção do Modelo Inicial: envolve a criação ou seleção de uma especificação abstrata do
conhecimento, necessária à realização de uma tarefa particular em algum domínio. Modelos
iniciais variam em quantidade de detalhes e em abrangência;
• Instanciação do Modelo: nessa fase, o modelo inicial é preenchido com o conhecimento de
domínio para gerar uma base de conhecimento completa. Em geral, o conhecimento é
representado em uma linguagem não executável;
• Compilação do Modelo: consiste em transformar o modelo inicial instanciado em uma base de
conhecimento executável;
• Refinamento do Modelo: nessa fase, as características dinâmicas do SBC são validadas
usando-se um conjunto de casos de teste. Um
feedback
é gerado no caso de algum
conhecimento incorreto ou ausente no modelo executável;
• Validação: provê
feedback
a respeito da validade do modelo inicial, que pode levar a
identificar partes que precisam ser adaptadas ou colocadas em uma biblioteca para reuso.
A principal vantagem das técnicas baseadas em modelos é induzir a construção de bases de
conhecimento mais organizadas e, conseqüentemente, menos propensas a inconsistências, erros e
incompletudes. A sua principal desvantagem é ainda demandar um grande esforço para a construção
do SBC, uma vez que, além da tarefa de construção do modelo de conhecimento da aplicação,
também é necessária uma etapa na qual o modelo é implementado na linguagem de programação
adotada pelo SBC.
e)
Técnica
Delphi
Apesar do primeiro experimento utilizando
Delphi
ter sido realizado em 1948, ela se tornou
popular somente após a publicação do primeiro artigo descrevendo a técnica, em 1963 (GUPTA e
CLARKE, 1996). Para Gupta e Clarke (1996),
Delphi
é uma das técnicas mais populares para
prognóstico no campo tecnológico e no industrial, onde se estima que 90% dos estudos fazem uso da
238
técnica. Ayyub (2001) vai além e qualifica
Delphi
como a técnica mais conhecidas para elicitação de
conhecimento de especialista.
As abordagens tradicionais de discussão em grupo são muito utilizadas a fim de possibilitar uma
interação entre os participantes para que se alcance um consenso sobre o assunto. No entanto, o
trabalho em grupo tem alguns inconvenientes, tais como: a presença de um participante dominante; a
capacidade de persuasão de cada um; a tendência do participante querer ter a aprovação da equipe; a
resistência de mudar de opinião depois de expô-la ao grupo (DALKEY, 1968); a pressão para se
alcançar um consenso; e o ruído causado por material redundante ou irrelevante que ofusca materiais
relevantes (DALKEY, 1967).
Dalkey (1967) constatou que, em questões que não se pode verificar a veracidade dos
resultados, tipicamente as opiniões convergem durante as iterações e que, nos casos que se pode
confirmar os resultados, as respostas tendem a se mover na direção da "resposta verdadeira". Após a
execução de experimentos comparando os resultados obtidos em reuniões estruturadas e por meio da
técnica
Delphi
, Dalkey (1967) observou que as respostas obtidas por meio de questionários foram
mais acuradas que as obtidas nas discussões em grupo. Outra constatação importante neste
experimento é que as respostas obtidas na segunda iteração dos questionários eram mais acuradas que
na quarta, e última, iteração. Acredita-se que este efeito tenha sido causado pela fadiga dos
participantes ou pelo fato de toda informação relevante ter vindo à tona na segunda iteração e as
iterações posteriores se tornaram devaneios. No entanto, não ficou clara a causa deste efeito.
A técnica
Delphi
possui as seguintes características: reduz os efeitos dos aspectos indesejáveis
das reuniões, decorrente da interação do grupo, destacando-se como características o anonimato,
elicitando separadamente e de forma privada as respostas das questões preparadas; possibilita
repetidas iterações do conhecimento elicitado; resolução das diferenças; controle da realimentação,
reduzindo o ruído de informações menos relevantes; e obtenção de uma estatística das respostas que
apresente a opinião do grupo de forma representativa (GUPTA e CLARKE, 1996; DALKEY, 1967).
Linstone e Turoff (2002) dividem os métodos de aplicação da técnica Delphi em dois grupos:
Delphi
convencional (lápis-e-papel) e conferência
Delphi
. No primeiro, um pequeno grupo de
mediadores elabora questionários para um grupo maior de respondentes. As respostas são, então,
resumidas e, baseado nos resultados, elabora-se um novo questionário. Usualmente, os respondentes
têm a oportunidade de avaliar as respostas do grupo pelo menos uma vez. Na conferência Delphi
computadores são programados para fazer a compilação dos resultados, reduzindo a influência do
grupo de moderadores. Isso traz algumas vantagens (Por Exemplo: a eliminação dos atrasos causados
no processamento das informações em cada rodada do
Delphi
) contudo requer que as características
da comunicação estejam bem definidas antes que a técnica seja aplicada, enquanto que no método
convencional o grupo de monitores pode fazer ajustes em função das respostas obtidas.
É interessante salientar que Brown (1968), já destacava na década de sessenta que
computadores poderiam ser utilizados para coletar as respostas dos especialistas; processar estas
informações; computar medidas sobre as respostas do grupo; agregar informações relevantes e
plausíveis de um banco de dados existentes; e realimentar o grupo para uma nova iteração.
239
Contudo, a técnica
Delphi
tem suas limitações e desvantagens. Ironicamente, algumas dessas
desvantagens são também vantagens, por exemplo: apesar do anonimato procura reduzir a influência
do grupo sobre o respondente, ele pode resultar num comprometimento individualizado e não refletir o
consenso do grupo (GUPTA e CLARKE, 1996). A seguir, seguem alguns outros inconvenientes de se
optar pela técnica
Delphi
(LINSTONE; TUROFF, 2002 e GUPTA; CLARKE, 1996): o mediador
pode impor sua visão ou estruturar o
Delphi
de forma a permitir outras perspectivas do problema; o
mediador pode ignorar e não explorar discordâncias, desencorajando a discussão o que pode acarretar
em um consenso artificial; o resumo e a apresentação das respostas de forma inadequada pode
dificultar, ou até inviabilizar, a aplicação da técnica; participantes podem inadvertidamente ou
deliberadamente promover um resultado; ausência de critérios para distinguir um especialista de um
leigo e ausência de evidências suficientes para julgar se a resposta de um especialista é mais confiável
que de outro; e assumir que a técnica
Delphi
pode resolver todo tipo de problema e ignorar outras
formas de comunicação.
B.3 AQUISIÇÃO E ELICITAÇÃO DO CONHECIMENTO – TÉCNICAS AUTOMATIZADAS
a)
Baseadas no Reuso do Conhecimento do Domínio
Um dos problemas com o uso de
shells
é que elas deixam sob encargo do EC ou do
especialista toda a responsabilidade por fornecer o conhecimento da aplicação a ser desenvolvida. Para
sanar esta limitação algumas ferramentas usam o conhecimento do domínio no qual são aplicadas para
interrogar o EC ou especialista a respeito do novo conhecimento que está sendo incorporado no SBC.
O fato de esta abordagem ser específica do domínio traz vantagens e desvantagens. Enquanto ela
permite o sistema utilizar a terminologia usada pelo especialista e fazer questionamentos detalhados
sobre o conhecimento do domínio, ela restringe a sua reutilização, uma vez que um novo domínio
pode apresentar características bem distintas do domínio presente na base de conhecimento
(REZENDE, 2003).
Um exemplo desta técnica de AC é o OPAL (
Object, Process and Actor Modelling Language
)
que é uma ferramenta de AC desenvolvida para o uso em um domínio particular: o planejamento da
terapia do câncer, que é feito por meio de complexos planos de tratamento denominados protocolos.
Ele dispõe de conhecimento sobre as principais drogas para o tratamento de câncer, sobre a química
do sangue e de como interagem entre si. O conhecimento do OPAL permite reduzir a elicitação de
conhecimento ao preenchimento de formulários. A ferramenta dispõe de editor gráfico para redes de
transição usadas para capturar os desvios e as iterações dos planos de tratamento.
b)
Baseadas no Reuso de Modelos
Segundo Rezende (2003) muitos construtores de SBC, representam o conhecimento de uma
maneira fortemente influenciada pela aplicação em desenvolvimento, sem se preocupar se esse
240
conhecimento pode ser usado por outros sistemas.
A partir desta constatação, os esforços se direcionaram a promoção do reuso de conhecimento
através da confecção de bibliotecas de componentes reusáveis de conhecimento e da disponibilização
de seus elementos para a composição de bases de conhecimento. Tais componentes são projetados
levando em conta o objetivo de serem reusados, em múltiplas aplicações, o que por um lado exige
maior rigor e esforço, mas por outro permite que o mesmo conhecimento só necessite ser representado
uma única vez. Esta técnica tornou-se ainda mais utilizada quando a aquisição começou a ser vista
como um processo de modelagem do conhecimento (REZENDE, 2003).
Para exemplificar esta técnica Swartout
et al
(1999) cita o EXPECT que é uma ferramenta de
AC que oferece uma biblioteca de métodos de resolução de problemas a partir dos quais um SBC pode
ser construído. Permite também a adição e extensão dos métodos existentes. Cada método tem
acoplado uma ontologia que define os termos usados no método.
Outro exemplo é a metodologia KADS -
Knowledge Acquisition and Design Structure
(WIELINGA
et al
, 1992) que tem evoluído no sentido de oferecer editores para os seus diversos tipos
de modelos, e disponibilizar o uso de bibliotecas de componentes reusáveis (ontologias, métodos de
resolução de problemas e procedimentos de inferência) e de indicar como utilizar estas ferramentas na
construção do SBC.
O PROTÉGÉ-II (PUERTA
et al
, 1996) amplia a abordagem PROTÉGÉ desvinculando-a de
um método específico de resolução de problemas e fornecendo várias ferramentas de apoio à
construção de SBC’s, dentre as quais um editor de ontologias, um mecanismo de configuração de
componentes e, em particular, uma ferramenta chamada DASH, que permite a geração de um sistema
de AC específico para um domínio, a partir de uma ontologia deste domínio.
Motta (1998) propõe um modelo flexível para organizar e utilizar bibliotecas de componentes
reusáveis, baseando-se em um paradigma de busca para criar um modelo genérico de resolução de
problemas que é instanciado com o conhecimento especifico da aplicação e configurado a partir de
bibliotecas de métodos, do domínio e de ontologias de tarefas.
c)
Baseada em Ontologias Reusáveis
Rezende (2003) afirma que: uma forma comum, de criar componentes reusáveis, é por meio
da confecção e disponibilização de ontologias de caráter genérico. Ontologias genéricas descrevem
conceitos e relações que podem ser usados em diferentes Bases de Conhecimento. Elas podem
descrever conceitos bem gerais como espaço, tempo, matéria, objeto, evento e ação, os quais são
independentes de um problema, domínio ou método em particular. Podem também descrever os
conceitos relacionados a um domínio genérico como medicina, engenharia, finanças ou automóveis,
ou relacionados a uma tarefa genérica como diagnóstico ou planejamento, ou mesmo relacionados a
um método genérico como gerar-e-testar ou propor-e-revisar.
Para Rezende (2003), os conceitos e as relações de uma ontologia podem ser definidos em
diferentes níveis de formalidade, variando desde definições altamente informais, em linguagem
241
natural, até definições rigorosas em linguagens formais, como a lógica de primeira ordem. Para
Motta (1998), pode-se ainda usar linguagens especificamente projetadas para a descrição de
ontologias, a mais conhecida dentre estas é a Ontolingua (GRUBER, 1993).
Em geral, quanto mais formal a ontologia, maior o potencial de reuso computacional.
Ontologias formais podem ser incorporadas a bases de conhecimento diretamente, quando expressas
na própria linguagem de representação do SBC, ou por meio do uso de tradutores automatizados.
Contudo, apesar de alguns experimentos bem sucedidos e do grande potencial de reduzir o ciclo de
desenvolvimento de SBC’s, existem algumas dificuldades para tornar o reuso eficiente. As
ontologias disponíveis não são gerais o bastante, para serem usadas com pouco esforço de
adaptação, o que pode acarretar uma preferência por construir uma nova ontologia a reusar uma
existente. Outro problema é que a integração de ontologias, pois elas podem possuir vocabulários e
visões conflitantes do mundo. Ontologias também não podem ser estacionárias, pois necessitam
evoluir com o tempo (REZENDE, 2003).
d)
AC Baseada no Reuso do Método de Resolução de Problemas
Algumas ferramentas baseiam-se no reuso de métodos genéricos de resolução de problemas. Em
contraste com o uso de
shells
, que fornecem uma forma de representação e um mecanismo de inferência
bastante geral, estas abordagens oferecem uma seqüência abstrata de etapas que devem ser realizadas
para resolver uma determinada classe de problemas. Embora esta técnica seja mais específica (só se
aplica a problemas que apresentem as características necessárias para a execução eficiente do método),
ela fornece mais elementos para reuso, direcionando e facilitando a aquisição (REZENDE, 2003).
Um exemplo desta metodologia é o MOLE, um sistema automatizado de AC para
problemas de classificação heurística que possui a capacidade de tolerar informações imprecisas,
capacidade de adicionar, refinar e corrigir a base de conhecimento. O método de resolução de
problemas adotado é o generalizar-diferenciar (
cover-and-differentiate
). O MOLE extrai
informações relevantes do especialista na construção de um solucionador de problemas heurístico, o
sistema está habilitado para retirar a ambigüidade sobre a base de conhecimento, ou seja, quando
existirem várias hipóteses que explicam um determinado conceito, o MOLE escolherá a melhor
explicação e gradativamente refinará a base de conhecimento. É utilizado na área de diagnóstico de
motores, problemas siderúrgicos e ineficiências em usinas termoelétricas (ESHELMAN
et al
, 1988).
e)
AC Baseada em Técnicas Provindas da Psicologia
A experiência do especialista é muitas vezes baseada em sua percepção e intuição. Por isso,
ele pode ter dificuldade em verbalizar a sua linha de raciocínio. Para sobrepor esse tipo de limitação da
AC e conseguir extrair o modelo mental do especialista sobre o domínio do problema, algumas
técnicas de elicitação foram desenvolvidas. Essas técnicas têm sua origem na psicologia e utilizam
uma abordagem denominada entrevista de classificação. Os princípios e as teorias da psicologia têm
242
sido aplicados na AC manual. Contudo, algumas destas técnicas são bem estruturadas e podem ser
auxiliadas por computador. O método mais conhecido, e que utiliza técnicas provindas da psicologia, é
o de Análise de Grades de Repertório (AGR) ou em inglês,
Repertory Grid
(REZENDE, 2003).
A AGR é baseada em um modelo de raciocínio humano (KELLY, 1955) denominado
Teoria de Construção Pessoal. Nessa teoria, cada pessoa é vista como um “cientista”, capaz de
predizer e controlar eventos, formando teorias, testando hipóteses e analisando resultados de
experimentos. O conhecimento e a percepção sobre o mundo (um domínio ou problema) são
classificados e categorizados pelo indivíduo, formando um modelo de percepção pessoal. Baseado
nesse modelo, cada pessoa é capaz de antecipar situações e atuar sobre essas antecipações. O
modelo pessoal descreve o desenvolvimento e o uso do conhecimento do especialista em trabalho e
é passível de ser implementado em um SBC (CARVALHO, 1995).
O sistema AQUINAS é um exemplo de ferramenta que entrevista especialistas utilizando o
método de AGR. Primeiro, a ferramenta solicita ao especialista identificar soluções para o seu
problema. Em seguida, a ferramenta pede que considere os atributos importantes para a sua tomada
de decisão. Depois, para cada atributo é solicitado estabelecer uma escala bipolar, ou seja, uma
escala com dois valores de atributos opostos. Finalmente, a ferramenta solicita ao especialista
atribuir valores de 1 a 5 para cada atributo das soluções dentro de sua respectiva escala bipolar. O
resultado fica registrado em uma grade de pontuações. Essa grade pode ser usada para recomendar,
em situações nas quais é conhecida a importância de cada atributo, qual a melhor solução. O sistema
AQUINAS é um sistema automatizado híbrido de aquisição e representação do conhecimento.
Possui vários métodos para gerenciar a incerteza com diferentes ferramentas que modelam as tarefas
básicas de AC e comparam o conhecimento de diferentes especialistas. A representação do
conhecimento é através de regras de produção. Este sistema é utilizado pela Boeing desde 1983
(BOOSE e BRADSHAW, 1988).
f)
Indução de Regras e Árvore de Decisão
A indução de regras se refere à detecção de tendências dentro de grupos de dados, ou de
regras sobre os dados. As regras são, então, apresentadas aos usuários como uma lista “não
encomendada”. A tradução das regras para um modelo aproveitável é feita pelo usuário ou por uma
interface de árvore de decisão (REZENDE, 2003).
As árvores de decisão são uma evolução das técnicas que apareceram durante o
desenvolvimento das disciplinas de aprendizado de máquinas. Elas cresceram a partir da
aproximação de uma análise chamada Detecção de Interação Automática (DIA), desenvolvida na
Universidade de Michigan. Essa análise tem a finalidade de realizar testes automáticos, com todos
os valores do atributo, para identificar aqueles que são fortemente associados com o item de saída
selecionado para o exame. Esses testes são realizados com o cálculo da entropia, que é um método
bastante utilizado para a construção de árvores de decisão, pois revela o grau de desorganização de
um atributo em relação ao item de saída. Os valores encontrados com forte associação são os
243
prognósticos chaves ou fatores explicativos, também chamados de regras sobre o dados. As árvores
de decisão são utilizadas quase sempre em conjunto com a
indução de regras, apresentando os
resultados da
indução de regras num formato com priorização. Logo, a regra mais importante é
apresentada na árvore com o primeiro nó e as regras menos relevantes são representadas como nós
subseqüentes (REZENDE, 2003).
g)
Knowledge Discovery in Data Base (KDD)
A Extração de Conhecimento de Bases de Dados ou o termo em inglês Knowledge
Discovery in Data Base (KDD), como é mais utilizado, foi criado em 1989 para se referir ao amplo
processo de descoberta de conhecimento em dados e, para enfatizar a aplicação de “alto nível” do
método particular de Mineração de Dados (
Datamining
). O termo Mineração de Dados era usado,
em geral, pelos estatísticos, analistas de dados e a comunidade de gerenciamento de sistemas de
informação, ao passo que KDD era mais usado pelos pesquisadores em IA e Aprendizado de
Máquina. O KDD mostra-se como uma ferramenta semi-automática que possibilita a análise de
grandes conjuntos de dados, propondo-se como o descobridor de informação útil a partir de grandes
bases de dados. A informação descoberta pode ser representada por regras, descrevendo
propriedades dos dados, padrões que ocorrem freqüentemente, agrupamento de objetos na base de
dados, etc... (FERNANDES, 2003).
O processo de KDD tem o objetivo de encontrar conhecimento a partir de um conjunto de
dados para ser utilizado em um processo decisório. Portanto, um requisito importante é que esse
conhecimento descoberto seja compreensível a humanos, além de útil e interessante para os usuários
finais do processo, que geralmente são tomadores de decisão, de forma que ele forneça um suporte a
esses usuários no processo de tomada de decisão. KDD é o processo de identificação de padrões
válidos, novos, potencialmente úteis e compreensíveis embutidos nos dados (REZENDE, 2003). A
Figura B.7 ilustra o processo KDD, que se caracteriza pelos seguintes passos (FERNANDES, 2003):
Figura B.7 – O Processo KDD.
Fonte: adaptado de FERNANDES, 2003.
Warehouse
Fonte de
Dados
Consolidação dos
Dados
Dados
Consolidados
Dados
Organizados
Padrões e
Modelos
Interpretação
e Avaliação
Conhecimento
Seleção e
Pré-processamento
Mineração
de Dados
• Compreensão do domínio: é um pré-requisito para se extrair qualquer conhecimento útil, ou
seja, o usuário de um sistema KDD deve ter uma certa compreensão sobre a área de
aplicação antes que qualquer informação de valor possa ser obtida;
• Organização do conjunto de dados: também conhecida como Armazenamento de Dados ou
Datawarehouse
, envolve a seleção da fonte de dados, a integração dos dados heterogêneos, a
244
limpeza dos erros nos dados, a avaliação do ruído, o tratamento dos valores perdidos, etc...;
• Descoberta dos padrões: é o passo em que os padrões freqüentes e de interesse são
levantados a partir dos dados.
h)
AC Baseada em Aprendizado de Máquina
O objetivo desta técnica segundo Rezende (2003) é desenvolver métodos computacionais
automáticos para AC. Um estudo mais aprofundado desta metodologia, pode ser visto em Carvalho
(1995), que cita as seguintes abordagens para efetivá-la: Aprendizagem por Memorização,
Aprendizagem por Aconselhamento, Aprendizagem por Indução, Aprendizagem por Explicações,
Aprendizagem por Descoberta, Aprendizagem por Analogia e Aprendizagem por Redes Neurais.
B.4 REPRESENTAÇÃO DO CONHECIMENTO (RC) – TÉCNICAS
a)
Representação Lógica
A lógica matemática é uma linguagem formal. Diferentemente de linguagens naturais nas
quais as regras gramaticais são imprecisas, nas linguagens formais sempre se pode dizer se uma
seqüência de símbolos está de acordo com as regras para a construção de expressões (fórmulas) da
linguagem (REZENDE, 2003).
A lógica matemática possui várias regras sintáticas de dedução, isto é, formas de realizar
inferências dedutivas exclusivamente a partir do formato sintático das expressões da linguagem, sem
se basear em quaisquer idéias extras ou intuitivas. O termo dedução automática refere-se ao
comportamento de qualquer programa de computador que realiza inferências dedutivas a partir das
leis da lógica matemática (RICH, 1993).
Existem vários tipos de lógicas usadas para a realização de dedução automática. O
cálculo proposicional é a mais simples delas porque baseia se apenas na existência de constantes e
no uso de operadores lógicos. Contudo o cálculo proposicional apresenta várias limitações. Para
isso, é necessário usar o cálculo de predicados ou lógica de primeira ordem. A lógica de primeira
ordem possui um grande potencial expressivo para a RC e tem sido o instrumento preferido para a
formalização do conhecimento durante o processo de desenvolvimento de um SBC. Várias
extensões da lógica matemática, dentro da área de dedução automática, têm sido estudadas, tais
como: lógicas não monotônicas, modais, temporais e descritivas. Essas extensões tornam o uso da
lógica, mais adequado e fácil em determinados contextos (REZENDE, 2003).
b)
Redes Semânticas
Uma rede semântica é um grafo rotulado e direcionado formado por um conjunto de nós
representando os objetos (indivíduos, coisas, conceitos, situações em um domínio) e por um
245
conjunto de arcos representando as relações entre os objetos. Um arco é rotulado com o nome da
relação que ele representa. Vários arcos podem ter o mesmo rótulo, entretanto cada objeto é
representado por apenas um nó (RICH, 1993).
Objetos complexos muitas vezes podem ser decompostos em objetos mais simples. Essas
decomposições produzem dois tipos de relações, ilustradas na Figura B.8:
• é um ou classe-de (
is-a
): as relações entre os objetos estão em uma taxonomia hierárquica;
• tem parte ou faz-parte (
part-of
): as relações objetos obedecem a um tipo de composição,
ou seja, um objeto é componente de outro, não havendo nenhum tipo de herança.
Etapas
MCC
FMEA
tem parte
tem parte
Gestão da
Manutenção
MCC TPM
é umé um
Figura B.8 – Exemplo de Redes Semânticas: Tipo é um e tem parte.
Fonte: do Autor.
Uma das propriedades mais importantes dessas relações é a transitividade, pois permite uma
declaração concisa de propriedades nos objetos mais gerais. Mecanismos de inferência podem,
então, ser utilizados para derivar essas propriedades para os objetos mais específicos. Esse
procedimento é denominado Herança de Propriedades (REZENDE, 2003).
Um dos atrativos das redes semânticas como forma de RC é a possibilidade de visualização
gráfica das estruturas de conhecimento e suas relações. Porém, muitas vezes, as representações
gráficas impõem limitações expressivas que podem restringir o uso deste tipo de linguagem
(REZENDE, 2003).
c)
Frames
Os
Frames
ou quadros, e sua variação, os roteiros ou
scripts
, foram introduzidos para
permitir a expressão das estruturas internas dos objetos, mantendo a possibilidade de representar
herança de propriedades como as redes semânticas. O
frame
é um termo usado para designar um
agrupamento de conhecimentos relevantes a uma coisa, um indivíduo, uma situação ou um conceito.
O
frame
possui um nome que identifica o conceito por ele definido e consiste de um conjunto de
atributos, chamados
slots
(BITTENCOURT, 2001). Em geral, um
frame
consiste em um conjunto
de atributos que, através de seus valores, descrevem as características do objeto representado pelo
frame
. Os valores atribuídos a estes atributos podem ser outros
frames
, criando uma rede de
dependências entre os mesmos. Os
frames
são também organizados em uma hierarquia de
especialização, criando uma outra dimensão de dependência entre eles. Os atributos também
apresentam propriedades, que dizem respeito ao tipo de valores e às restrições de número que
246
podem ser associados a cada atributo. Essas propriedades são chamadas facetas (BITTENCOURT,
2001). A Figura B.9 mostra um exemplo de uma representação utilizando
frame
.
Da representação mostrada na Figura B.9, pode-se concluir que um Compressor Alternativo é
um tipo de Compressor Volumétrico, normalmente com 2 câmaras de compressão, 2 cilindros e tem a
finalidade de comprimir gás, e possui alguns partes específicas um determinado número de estágios e
um modo de refrigeração. As facetas dos atributos especificam os tipos de valores esperados e, se for o
caso, procedimentos adequados para calcular o valor do atributo (campo observação).
Segundo Bittencourt (2001), da mesma maneira que as redes semânticas, os sistemas baseados
no método de
frames
não são um conjunto homogêneo, no entanto, algumas idéias fundamentais são
compartilhadas por estes sistemas. Uma dessas idéias é o conceito de herança de propriedades, o que
permite a especificação de propriedades de uma classe de objetos através da declaração de que esta
classe é uma subclasse de outra que goza da propriedade em questão. A herança pode ser um mecanismo
de inferência muito eficiente em domínios que apresentem uma taxonomia natural de conceitos. Outra
idéia comum aos sistemas baseados em
frames
é o raciocínio guiado por expectativas . Um
frame
contém atributos, e estes atributos podem ter valores típicos. Ao tentar instanciar um
frame
para que
corresponda a uma dada ocorrência, o processo de raciocínio deve tentar preencher os valores dos
atributos do
frame
com as informações disponíveis na descrição da ocorrência. Com esta característica o
processo de raciocínio, sabe o que procurar para completar a informação necessária, e caso esta não
esteja disponível, que valores pode tentar imputar aos atributos não preenchidos. Além dos valores
default
, um atributo pode ser associado a um procedimento, que deve ser executado quando certas
condições forem satisfeitas, por exemplo: ao ser criado o atributo, ao ser lido o valor do atributo, ao ser
modificado o valor do atributo, ou ao ser destruído o valor do atributo.
d)
Objeto-Atributo-Valor
Conforme Durkin (1994), além das relações entre objetos, como redes semânticas, há
situações que requerem uma descrição das características do objeto por meio de fatos. Estes fatos
são declarações de um valor para um atributo particular do objeto. Este tipo de fato é conhecido
como tríade Objeto-Atributo-Valor (OAV). A representação tríade OAV divide uma dada
Frame
: Compressor Alternativo Super
Frame
: Compressores Volumétricos
Atributos
Default
Tipo Observação
Partes
Pistão, Eixo,
Biela
Lista de
Símbolos
Número de Estágios 2 Número
Modo de Refrigeração Ar Símbolo
Frame
: Compressores Volumétricos Super
Frame
: Compressor
Atributos
Default
Tipo Observação
Número de Câmaras de Compressão 2 Número
Número de Cilindros 2 Número
Finalidade Comprimir Gás Símbolo
éum
Figura B.9 – Exemplo de
Frames
.
Fonte: do Autor.
247
declaração em três partes distintas: objeto, atributo e valor. O objeto representado em uma tríade
OAV pode ser um item físico, tal como uma bomba ou válvula, ou um item abstrato tal como falha
ou defeito. Atributo é uma característica do objeto que é importante no domínio do problema. O
valor especifica a designação do atributo. O valor pode ser booleano, numérico ou não numérico.
Normalmente os objetos a serem representados em um SBC apresentam mais de uma característica
relevante. Nestas situações mais de um atributo com seus valores correspondentes caracterizam um
objeto. Um exemplo é considerar a falha como objeto com seus atributos e valores, conforme
mostrado na Tabela B.2. A representação OAV é útil para modelar as condicionais a serem
combinadas com os fatos premissas, de uma regra.
Tabela B.2 – Exemplo de Representação Objeto – Atributo – Valor (OAV).
Fonte: do autor.
Objeto Atributo Valor
Falha Modo Pressão Alta na Descarga da ECOMP
Falha Efeitos
1) Pressão alta a jusante da ECOMP
2) Desligamento da ECOMP
Falha Causas internas
1) Falha na Válvula do Coletor de Descarga
2) Falha no Compressor
Falha Componente de origem Compressor
Falha Tipo de comprometimento Envolve segurança pessoal
Falha Condições Monitoráveis Desgaste, Quebra, Pressão, Vazão
e)
Ontologias
De acordo com Chandrasekaran
et al
(1999), as teorias sobre inteligência artificial podem
ser classificadas em duas grandes categorias: as teorias dos mecanismos e as teorias do conteúdo. As
ontologias são teorias do conteúdo com relação às classes de objetos, às propriedades dos objetos e
às relações dos objetos que são possíveis dentro de um domínio específico do conhecimento. Elas
fornecem termos potenciais para descrever o conhecimento sobre o domínio.
Uma ontologia é uma descrição formal e explícita dos conceitos em um domínio de discurso
(classes, às vezes chamadas de conceitos), propriedades de cada conceito descrevendo várias
características e atributos do conceito (
slots
, às vezes chamados de papéis ou propriedades), e restrições
sobre
slots
(facetas, às vezes chamadas de restrições do papel). Uma ontologia junto a um jogo de
instâncias individuais e classes constitui uma base de conhecimento. Na realidade, é difícil demarcar
onde termina uma ontologia e começa a base de conhecimento (CHANDRASEKARAN
et al
, 1999).
Em termos práticos, o desenvolvimento de uma ontologia inclui: definir as classes na ontologia,
dispor as classes numa hierarquia taxonômica (subclasses - superclasses), definir os
slots
, descrever
valores permitidos e preencher os mesmos com os valores para as instâncias (CASTILLO, 2003).
Uma das ferramentas para RC que utiliza ontologias para RC é o Protégé, que dispõe de
uma interface gráfica, baseada em janelas, que permite ao usuário construir uma ontologia do
domínio, formatar formulários para aquisição do conhecimento e então completar com o
conhecimento do domínio. Sua plataforma pode ser estendida com outros programas aplicativos,
adicionando capacidade de gerar diagramas gráficos das ontologias criadas e executar diretamente
248
em seu ambiente arquivos de regras para linguagens como o JESS (uma extensão do CLIPS para
Java) que utiliza a base de conhecimento criada no Protégé. Podemos, então, criar uma base de
conhecimentos definindo instâncias individuais destas classes, preenchendo a informação específica
do valor dos
slots
e as restrições adicionais dos mesmos (CASTILLO, 2003).
O editor de ontologia Protégé permite uma integração do domínio de uma ontologia de classes
descrevendo um tema determinado, a criação de uma ferramenta de AC para coletar o conhecimento, a
entrada de instâncias específicas de dados e a criação de uma base de conhecimento, e finalmente a
execução de aplicações. A ferramenta para a AC é desenhada para ser específica ao domínio,
permitindo aos peritos do domínio estabelecer de maneira fácil e natural a base de conhecimento da
área. O Protégé foi projetado para guiar os desenvolvedores e especialistas de domínio no processo de
desenvolvimento do sistema, permitindo aos mesmos reutilizar as ontologias e os métodos para a
resolução de problemas, encurtando o tempo requerido para isto (PROTÉGÉ, 2005).
B.5 VERIFICAÇÃO E VALIDAÇÃO DE SBC
Historicamente, os primeiros critérios de avaliação, para descrever as características de
qualidade desejáveis nos SBC’s foram fornecidas por Gaschnig
et al
(1983) e serviram de base para
avaliação dos primeiros SBC’s e também, para trabalhos recentes que procuraram definir
características de qualidade para os SBC’s. Liebowitz (1988) propõe critérios para avaliação da
qualidade de SBC’s objetivando atualizar os conceitos de qualidade para SBC’s reunindo as
características propostas por Boehm
et al
(1978), para softwares convencionais e Gaschnig
et al
(1983), para SBC’s. Marcot (1987) propõe critérios para a avaliação da base de conhecimento e
fornece uma lista extensiva de critérios de validação e do porque a base de conhecimento deve ser
validada. Guida e Spampinato (1989) desenvolveram um conjunto detalhado dos critérios para
avaliar a adequação dos SBC’s em domínios críticos. Estes critérios foram elaborados para avaliar a
estrutura interna do SBC durante seu ciclo de vida. Mais recentemente, a pesquisa em critérios de
qualidade para os SBC’s começou a dirigir-se também para a qualidade do processo do
desenvolvimento Giarratano e Riley (1998) desenvolveram uma lista dos critérios que abrangem
características do processo de desenvolvimento e do produto de software, estes critérios, referidos
como métricas, incluem características tais como mantenabilidade, portabilidade e compreensão do
código, que refletem como o produto de software foi projetado e executado, isto é, seu processo de
desenvolvimento. A verificação e a validação são atividades complementares, necessárias para
avaliar e assegurar a qualidade dos SBC’s (SMITH e KANDEL, 1993).
A validação determina a eficácia do sistema final com relação às necessidades do usuário
final e ao mesmo tempo avalia se o SBC executa a tarefa desejada com um nível suficiente da
perícia. A validação analisa as exigências explícitas e implícitas do sistema. As exigências explícitas
são aquelas definidas na fase de planejamento e especificação do SBC, e que necessitam ser
confirmadas e testadas. Nesta etapa valem os preceitos das normas para softwares convencionais
ISO/IEC 9126 ou NBR 13596. As exigências implícitas analisam a habilidade do SBC se equiparar
249
a um EH na resolução de suas tarefas, estas características são únicas dos SBC’s e não são válidos
os preceitos das normas para softwares convencionais. Nesta etapa, utilizando-se da análise
dinâmica, as respostas do SBC são confrontadas com as respostas do EH ou com soluções de casos
anteriores, buscando ratificar a acurácia do SBC (SMITH e KANDEL, 1993).
As atividades de verificação e validação devem estar presentes em todas as etapas de
desenvolvimento do SBC. O julgamento do SBC por parte do EH deve ser isento de preconceitos ou
receios, devendo ficar claro o fato do SBC tratar-se de uma ferramenta de apoio e não um substituto
do EH. Para eliminar a subjetividade, ganhar tempo e evitar atividades tediosas, ferramentas
automáticas podem ser utilizadas, tanto na etapa de verificação quanto na etapa de validação do
SBC (SMITH e KANDEL, 1993). Vermesan e Bench (1995), descrevem diversas ferramentas para
verificação e validação automática de SBC, entre elas destaca-se: KRUST - Knowledge Refinement
Using Semantic Trees: faz um refinamento da base de regras tentando evidenciar possíveis falhas
nas regras do SBC; COVADIS: é uma ferramenta específica para a shell MORSE que testa a
inconsistência da base de regras; CONKRET - Control Knowledge Refinement Tool: testa a
funcionalidade das metaregras; IN-DEPTH: ferramenta para verificação incremental de SBC’s.
B.6 MODELAGEM DO CONHECIMENTO
A transição do Projeto Orientado a Objetos para a Programação Orientada a Objetos nem
sempre é bem definida, numa tentativa de definir uma forma padronizada e unificada de modelagem
foi criado a UML (
Unified Modeling Language
). A UML é uma linguagem de modelagem visual
que utiliza vários tipos de diagramas para auxiliar o analista e o projetista a documentar parte ou
todo o processo de software. Cada diagrama é uma apresentação gráfica de uma coleção de
elementos de modelagem (símbolos gráficos), freqüentemente relacionados por arcos e vértices
(relacionamentos), que ilustram partes distintas do software. Alguns desses diagramas são: diagrama
de caso de uso, diagrama de classe, diagrama de seqüência, diagrama de colaboração, e diagrama de
implantação (SOMMERVILLE, 2004 e PRESSMAN, 2004).
A UML possui também vários mecanismos que podem ser utilizados para facilitar a compreensão
dos diagramas, como estereótipos, restrições e valores atribuídos. Esses mecanismos também podem ser
utilizados para estender a sintaxe e a semântica da linguagem, possibilitando a criação de novos
elementos de modelagem e notações. A grande vantagem da UML com relação a outros métodos é que
ela não é um método em si, mas sim, uma linguagem para representação de um sistema e pode ser
aplicada de maneira independente em todas as fases do processo de desenvolvimento de software. Por se
tratar de uma linguagem, a transição entre as fases de análise, projeto e codificação é natural, rápida,
complementar e sem ambigüidade. Em UML, um sistema é representado por cinco “visões” diferentes,
cada qual definida por um conjunto de diagramas (PRESSMAN, 2004):
• Visão de caso de uso: representa o sistema a partir da perspectiva do usuário;
• Visão de projeto: abrange as classes, interfaces e colaborações que definem o sistema como software;
• Visão de processo: representa os aspectos dinâmicos ou comportamentais do sistema;
250
• Visão de implementação: representa os componentes e arquivos utilizados para a montagem e
fornecimento do sistema físico;
• Visão de implantação: representa o ambiente em que o sistema é executado (hardware e topologia).
Essas visões podem ser tratadas isoladamente, permitindo que os participantes do processo
de desenvolvimento do software tratem aspectos específicos do sistema (PRESSMAN, 2004).
B.7 CONFIABILIDADE DE SBC
Segundo Hollnagel (1989), a análise da confiabilidade de SBC deve levar em conta tanto a
confiabilidade interna quanto a confiabilidade externa. A confiabilidade interna se ocupa das
características intrínsecas do SBC: máquina de inferência, a representação do conhecimento, o
tratamento de incertezas, etc. A confiabilidade externa se ocupa da interação com o usuário: a
interface, a qualidade das respostas, etc. A confiabilidade externa depende claramente da
confiabilidade interna, entretanto, mesmo que uma alta confiabilidade interna seja condição
necessária para se obter alta confiabilidade externa, ela não é suficiente para garanti-la. Uma alta
confiabilidade das partes individuais do SBC não produz necessariamente um bom resultado, o
problema neste caso pode estar na desconfiança ou intolerância ao sistema, por parte do usuário.
Os SBC’s são um poderoso instrumento para o manuseio de grandes quantidades de
informação e conhecimento, características de sistemas complexos. Em função disso, os SBC’s têm
sido vistos como uma possível solução para o problema de redução do risco e aumento da
confiabilidade durante o projeto, desenvolvimento e operação de sistemas, em razão do aumento da
funcionalidade e performance proporcionadas. Estes aspectos são ratificados pelas seguintes
características relacionadas aos SBC’s (HOLLNAGEL, 1989):
• Aumentam o poder de raciocínio humano, em termos de complexidade e amplidão,
auxiliando o usuário em situações de pressão e estresse;
• Aumentam a disponibilidade e a permanência do conhecimento, evitando perdas com
ausências ou indisponibilidades do EH e reduzindo custos;
• Podem ajudar a reduzir a complexidade aparente do sistema através de interfaces amigáveis
e explicação do raciocínio, podendo ser utilizado como tutor inteligente.
• Não são sensíveis a desvios de atenção ou esquecimentos, resultando, quando requisitado,
em ações mais rápidas, completas, consistentes e imparciais;
• Em geral são mais eficientes que os EH no tratamento de incertezas e incompletudes do
domínio, podendo incorporar múltiplas especialidades.
Paradoxalmente, apesar da alta confiabilidade dos SBC e de todas as vantagens citadas
acima, os SBC’s não representam uma solução universal para os problemas de análise, redução de
riscos e ferramenta para aumento da confiabilidade de sistemas. O uso indiscriminado dos SBC’s
pode representar uma armadilha para o usuário desatento às limitações do SBC e em especial da
base de conhecimento. Entre as principais limitações dos SBC’s tem-se (HOLLNAGEL, 1989):
251
• Dificuldade de mapear conhecimento de senso comum, também chamado por alguns autores
de conhecimento genérico;
• As respostas podem não estar sempre corretas. Existe também a possibilidade de que uma
consideração mal feita se propague por todo o processo, gerando conclusões erradas;
• As técnicas de aprendizado de máquina ainda são limitadas, o que exige em muitos casos a
presença do EC para aquisição e representação de novas porções de conhecimento além da
manutenção do SBC;
• Os SBC’s não possuem a criatividade inerente aos EH’s na resolução de situações anormais
e não modeladas na base de conhecimento.
Além dos aspectos citados acima, a confiabilidade dos SBC’s é sensivelmente afetada pelo
processo de aquisição e representação do conhecimento.
B.8 FUZZYCLIPS COMO FERRAMENTA PARA DESENVOLVIMENTO DE SBC-
FUZZY
Trabalhos envolvendo SBC-
Fuzzy
têm sido objeto de amplo estudo e interesse
(LIEBOWITZ e WILCOX, 1997). Liebowitz (1988) destaca a tendência da utilização da teoria dos
conjuntos
Fuzzy
em SBC’s, principalmente em países como o Japão. Na Alemanha, as indústrias
pesadas estão usando amplamente SBC-
Fuzzy
e obtendo excelentes resultados.
A análise da
shell
FuzzyCLIPS
(Fuzzy C Language Integrated Production Systems)
foi
motivada devido ao fato de ser uma ferramenta pouco explorada no mercado e apresentar algumas
facilidades na modelagem do raciocínio aproximado. Os principais benefícios derivados do uso de
modelos
Fuzzy
em SBC’s são:
• A capacidade de modelar problemas altamente complexos;
• Melhoria da modelagem cognitiva dos SBC’s;
• Habilidade de modelar sistemas envolvendo vários especialistas;
• Redução da complexidade do modelo;
• Melhoria da capacidade de manipulação da "incerteza" e da "possibilidade" (COX, 1994).
O FuzzyCLIPS é uma
Shell
para desenvolvimento de SBC’c baseados em Lógica
Fuzzy
. É
uma versão estendida do CLIPS 6.02
(software
desenvolvido
pelo Johnson Space Center —
NASA,
para desenvolvimento de Sistemas Especialistas) e foi implementado pelo Laboratório de Sistemas
de Conhecimento do
National Research Council,
no Canadá, para a representação e manipulação de
fatos e regras
Fuzzy
. O FuzzyCLIPS modela o raciocínio exato,
Fuzzy
, e combinado, permitindo
que termos
Fuzzy
e normais (
crisp
) sejam misturados livremente nas regras e fatos de um Sistema
Especialista. A sua base de conhecimento está dividida em base de regras e base de fatos. As regras
e fatos ficam armazenados em módulos independentes a fim de facilitar a manutenção do sistema.
A seguir são descritas as principais construções internas do FuzzyCLIPS
,
a forma de avaliação
de regras, fator de certeza, métodos de desfuzzyficação e representação dos conjuntos
Fuzzy
. Apresenta-
252
se, ainda, as principais etapas de desenvolvimento de SBC’s no FuzzyCLIPS e as limitações encontradas
na linguagem. As principais construções internas no FuzzyCLIPS são (FERNANDES, 2001):
Defglobal
→
Define e inicializa as variáveis globais do sistema.
Deftemplate
→
Define as variáveis linguísticas e seus respectivos conjuntos
Fuzzy
.
Deffunction
→
Define as funções criadas pelo usuário.
Defrule
→
Define as regras que são usadas pelo sistema.
Deffacts
→
Define os fatos que inicializarão o sistema.
A avaliação das regras no FuzzyCLIPS depende de vários fatores. Entre estes fatores
destaca-se: as variáveis
Fuzzy
são encontradas ou não no antecedente ou consequente da regra; se
uma regra contém múltiplos antecedentes ou consequentes; se um fato
Fuzzy
sendo declarado, tem a
mesma variável
Fuzzy
que um fato
Fuzzy
já existente. Assim, o FuzzyCLIPS trabalha com dois
tipos de regras: simples e compostas. A forma de avaliação das regras é realizada conforme descrito
na Tabela B.3 (FERNANDES, 2001):
Tabela B.3 – Tipos de Regras no FuzzyCLIPS.
Fonte: adaptado de FERNANDES, 2001.
Tipos de Regras Antecedente Consequente Comentário
Simples
Crisp Crisp
ou
Fuzzy
Apresenta antecedente
Crisp
, independente do
consequente.
Simples
Fuzzy Crisp
Apresenta antecedente
Fuzzy
e consequente
Crisp
.
Simples
Fuzzy Fuzzy
Antecedentes e consequentes são
Fuzzy
.
Compostas
Fuzzy
e
Crisp Fuzzy
Antecedente possui objetos
Crisp
e
Fuzzy
, porém,
o consequente é
Fuzzy
.
Compostas
Fuzzy
e
Crisp Crisp
Antecedente possui objetos
Crisp
e
Fuzzy
, porém,
o consequente é
Crisp
.
Compostas
Fuzzy
e
Crisp Fuzzy
e
Crisp
Antecedente possui objetos
Crisp
e
Fuzzy
, porém,
o consequente é
Fuzzy
e
Crisp
.
No FuzzyCLIPS é possível estabelecer um valor limiar para o fator de certeza tal que uma
regra será disparada somente se o seu valor de fator de certeza calculado é maior ou igual ao valor
do limiar. Esta característica pode ser útil na prevenção de um encadeamento de regras com certeza
muito baixa e pouca contribuição lógica a partir do disparo, aumentando a velocidade do tempo de
execução. O padrão é não ter limiar do fator de certeza, e as regras serem disparadas como usuais. O
cálculo do Fator de Certeza (FC) é: FCregra x min(FC
1
,...,FC
n
); onde FCregra é o FC para a regra e
CFi são os FC’s para os fatos que unificam os n padrões no lado esquerdo de uma regra.
No FuzzyCLIPS, o usuário tem a opção de escolher entre COG (Centro de Gravidade) e
MOM (Média dos Máximos) para desfuzzyficar um conjunto
Fuzzy
. Para isto, basta usar uma das
duas funções descritas à seguir.
(moment-defuzzify ? variável)
; centro de gravidade
(maximum-defuzzify ? variável)
; média dos máximos
Os conjuntos
Fuzzy
podem ser representados no FuzzyCLIPS através de quatro formas
diferentes: notação
Singleton,
e números
Fuzzy
do tipo S, Z e P.
253
(deftemplate universe 0 10 (
;declaração de variável linguística e limites do universo de discurso
(ruim ( 0 0) ( 0 1) ( 1 1) ( 2 0))
;termo primário “ruim” descrito na notação de Singleton
(baixa ( 1 0) ( 2 1) ( 3 1) ( 4 0))
;termo primário “baixa” descrito na notação de Singleton
(boa ( 3 0) ( 4 1) ( 6 1) ( 7 0))
;termo primário “boa” descrito na notação de Singleton
(alta ( 6 0) ( 7 1) ( 8 1) ( 9 0))
;termo primário “alta” descrito na notação de Singleton
(otima ( 8 0) ( 9 1) ( 10 1) ( 10 0))
;termo primário “otima” descrito na notação de Singleton
))
;fim do
deftemplate Fuzzy
“
universe
”
Frequentemente é útil descrever uma função de pertinência usando um conjunto
Fuzzy
de
uma das funções S, P ou Z. Os parâmetros destas funções podem ser escolhidos, dependendo da
aplicação. Os nomes usados sugerem o formato das funções, mostradas no exemplo abaixo:
(deftemplate Tx “temperatura água” 5 65 Celsius
((frio (z 10 26))
(ok (PI 2 36))
(quente (s 37 60))
Para construir um SBC no FuzzyCLIPS, algumas etapas devem ser desenvolvidas:
Definição das Variáveis Globais: As variáveis que serão utilizadas por várias funções e módulos no
sistema, bem como as variáveis manipuladas pelas funções de interface
,
devem ser definidas e
inicializadas no início do programa através da construção
defglobal.
Definição das Funções Criadas pelo Usuário: Todas as funções criadas pelo usuário ou EC para
interface
com usuário, cálculos, etc..., são definidas através da construção
deffunction
logo após a
definição das variáveis globais.
Definição dos Conjuntos
Fuzzy
Utilizados pelo Sistema: Todas as variáveis linguísticas utilizadas
no sistema tem seus conjuntos
Fuzzy
determinados através da construção
deftemplate.
Aqui também
define-se o universo de discurso das variáveis linguísticas.
Regra de
Startup:
Este passo consiste em determinar a regra que iniciará a execução do programa.
Esta regra é diferenciada das outras pela ausência de antecedente. Dentro do consequente desta regra
deve constar os módulos onde se encontram as regras e as chamadas das funções a serem usadas
durante a execução do sistema.
(defrule startup = >
(load “teste1.clp”)
….)
Definição das Regras: As regras a serem utilizadas pelo sistema devem ser definidas através da
construção
defrule.
Estas regras podem ser definidas no corpo do programa principal (se forem em
pequeno número), mas geralmente são definidas em módulos separados, os quais são carregados
pela regra de
startup.
O FuzzyCLIPS não apresenta uma interface amigável. Para contornar esta situação, os
programadores podem contar com a ferramenta o wxCLIPS, desenvolvida pelo AIAI –
Artificial
Intelligence Applications Institute
, da Universidade de Edinburgh, Reino Unido, em 1994. O
desenvolvimento de tal ferramenta foi motivado pela necessidade de suprir uma deficiência dos
programas feitos em CLIPS ou FuzzyCLIPS, a interface do usuário. O wxCLIPS pode ser
considerado em dois aspectos: uma biblioteca de funções CLIPS/FuzzyCLIPS, para acessar as
254
facilidades do wxWindows; e um ambiente de desenvolvimento de aplicações wxWindows, usando
as funções CLIPS/FuzzyCLlPS. A biblioteca pode ser usada por qualquer programa C++; wxCLIPS
é então, uma simples interface
de desenvolvimento para Windows
que usa a biblioteca de funções
CLIPS/FuzzyCLIPS. O wxCLIPS possui um ambiente de desenvolvimento básico, que consiste em
uma janela com menus
,
uma janela para entrada de dados e uma janela para os textos de saída.
Durante a compilação dos programas, as mensagens de erro são escritas na janela de saída. Usando
o wxCLIPS, pode-se criar
frames,
cada um com seus próprios menus
.
Dentro de um
frame
pode-se
criar uma ou mais subjanelas. Estas sub-janelas podem ser
panels, canvases
e subjanelas de texto.
Panels
são usados para conter os
panel items,
tais como botões, itens para entrada de texto,
box
de
listas, etc... O
box
de diálogo é uma forma especial de
panel,
que contem seu próprio
frame,
sendo
assim, ao invés de criar um
frame
e um
panel,
basta criar um
box
de diálogo e inserir os
panel items
necessários.
Canvases
são usados para desenhar figuras com qualquer formato. As subjanelas de
texto são usadas para exibir arquivos texto ou editar os programas. Não há necessidade de criar um
box
de diálogo ou manipular todos os botões, e outros eventos manualmente. Há um certo número
de funções que desempenham todas estas tarefas, tais como: get-text-from-user, message-box, get-
choice, fíle-selector, etc... Tais funções bloqueiam o fluxo de execução do programa no ponto onde
foram chamadas, até que o usuário responda às solicitações. A Figura B.10 exibe algumas das
opções de interface
que o wxCLIPS fornece.
Figura B.10 – Exemplos de Interfaces do wxCLIPS.
Fonte: adaptado de FERNANDES, 2001.
Há uma única função obrigatória a todos os programas que são executados no wxCLIPS:
app-on-init.
Se uma aplicação define uma função com este nome, a interface
wxCLIPS do usuário
pode inicializar a aplicação e estabelecer todas as variáveis de ambiente, arquivos e funções que
serão usadas no decorrer da execução.
255
APÊNDICE C
QUESTIONÁRIOS
Apresenta os Questionários utilizados para Aquisição de Conhecimento e
Validação do DALF-MCC
256
257
UFSC - UNIVERSIDADE FEDERAL DE SANTA CATARINA
NÚCLEO DE DESENVOLVIMENTO INTEGRADO DE PRODUTOS
DEPARTAMENTO DE ENGENHARIA MECÂNICA
Questionário para Aquisição de Conhecimento
As respostas às questões abaixo servirão para nortear o desenvolvimento de um Sistema
Baseado em Conhecimento (SBC)
Fuzzy
para auxiliar a implantação e a auditoria da MCC,
ponderando as características e objetivos da empresa, as necessidades da planta e os fatores críticos
para o sucesso de um programa de MCC. O objetivo é minimizar os riscos de insucesso da MCC ao
longo de todo o seu ciclo de vida. Para os problemas apresentados pela empresa/sistema o SBC
Fuzzy
, sempre que possível, apontará soluções que contornem tais problemas, tentando desta forma
minimizar os fatores de insucesso. As questões abaixo foram elaboradas com base na Figura abaixo.
Procedimentos de Referência para Implantação da MCC.
Rigoni: Existe uma Etapa de Pré-Implantação onde é verificada e ratificada a Adequação da MCC
para aquela determinada empresa/sistema?
Iony: A metodologia MCC em princípio aplica-se a qualquer empresa/sistema, variando apenas o
nível e estratégia de implantação. O nível e estratégia de implantação são definidos nas etapas de
identificação das instalações, sistemas e funções que serão avaliados. Estes itens podem variar desde
equipamentos isolados com seus sistemas e funções internas, até empresas inteiras, com seus macro
sistemas e macro funções.
258
UFSC - UNIVERSIDADE FEDERAL DE SANTA CATARINA
NÚCLEO DE DESENVOLVIMENTO INTEGRADO DE PRODUTOS
DEPARTAMENTO DE ENGENHARIA MECÂNICA
Rigoni: Para evitar problemas ao longo de todo o ciclo de vida da MCC, quais as
características/atributos que a empresa/sistema deveria ter antes de iniciar os procedimentos de
implantação?
Iony: Duas características são necessárias para o sucesso da implantação da MCC: (a) know-how
interno ou contratado para suportar a metodologia; e (b) clara definição prévia dos objetivos e níveis
de aplicação da metodologia.
Rigoni: Quais os procedimentos de preparação para a implantação da MCC que deveriam ser
observados para não causar transtornos para a equipe de implantação? Quais as soluções para
estes problemas? Se for possível e/ou aplicável, como um SBC-
Fuzzy
poderia auxiliar este
processo?
Iony: É indispensável a definição, por parte da gestão da empresa, de um patrocinador interno à
organização com poder de mobilização dos recursos necessários. Para isto, é necessário a aprovação,
pela organização, de um plano de implantação da MCC, constando no mínimo da alocação de
recursos, orçamentação, objetivos, metas, cronograma, etc. Um sistema Fuzzy poderia ser estruturado
para sugerir este plano, através de questões objetivas dirigidas ao decisor da empresa.
Rigoni: Quais os problemas que comumente aparecem durante a Etapa de Seleção do Sistema e
Coleta de Informações? Quais as soluções para estes problemas? Se for possível e/ou aplicável,
como um SBC-
Fuzzy
poderia auxiliar este processo?
Iony: O erro grave na seleção do sistema e coleta de informações seria selecionar uma instalação ou
sistema para o qual a equipe não tem conhecimento ou disponibilidade de recurso para conduzir a
análise. A análise criteriosa e o dimensionamento prévio dos recursos garantirão o sucesso desta
etapa. Um sistema Fuzzy que contivesse regras de identificação e dimensionamento de recursos
montadas por especialistas em MCC poderia ajudar a evitar estes problemas.
Rigoni: Quais os problemas que comumente aparecem durante a Etapa de Análise dos Modos de
Falha seus Efeitos e sua Criticidade (FMECA)? Quais as soluções para estes problemas? Se for
possível e/ou aplicável, como um SBC-
Fuzzy
poderia auxiliar este processo?
Iony: Um erro comum na etapa de FMEA é o aprofundamento da análise de modos e causas de falha
além do necessário para a definição de uma política de manutenção. É comum o especialista no
processo desejar identificar a causa profunda do modo de falha, na tentativa de mudar o projeto para
259
UFSC - UNIVERSIDADE FEDERAL DE SANTA CATARINA
NÚCLEO DE DESENVOLVIMENTO INTEGRADO DE PRODUTOS
DEPARTAMENTO DE ENGENHARIA MECÂNICA
eliminá-la definitivamente. Isto muda o foco do FMEA da manutenção para o projeto, desvirtuando
os objetivos da análise. Um sistema Fuzzy que contivesse regras para delimitar o nível de
detalhamento da FMEA, montadas por especialistas em MCC, poderia ajudar a evitar estes
problemas.
Rigoni: Quais os problemas que comumente aparecem durante a Etapa de Seleção e
Caracterização das Funções Significantes? Quais as soluções para estes problemas? Se for
possível e/ou aplicável, como um SBC-
Fuzzy
poderia auxiliar este processo?
Iony: O erro mais comum na etapa de Etapa de Seleção e Caracterização das Funções Significantes é
o esquecimento da função do usuário na escolha da função. A este cabe a decisão sobre a
significância da função, e não ao mantenedor. É comum o especialista no processo julgar que pode
identificar a função significante de um sistema sem ouvir a opinião do usuário ou proprietário. Um
sistema Fuzzy que contivesse questões específicas para o usuário sobre a significância das funções
poderia ajudar a evitar estes problemas.
Rigoni: Quais os problemas que comumente aparecem durante a Etapa de Seleção das Tarefas de
Manutenção Aplicáveis e Efetivas? Quais as soluções para estes problemas? Se for possível e/ou
aplicável, como um SBC-
Fuzzy
poderia auxiliar este processo?
Iony: Um erro comum na etapa de Etapa de Seleção das Tarefas de Manutenção Aplicáveis e
Efetivas é escolha de uma atividade motivada pela disponibilidade de competência e recursos na
empresa para sua execução, sem considerar a necessidade ou justificativa para prevenir ou remediar
um modo de falha. A associação correta do mecanismo de falha com as potencialidades e
custo/benefício da atividade recomendada deve guiar o processo de escolha. Um sistema Fuzzy que
contivesse questões específicas para o usuário sobre a aplicabilidade e efetividade de cada atividade
sugerida poderia ajudar a evitar estes problemas.
Rigoni: Quais os problemas que comumente aparecem durante a Etapa de Definição dos
Intervalos Iniciais e Agrupamento das Tarefas de Manutenção? Quais as soluções para estes
problemas? Se for possível e/ou aplicável, como um SBC-
Fuzzy
poderia auxiliar este processo?
Iony: Na Etapa de Definição dos Intervalos Iniciais e Agrupamento das Tarefas de Manutenção é
possível que a empresa não possua dados ou know-how interno para escolher uma periodicidade
ótima de forma matemática. Também é comum a ausência de um objetivo quantificável e claro
do que será otimizado na manutenção. Na ausência de dados, pode-se implantar um processo de
260
UFSC - UNIVERSIDADE FEDERAL DE SANTA CATARINA
NÚCLEO DE DESENVOLVIMENTO INTEGRADO DE PRODUTOS
DEPARTAMENTO DE ENGENHARIA MECÂNICA
exploração de idade, associado a um plano de coleta de informações sobre cada manutenção e modo
de falha, e a definição precisa do objetivo da manutenção. Um sistema Fuzzy que contivesse métodos
de otimização lingüística, com parâmetros difusos definidos por especialistas, poderia sugerir
intervalos ótimos (no sentido difuso) de manutenção e evitar estes problemas.
Rigoni: Quais os problemas que comumente aparecem durante a Etapa de Redação do Manual e
Implementação da MCC? Quais as soluções para estes problemas? Se for possível e/ou aplicável,
como um SBC-
Fuzzy
poderia auxiliar este processo?
Iony: Na Etapa de Redação do Manual e Implementação da MCC é possível que a equipe
responsável pela análise já tenha se dispersado, dificultando a elaboração do Manual. Um
planejamento e gestão adequados do processo é a solução para este problema. É recomendável o uso
de softwares especializados de MCC que publiquem automaticamente o manual depois de concluída a
etapa de análise e decisão, e automaticamente integre as decisões tomadas ao sistema de gestão da
manutenção (CMMS). Um sistema Fuzzy que contivesse regras de estruturação do manual, com
parâmetros definidos por especialistas, poderia ajudar sugerir a estruturar o manual e evitar estes
problemas.
Rigoni: Quais os problemas que comumente aparecem durante a Etapa de Acompanhamento e
Realimentação do Programa de MCC? Quais as soluções para estes problemas? Se for possível
e/ou aplicável, como um SBC-
Fuzzy
poderia auxiliar este processo?
Iony: Na Etapa de Acompanhamento e Realimentação do Programa de MCC é possível que a
empresa não sistematize como rotina da manutenção, a re-análise de cada modo de falha não incluído
na MCC. É recomendável o uso de softwares especializados de MCC que verifiquem
automaticamente se cada modo de falha reportado na rotina da manutenção foi avaliado na MCC,
reprogramando sua análise. Um sistema Fuzzy integrado ao software de MCC e ao de gestão da
manutenção (CMMS), com regras de decisão sobre aprovação de cada modo de falha reportado, ou
sua programação para análise pela MCC, poderia ajudar a evitar estes problemas.
261
UFSC - UNIVERSIDADE FEDERAL DE SANTA CATARINA
NÚCLEO DE DESENVOLVIMENTO INTEGRADO DE PRODUTOS
DEPARTAMENTO DE ENGENHARIA MECÂNICA
Questionário para Validação do DALF-MCC
METODOLOGIA PARA IMPLANTAÇÃO DA MANUTENÇÃO CENTRADA NA
CONFIABILIDADE: uma abordagem fundamentada em Sistemas Baseados em Conhecimento e
Lógica
Fuzzy
.
O objetivo deste questionário é validar a ferramenta computacional denominada DALF-MCC
(Diagnóstico Auxiliado por Lógica
Fuzzy
para a Manutenção Centrada na Confiabilidade), a qual faz parte da
metodologia proposta para avaliação dos pré-requisitos e auditoria das etapas de implantação da MCC.
Responda aos questionamentos marcando a alternativa que melhor expresse sua opinião sobre o
quesito a ser avaliado e, se necessário, faça os comentários que julgar procedentes para validar a ferramenta
proposta (DALF-MCC).
Para facilitar a análise, o presente questionário de validação foi dividido em 2 partes, a saber: i) análise
da interface com o usuário e, ii) análise do processo de inferência, o qual inclui os questionamentos e respostas
para o usuário, além dos aspectos gerais inerentes a aplicação e concepção do DALF-MCC.
Análise da Interface:
1. A Tela Início DALF-MCC esclarece adequadamente os objetivos do software?
Sim Não Parcialmente
Comentários:
2. A Tela Empresa do DALF-MCC, que serve para cadastramento da empresa, é clara, não
suscitando dúvidas sobre seu preenchimento?
Sim Não Parcialmente
Comentários:
3. A Tela Parametrização
Fuzzy
do DALF-MCC é clara e possibilita a concepção de conjuntos
Fuzzy
adequados ao processo de inferência que se propõe estabelecer?
Sim Não Parcialmente
Comentários:
262
UFSC - UNIVERSIDADE FEDERAL DE SANTA CATARINA
NÚCLEO DE DESENVOLVIMENTO INTEGRADO DE PRODUTOS
DEPARTAMENTO DE ENGENHARIA MECÂNICA
4. A Tela de Análise dos Pré-Requisitos e Auditoria do DALF-MCC possui interface amigável e intuitiva?
Sim Não Parcialmente
Comentários:
5. A Tela de Resultados e Conclusões do DALF-MCC apresenta os resultados da Análise de forma
clara, objetiva e organizada?
Sim Não Parcialmente
Comentários:
6. A Tela Apoio a Implementação do DALF-MCC é clara e não levanta dúvidas, sobre como acessar,
ou a utilidade das ferramentas apresentadas, para auxilio à implementação da MCC?
Sim Não Parcialmente
Comentários:
Análise do Processo de Inferência:
1. O DALF-MCC abrange todas as etapas do processo de implantação da MCC?
Sim Não Parcialmente
Comentários:
2. Os Critérios e seus Quesitos avaliados em cada etapa, para análise dos pré-requisitos, refletem as
reais necessidades de um processo de implementação da MCC?
Sim Não Parcialmente
Comentários:
3. Os Critérios e seus Quesitos avaliados em cada etapa, para sua auditoria, avaliam de forma correta a
execução da etapa e refletem as reais exigências de um processo de auditoria da MCC?
Sim Não Parcialmente
Comentários:
263
UFSC - UNIVERSIDADE FEDERAL DE SANTA CATARINA
NÚCLEO DE DESENVOLVIMENTO INTEGRADO DE PRODUTOS
DEPARTAMENTO DE ENGENHARIA MECÂNICA
4. O relatório final da análise apresenta de forma clara, objetiva, organizada e correta os resultados e
conclusões do processo de inferência, apontando os fatores críticos para o sucesso do programa de
MCC, tanto para o caso da avaliação dos pré-requisitos quanto para o caso da auditoria?
Sim Não Parcialmente
Comentários:
5. As informações presentes no relatório final da análise são suficientes para nortear o processo de melhoria
interna da empresa/sistema, com o objetivo de aumentar sua aderência às necessidades da MCC?
Sim Não Parcialmente
Comentários:
6. O texto dos questionamentos e dos relatórios é claro, adequado e de fácil entendimento?
Sim Não Parcialmente
Comentários:
7. O texto do arquivo de ajuda (
help
) é claro, de fácil entendimento e contribui satisfatoriamente para
a resolução das dúvidas?
Sim Não Parcialmente
Comentários:
Aspectos Gerais:
1. O DALF-MCC avalia a empresa/sistema segundo uma abordagem holística, ou seja, envolvendo
os aspectos técnicos e gerenciais que afetam a implantação da MCC?
Sim Não Parcialmente
Comentários:
264
UFSC - UNIVERSIDADE FEDERAL DE SANTA CATARINA
NÚCLEO DE DESENVOLVIMENTO INTEGRADO DE PRODUTOS
DEPARTAMENTO DE ENGENHARIA MECÂNICA
2. As ferramentas propostas para a fase de implementação, sugeridas para as etapas 3, 4 e 5, são
adequadas e podem auxiliar o processo de implementação das referidas etapas?
Sim Não Parcialmente
Comentários:
3. A aplicação do DALF-MCC, na fase anterior (análise de pré-requisitos) e posterior (auditoria) a
implementação de cada etapa, pode fomentar o diálogo entre a equipe de implementação da MCC, na
perspectiva de mudar sua atitude diante das práticas utilizadas?
Sim Não Parcialmente
Comentários:
4. Que procedimentos você sugere para facilitar a aplicação do DALF-MCC, ao longo do processo
de implantação da MCC.
Comentários:
5. Em sua opinião, o DALF-MCC contribui com algo novo e que pode de fato auxiliar o processo de
implantação da MCC?
Sim Não Parcialmente
Comentários:
Para comentários adicionais utilize o verso ou folhas suplementares.
OBRIGADO PELA SUA COLABORAÇÃO
265
APÊNDICE D
INSTALAÇÃO E EXECUÇÃO DO DALF-MCC
Apresenta os procedimentos para Instalação e Execução do DALF-MCC
266
267
Instalação do DALF-MCC
Diagnóstico Auxiliado por Lógica
Fuzzy
para a Manutenção Centrada na Confiabilidade
1) Crie um Diretório (Pasta) com o nome DALF no drive C:\ .
2) Faça o
download
do programa DALF-MCC, disponível em:
www.rigoni.com.br/DALF_MCC.rar
salvando, o mesmo, no Diretório (Pasta) criado em (1).
3) Descompacte o programa DALF-MCC, salvo conforme item (2), no Diretório (Pasta) criado
conforme item (1).
Click
com o Botão Direito do Mouse sobre o Arquivo DALF_MCC.rar e
escolha a opção
Extract Here
.
4) Após descompactar o Arquivo DALF_MCC.rar o Diretório (Pasta) C:\DALF assume a
configuração abaixo:
5) Transfira o conteúdo do Diretório (Pasta) DALF_MCC para C:\DALF criado em (1). Após
concluir esta operação
delete
o Diretório (Pasta) DALF_MCC. Nesta etapa do processo o
Diretório (Pasta) C:\DALF assume a configuração abaixo:
268
6) Descompacte o conteúdo de C:\DALF\DALF_Arquivos.rar dentro do mesmo Diretório
(Pasta) em que se encontra ou seja C:\DALF.
Click
com o Botão Direito do Mouse sobre o
Arquivo DALF_MCC.rar e escolha a opção
Extract Here
.
7) Nesta etapa do processo o Diretório (Pasta) C:\DALF assume a configuração abaixo:
8) Execute o Arquivo setup.exe presente no Diretório (Pasta) C:\DALF\Instalador
9) Na Tela que será exibida, conforme abaixo,
click
na Opção OK.
269
10) Na Tela seguinte escolha a Opção
Change Directory
para alterar o Diretório (Pasta) de destino
da instalação
11) Na tela seguinte escolha o Diretório (Pasta) C:\DALF criado em (1)
12) Na Tela seguinte
click
no Botão de Instalação, conforme abaixo e siga as instruções do
instalador (tipicamente não é necessária nenhuma intervenção, pois o processo é automático):
13) Concluído o processo de instalação
click
no Botão OK, conforme abaixo:
Click aqui!
Click aqui!
Escolha aqui o
Diretório/Pasta DALF
criado em (1) e
Click
em OK!
270
Execução do DALF-MCC
Diagnóstico Auxiliado por Lógica
Fuzzy
para a Manutenção Centrada na Confiabilidade
1) Execute o Arquivo: DALF-MCC.exe, o qual se encontra no Diretório (Pasta) C:\DALF criado
em (1)
2) Na Tela de Parametrização
Fuzzy
configure os Conjuntos
Fuzzy
de acordo com sua
preferência e
Click
em Atualizar. Caso os Conjuntos já estejam de seu agrado, apenas
Click
em Atualizar.
3) Para proceder à ponderação dos Pré-Requisitos ou Auditoria escolha no Menu correspondente
a Etapa que queira avaliar. Estando na Etapa desejada avalie todos os seus Quesitos.
Concluída a ponderação dos Quesitos,
Click
no Botão Avaliação do Critério. Proceda da
mesma forma para todos os Critérios da Etapa selecionada. Concluído a avaliação dos
Critérios
Click
no Botão Avalia Etapa “n” onde “n” é o Número da Etapa escolhida.
Configurar os Conjuntos e Atualizar
Para acessar esta Tela
Click
Aqui (Parametrização
Fuzzy
)
Para acessar esta Tela
Click
Aqui.
Cada uma destas Abas é um Critério. Todos devem
ser Avaliados para se ter a Avaliação da Etapa.
Todos os Quesitos de cada Critério devem ser Avaliados
p
ara se ter a Avalia
ç
ão do res
p
ectivo Critério.
Após Avaliar todos os Critérios.
Aqui se Avalia a Etapa.
Após Avaliar todos os Quesitos.
Aqui se Avalia o Critério.
271
4) Após Avaliar a Etapa o Relatório da análise pode ser acessado através do no Menu Resultados
e Conclusões. Obs.: Somente as Etapas Avaliadas terão seu respectivo Relatório disponível.
5) As ferramentas complementares de Apoio a Implementação da MCC podem ser acessadas
através do Menu Apoio a Implementação.
Senhas:
OpenFMECA: Login = aluno Senha = aluno
FMECA-Delphi: Login = rigoni Senha = rigoni
Obs.: Mais detalhes da Execução do DALF-MCC e suas Ferramentas Complementares estão
explicitados nos Capítulos 5, 6, 7 e Apêndice G deste trabalho.
Para acessar o Relatório
Click
Aqui (Resultados e Conclusões).
O Relatório só estará disponível após a avaliação da respectiva Etapa.
Para acessar as ferramentas de Apoio a Implementação da MCC
Click
Aqui (
Apoio a Implementação).
Algumas das ferramentas exigem conexão com a Internet e Senha.
272
273
APÊNDICE E
PUBLICAÇÕES
Apresenta as principais Publicação inerentes a este Trabalho
274
275
APÊNDICE E
PUBLICAÇÕES
E.1 CONGRESSOS E REVISTAS
RIGONI, Emerson; SILVA, Jonny Carlos da. Sistema Especialista de Apoio a Manutenção de
Sistemas Automatizados. 2º Congresso Mundial de Manutenção e 19º Congresso Brasileiro de
Manutenção organização ABRAMAN, 2004.
RIGONI, Emerson; SILVA, Jonny Carlos da. Hybrid Knowledege Based System: A Decision
Support Proposal for Natural Gas Compressor Station Maintenance and Operation. 18th
International Congress of Mechanical Engineering, COBEM, 2005.
RIGONI, Emerson; DIAS, Acires; SILVA, Jonny Carlos da. Knowledge Based System for
Management of Critical Factors Related to Reliability Centered Maintenance. 19th
International Congress of Mechanical Engineering. COBEM, 2007.
RIGONI, Emerson; DIAS, Acires; SILVA, Jonny Carlos da. Sistema Baseado em
Conhecimento para Gerenciamento dos Fatores Críticos da Manutenção Centrada na
Confiabilidade. XX Congresso Pan-Americano de Engenharia Naval, Transporte Marítimo e
Engenharia Portuária, COPINAVAL, 2007.
RIGONI, Emerson; DIAS, Acires; CALIL, Luis Fernando P.; ANDRADE, Bernardo L.R.;
SAKURADA, Eduardo Yuji; KAGUEIAMA, Heitor Azuma. Proposta de uma Abordagem
para Elaboração de FMECA Virtual. XX Congresso Pan-Americano de Engenharia Naval,
Transporte Marítimo e Engenharia Portuária, COPINAVAL, 2007.
RIGONI, Emerson. Sistema Baseado em Conhecimento para Implantação da Manutenção
Centrada na Confiabilidade.
15º Seminário Brasileiro de Planejamento e Informatização da
Manutenção e 14º Seminário Brasileiro de Manutenção Preditiva e Inspeção de Equipamentos,
Organização Excelência Consultoria e Treinamento, 2008.
RIGONI, Emerson. A Gestão do Conhecimento para Implantação da Manutenção Centrada
na Confiabilidade. Revista Indústria em Foco, 2008.
RIGONI, Emerson; Dias, Acires; Silva, Jonny Carlos da. Sistema Baseado em Conhecimento
para Implantação da Manutenção Centrada na Confiabilidade. 19º Congresso Brasileiro de
Manutenção Organização ABRAMAN, 2008.
RIGONI, Emerson; DIAS, Acires; SILVA, Jonny Carlos da. Implantação da Manutenção
Centrada na Confiabilidade com Auxílio de um Sistema Especialista Fuzzy. V Congresso
Nacional de Engenharia Mecânica – CONEM, 2008.
E.2 ORIENTAÇÃO DE TRABALHO DE CONCLUSÃO DE CURSO
GOBER, Cristiano José; SILVA, Luís Carlos Santos da; SANTOS, Rogério José dos. Aplicação de
Ferramentas Computacionais para Definição de uma Metodologia de Gestão da Manutenção.
2008, 132f. Trabalho de Conclusão de Curso – Curso Superior de Tecnologia em Gestão Comercial
Elétrica, Universidade Tecnológica Federal do Paraná, Curitiba, 2008.
276
277
APÊNDICE F
QUESITOS E CRITÉRIOS DO SBC-
FUZZY
DESENVOLVIDO
Apresenta os Quesitos e Critérios que compõem o Processo de Inferência
do DALF-MCC
278
279
APÊNDICE F
QUESITOS E CRITÉRIOS DO SBC-
FUZZY
DESENVOLVIDO
F.1 ANÁLISE DOS PRÉ-REQUISITOS DA MCC
Os próximos itens detalham os Quesitos (Q
n
), a serem ponderados pelo usuário, para
avaliação de cada Critério (C
n
). A desfuzzyficação dos conjuntos
Fuzzy
formados pela agregação
dos critérios avaliados resulta na avaliação da Etapa “n”. Tais Critérios e seus respectivos
Quesitos se referem a Análise dos Pré-Requisitos.
F.1.1 Pré-Requisitos_Etapa 0
Critério 1 (C1) – Disponibilidade da Informação/Recursos:
Q1
→
Todas as Entradas, Controles e Mecanismos da Etapa 0 (Adequação da MCC), do
procedimento de referência para implantação da MCC, estão disponíveis.
Q2
→
Existe uma documentação consistente das ações de manutenção.
Q3
→
Os sistemas candidatos a implantação da MCC possuem uma documentação técnic
a
adequada.
Q4
→
O planejamento estratégico da empresa, com relação à manutenção, está documentado de
forma auditável.
Critério 2 (C2) – Condição e Desempenho Atual da Manutenção:
Q1
→
O percentual de Manutenção Preditiva (baseada na condição) é maior do que o de
Manutenção Preventiva (baseada no tempo) ou Corretiva.
Q2
→
O desempenho atual da manutenção é satisfatório e homogêneo em todo o sistema fabril,
contando com uma equipe adequadamente preparada para o desempenho de sua função.
Q3
→
Historicamente o número de operadores, no chão de fábrica, é pequeno quando comparado
a
sistemas similares.
Q4
→
Os custos diretos e indiretos devidos à manutenção são altos com o sistema atual de gestão
da manutenção quando comparados a outros sistemas similares.
Critério 3 (C3) – Sistema Computacional de Suporte:
Q1
→
Para auxiliar a implantação do programa de MCC, um sistema computacional de automação
de escritório estará disponível com as seguintes funcionalidades: desenho técnico,
processamento de texto, banco de dados e planilhas eletrônicas.
Q2
→
Existe um sistema de gestão da informação integrado, implantado na empresa, que atende de
forma satisfatória às necessidades do setor/equipe de manutenção.
Q3
→
A gestão da manutenção conta com um sistema computacional adequadamente
dimensionado para o tamanho da empresa e do sistema que se quer implantar a MCC.
Q4
→
O sistema computacional de gestão da manutenção é de uso amigável, toda a equipe possui
280
treinamento adequado para utilizá-lo e sua utilização faz parte da rotina de trabalho d
a
equipe de manutenção.
Q5
→
O sistema computacional de gestão da manutenção permite integração com softwares
específicos de implantação e gestão da MCC. Caso contrário, conta com no mínimo as
seguintes funcionalidades: inclusão de novas tarefas com períodos customizados; controle
estatístico da manutenção; e agrupamento de tarefas de manutenção de forma otimizada.
Critério 4 (C4) – Cultura da Manutenção/Empresa:
Q1
→
O setor e/ou equipe de manutenção atual registra suas ações de forma suficientemente
detalhada para suportar uma análise estatística de tais ações.
Q2
→
A manutenção tem função estratégica dentro da empresa e ocupa um lugar de destaque na
estrutura organizacional.
Q3
→
A equipe e/ou setor de manutenção, em suas diferentes categorias profissionais, são
motivados, cooperativos e conscientes de seu papel estratégico dentro de empresa.
Q4
→
Outras metodologias de gestão da manutenção foram previamente adotadas e/ou estudadas e
culminaram com a adoção da MCC, por ser de custo/benefício mais vantajosa.
Q5
→
O atual programa de manutenção é continuamente atualizado e auditado por pessoal interno
ou externo à empresa ou setor de manutenção.
Critério 5 (C5) – Gerenciamento Estratégico da Manutenção:
Q1
→
Existe um orçamento para viabilizar a implantação da MCC e que supra as seguintes
necessidades: treinamento de pessoal dentro da filosofia da MCC; disponibilidade de
recursos humanos; implantação de ações preditivas; e implementação de sistemas
computacionais de suporte a MCC, caso necessário.
Q2
→
As decisões referentes às estratégias de gestão da manutenção estão em conformidade e te
m
suporte por outros setores da empresa, o que caracteriza o bom relacionamento institucional.
Q3
→
Os níveis gerenciais vêem a manutenção como investimento e não como um custo.
Q4
→
A MCC é visualizada como parte de um processo geral/global de gerenciamento d
a
manutenção, com métodos e técnicas, podendo coexistir outras metodologias de gestão d
a
manutenção em paralelo ou integradas à MCC.
Q5
→
Grande parte da manutenção é terceirizada, entretanto, seus controles, registros e demais
itens de gestão estão a cargo da empresa ou seu representante.
F.1.2 Pré-Requisitos_Etapa 1
Critério 1 (C1) – Disponibilidade da Informação/Recursos:
Q1
→
Todas as Entradas, Controles e Mecanismos da Etapa 1 (Preparação), do procedimento de
referência para implantação da MCC, estão disponíveis.
Q2
→
A etapa anterior foi Auditada com relação ao nível de conformidade com os requisitos do
procedimento de referência.
Obs.: Neste quesito responda com a Nota obtida na Auditoria da Etapa 0 (Adequação d
a
MCC).
Q3
→
Levando em conta o tamanho e a complexidade dos sistemas candidatos à implantação d
a
MCC, o software de apoio à equipe de implementação atende a todas as necessidades – sej
a
ele um software comercial específico para MCC ou, genérico de gestão da manutenção
281
aliado a softwares de automação de escritório.
Q4
→
Os itens/componentes dos sistemas candidatos a implantação da MCC possuem um
a
identificação única e inequívoca (etiqueta -
tag
).
Critério 2 (C2) – Formação da Equipe:
Q1
→
A empresa designou um patrocinador interno para auxiliar a implantação da MCC, co
m
poder para mobilização financeira e de pessoal.
Q2
→
A empresa possui internamente e/ou contratará consultores externos com conhecimento
comprovado da metodologia MCC para atuarem como facilitadores do processo de
implementação.
Q3
→
Todos os interessados nos sistemas candidatos à implantação da MCC, incluindo os clientes
internos e externos à empresa, estão disponíveis e dispostos a colaborar com o processo de
implantação.
Q4
→
Os níveis gerenciais estão envolvidos e comprometidos com a equipe de implementação d
a
MCC.
Q5
→
Existe pessoal habilitado, conhecedor da metodologia MCC e com competência equivalente,
para eventuais substituições de membros da equipe de implementação.
Critério 3 (C3) – Planejamento:
Q1
→
A condução do processo de implantação do programa de MCC seguirá uma metodologia de
Gestão de Projetos. Ex.: PMBOK (
Project Management Body of Knowledge
) do PMI
(
Project Management Institute
).
Q2
→
A implantação da MCC faz parte dos objetivos e metas do planejamento estratégico d
a
empresa e por isto terá um status prioritário para os níveis gerenciais além de contar co
m
níveis compatíveis de organização e alocação de responsabilidades, assim como recursos
humanos e financeiros.
Q3
→
A equipe de implementação terá redução de sua carga normal de trabalho para participar do
projeto de implementação da MCC. Isto resultará em disponibilidade tanto para reuniões
programadas quanto para atividades desenvolvidas entre as reuniões, disponibilidade est
a
acordada com a alta gerência.
Critério 4 (C4) – Estratégia de Implementação:
Q1
→
A equipe conhece o contexto operacional, cultural, histórico e político da empresa/sistem
a
para balizar os objetivos e resultados esperados e delinear a estratégia de implementação.
Q2
→
Um projeto piloto de implementação da MCC já foi conduzido pela empresa e seus
resultados práticos e de amadurecimento na metodologia MCC serão utilizados no processo
de implementação.
Q3
→
Existem programas de MCC, similares em contexto e domínio de conhecimento, que
servirão de benchmarking inclusive para auxiliar no dimensionamento de recursos para
a
implementação.
F.1.3 Pré-Requisitos_Etapa 2
Critério 1 (C1) – Disponibilidade da Informação/Recursos:
282
Q1
→
Todas as Entradas, Controles e Mecanismos da Etapa 2 (Seleção do Sistema e Coleta de
Informações), do procedimento de referência para implantação da MCC, estão disponíveis.
Q2
→
A etapa anterior foi Auditada com relação ao nível de conformidade com os requisitos do
procedimento de referência.
Obs.: Neste quesito responda com a Nota obtida na Auditoria da Etapa 1 (Preparação).
Q3
→
Os dados confiabilísticos e da mantenabilidade dos sistemas candidatos à implantação d
a
MCC estão disponíveis e suportam uma análise estatística que permita formular índices par
a
avaliar o desempenho atual e perspectivas futuras para a manutenção.
Q4
→
Com relação aos custos diretos e indiretos dos sistemas candidatos à implantação da MCC,
os seguintes dados estão disponíveis e suportam uma análise quantitativa: custos co
m
manutenção, impacto no processo produtivo devido à indisponibilidade e sua relação co
m
outros sistemas do processo produtivo.
Q5
→
A equipe de implementação domina as questões técnicas, de segurança e ambientais que
afetam ou se vinculam aos sistemas candidatos à implantação da MCC.
Q6
→
A empresa possui, para qualquer um dos sistemas candidatos à implantação da MCC,
recursos financeiros e humanos para: implementar a MCC conforme o procedimento de
referência; aquisição de equipamentos e treinamento para aumento de tarefas preditivas;
monitoramento e acompanhamento estatístico do sistema e das ações de manutenção par
a
realimentação do programa.
Critério 2 (C2) – Estratégia de Seleção:
Q1
→
A equipe de implementação tem uma clara definição do escopo e abrangência do program
a
de MCC. Assim, para os sistemas candidatos, os quais serão submetidos à análise, h
á
conhecimento técnico e gerencial além de recursos financeiros e de pessoal, compatíveis
com o tamanho e a importância dos sistemas candidatos, para suportar as análises requeridas
pela MCC.
Q2
→
Entre os sistemas candidatos à implantação da MCC existe algum que possui similaridade
com outros, pertencentes à empresa ou não, onde a MCC já foi implementada e cujos dados
estão disponíveis para um embasamento inicial da análise.
Q3
→
Todos os sistemas candidatos têm uma relação forte com a disponibilidade do sistem
a
global e economia do processo produtivo e/ou tem implicações de segurança ou meio
ambiente.
Q4
→
A documentação de engenharia disponível dos sistemas candidatos à implantação da MCC
p
ermite uma clara definição das fronteiras dos sistemas e agrupamento de
componentes/subsistema por especialidades técnicas.
Q5
→
A equipe de implantação tem pleno conhecimento do contexto operacional dos sistemas
candidatos à implantação da MCC e sua influência no desempenho, disponibilidade e
economia do processo produtivo, assim como na segurança e meio ambiente.
F.1.4 Pré-Requisitos_Etapa 3
Critério 1 (C1) – Disponibilidade da Informação/Recursos:
Q1
→
Todas as Entradas, Controles e Mecanismos da Etapa 3 (Análise dos Modos de Falha, seus
Efeitos e sua Criticidade – FMECA), do procedimento de referência para implantação d
a
MCC, estão disponíveis.
283
Q2
→
A etapa anterior foi Auditada com relação ao nível de conformidade com os requisitos do
procedimento de referência.
Obs.: Neste quesito responda com a Nota obtida na Auditoria da Etapa 2 (Seleção do
Sistema e Coleta de Informações)
Q3
→
Existe uma estrutura computacional ou ferramenta equivalente para agilizar, organizar e
garantir a participação de toda a equipe de implantação na concepção da FMECA e ao
mesmo tempo possibilite a criação de ambientes virtuais para flexibilizar as reuniões.
Q4
→
Existe uma documentação de engenharia consistente do sistema que será analisado,
incluindo proteções, instrumentação, monitoramento e controle.
Q5
→
Existe uma documentação/histórico consistente das falhas funcionais e dos controles atuais
para detectar e/ou prevenir as causas dos modos de falha.
Q6
→
Existe uma análise prévia das causas raízes do modo de falha (FTA –
Fault Tree Analysis
–
Análise da Árvore de Falhas) e dos seus efeitos (ETA –
Event Tree Analysis
– Análise d
a
Árvore de Eventos), a qual será utilizada para embasar a FMECA. Senão, serão utilizadas
análises de sistemas similares devidamente adaptadas ao contexto operacional em questão.
Critério 2 (C2) – Competências e Habilidades da Equipe:
Q1
→
A equipe que executará o FMECA (Análise dos Modos de Falha, seus Efeitos e su
a
Criticidade) conta com representantes da operação, manutenção, fornecedores, fabricante do
sistema analisado e consumidores/clientes da empresa.
Q2
→
A equipe que executará o FMECA (Análise dos Modos de Falha, seus Efeitos e su
a
Criticidade) recebeu treinamento específico e conhece os termos utilizados, seus
significados e a forma correta de preenchimento das planilhas de FMECA.
Q3
→
O tamanho da equipe, suas competências e habilidades e seu envolvimento e interesse com o
sistema a ser analisado estão adequados para o número de modos de falha e conseqüente
tempo de dedicação esperados para o FMECA.
Q4
→
Os índices e critérios para avaliação da criticidade (Severidade, Ocorrência e Detecção)
foram customizados e aprovados pela empresa e seus interessados “
stakeholders
” e estão
documentados de forma auditável. Caso este pré-requisito ainda não tenha sido satisfeito,
a
equipe de implantação o fará antes do início da condução da FMECA.
Q5
→
A equipe de implantação está preparada para avaliar tanto as causas e efeitos do modo de
falha internos à empresa quanto os externos os quais, de alguma forma, afetam o sistema
a
ser analisado ou a empresa.
F.1.5 Pré-Requisitos_Etapa 4
Critério 1 (C1) – Disponibilidade da Informação/Recursos:
Q1
→
Todas as Entradas, Controles e Mecanismos da Etapa 4 (Seleção das Funções Significantes e
Classificação de seus Modos de Falha), do procedimento de referência para implantação d
a
MCC, estão disponíveis.
Q2
→
A etapa anterior foi Auditada com relação ao nível de conformidade com os requisitos do
procedimento de referência.
Obs.: Neste quesito responda com a Nota obtida na Auditoria da Etapa 3 (Análise dos
Modos de Falha, seus Efeitos e sua Criticidade – FMECA).
Q3
→
A relação das funções do item/sistema, as quais já estão atualmente protegidas por tarefas de
manutenção estão disponíveis para a análise da equipe de implantação.
284
Q4
→
Os critérios para avaliação dos impactos de segurança, ambientais, econômicos e
operacionais, foram aprovados pelos níveis gerenciais da empresa e pelos
usuários/operadores do sistema e estão documentados de forma auditável. Caso este pré-
requisito ainda não tenha sido satisfeito, a equipe de implantação o fará antes do início d
a
condução desta etapa.
Q5
→
A equipe de implementação conta com representantes que são usuários/operadores do
sistema sob análise. Caso contrário, estes podem ser convocados especificamente para est
a
etapa após um treinamento prévio em MCC para atestar: a significância das funções, e a
evidência ou não dos modos de falha, seus efeitos ou as falhas funcionais a eles associadas.
F.1.6 Pré-Requisitos_Etapa 5
Critério 1 (C1) – Disponibilidade da Informação/Recursos:
Q1
→
Todas as Entradas, Controles e Mecanismos da Etapa 5 (Seleção das Tarefas de Manutenção
Aplicáveis e Efetivas), do procedimento de referência para implantação da MCC, estão
disponíveis.
Q2
→
A etapa anterior foi Auditada com relação ao nível de conformidade com os requisitos do
procedimento de referência.
Obs.: Neste quesito responda com a Nota obtida na Auditoria da Etapa 4 (Seleção das
Funções Significantes e Classificação de seus Modos de Falha).
Q3
→
Os critérios para avaliação da aplicabilidade e efetividade das ações de manutenção fora
m
aprovados pelos níveis gerenciais da empresa e pelos usuários/operadores do sistema e estão
documentados de forma auditável. Caso este pré-requisito ainda não tenha sido satisfeito,
a
equipe de implantação o fará antes do início da condução desta etapa.
Q4
→
A equipe de implementação conta com representantes da manutenção e usuários/operadores
do sistema sob análise ou caso contrário estes podem ser convocados especificamente par
a
esta etapa, após um treinamento prévio em MCC, para atestar a aplicabilidade e
a
efetividade das ações de manutenção.
Q5
→
Os custos e recursos do setor de manutenção estão disponíveis, destacando-se: custo po
r
hora trabalhada dos mantenedores, equipamentos disponíveis para ações preditivas e/o
u
locados para ações específicas com seus respectivos custos para a empresa, recursos
logísticos, humanos e financeiros do setor de manutenção.
Critério 2 (C2) – Conhecimento da Falha:
Q1
→
A maneira como a falha evolui (mecanismo da falha) é conhecida para todos os modos de
falha relacionados às funções significantes.
Q2
→
A rotina operacional do item/sistema, no qual a MCC será implantada, é conhecida pela
equipe de implantação.
Q3
→
A equipe de implantação conhece o impacto na segurança e no meio ambiente relacionado
à
p
erda das funções significantes do item/sistema, no qual a MCC será implantada. As normas
de segurança e ambientais do referido item/sistema também estão disponíveis.
F.1.7 Pré-Requisitos_Etapa 6
Critério 1 (C1) – Disponibilidade da Informação/Recursos:
Q1
→
Todas as Entradas, Controles e Mecanismos da Etapa 6 (Definição dos Intervalos Iniciais e
285
Agrupamento das Tarefas de Manutenção), do procedimento de referência para implantação
da MCC, estão disponíveis.
Q2
→
A etapa anterior foi Auditada com relação ao nível de conformidade com os requisitos do
procedimento de referência.
Obs.: Neste quesito responda com a Nota obtida na Auditoria da Etapa 5 (Seleção das
Tarefas de Manutenção Aplicáveis e Efetivas).
Q3
→
Existe uma documentação gerencial que permita inferir sobre o contexto e o ciclo
operacional do sistema, os custos envolvidos e os riscos financeiros, de segurança, e par
a
meio ambiente, de forma a ponderar a tomada de decisão referente aos intervalos e
agrupamentos das ações de manutenção.
Q4
→
As seguintes informações técnicas dos itens/componentes, relacionados às funções
significantes, estão disponíveis para a equipe de implementação: curva de degradação,
tempo de operação, tempo médio entre falhas, tempo para falhar e tempo de reparo.
Q5
→
A equipe de implantação tem competência e habilidade para definir os aspectos a sere
m
otimizados durante a definição dos intervalos iniciais e agrupamento das atividades de
manutenção.
F.1.8 Pré-Requisitos_Etapa 7
Critério 1 (C1) – Disponibilidade da Informação/Recursos:
Q1
→
Todas as Entradas, Controles e Mecanismos da Etapa 7 (Redação do Manual e
Implementação), do procedimento de referência para implantação da MCC, estão
disponíveis.
Q2
→
A etapa anterior foi Auditada, com relação ao nível de conformidade com os requisitos do
procedimento de referência.
Obs.: Neste quesito responda com a Nota obtida na Auditoria da Etapa 6 (Definição dos
Intervalos Iniciais e Agrupamento das Tarefas de Manutenção).
Q3
→
A equipe de implementação não irá se dispersar até concluir a redação do manual e
implantar efetivamente o programa de MCC, no sistema de gestão da manutenção d
a
empresa.
Q4
→
Existe uma estrutura computacional para geração automática do manual da MCC, o qual
deve contemplar todas as decisões e saídas das etapas conforme o procedimento de
referência. Caso contrário, existe disponibilidade de pessoal para realização desta atividade.
Critério 2 (C2) – Planejamento para Implementação:
Q1
→
Os recursos financeiros, humanos e os equipamentos necessários para implementação das
tarefas de manutenção e controle do programa de MCC estão disponíveis, de forma
a
garantir sua realimentação e revisão.
Q2
→
Existe uma estrutura interna ou externa à empresa (terceirizada) para treinamento dos
mantenedores e operadores, com base no novo programa de gestão da manutenção proposto
pela MCC.
Q3
→
O sistema computacional de gestão da manutenção permite, de forma automática, a partir do
software de implantação da MCC, a inclusão das tarefas e controles propostos pelo
p
rograma de MCC. Caso contrário, existe disponibilidade de pessoal para uma inclusão
manual.
286
F.1.9 Pré-Requisitos_Etapa 8
Critério 1 (C1) – Disponibilidade da Informação/Recursos:
Q1
→
Todas as Entradas, Controles e Mecanismos da Etapa 8 (Acompanhamento e Realimentação),
do procedimento de referência para implantação da MCC, estão disponíveis.
Q2
→
A etapa anterior foi Auditada, com relação ao nível de conformidade com os requisitos do
procedimento de referência.
Obs.: Neste quesito responda com a Nota obtida na Auditoria da Etapa 7 (Redação do
Manual e Implementação da MCC).
Q3
→
O manual da MCC foi divulgado para os mantenedores, operadores e alta gerência. Após su
a
divulgação, houve consenso de que o novo programa de manutenção da empresa tradu
z
fielmente as atividades recomendadas pela MCC para aqueles sistemas onde esta foi
implantada.
Critério 2 (C2) – Aderência da MCC:
Q1
→
Os responsáveis pela fase de execução do programa de MCC têm claros os objetivos e
interesses do programa, a ponto de criar índices que avaliem: o desempenho do programa de
MCC; o desempenho da manutenção após a implementação do programa de MCC; e
a
aderência da empresa ao programa de MCC.
Q2
→
O plano de manutenção gerado pela MCC foi incorporado na íntegra ao sistema de gestão d
a
manutenção da empresa/sistema. Da mesma forma, os procedimentos técnicos de
manutenção e operação do ativo/sistema, no qual a MCC foi implantada, foram alterados
para se adequar as novas tarefas de manutenção apontadas pelo programa de MCC.
Q3
→
Todos os procedimentos de manutenção e operação, apontados pela MCC, estão
normatizados e há ações disciplinadoras ou corretivas, caso haja quebra de procedimentos.
Q4
→
O sistema de gestão da manutenção e os recursos logísticos foram redimensionados par
a
atender as novas necessidades ditadas pela MCC.
F.2 AUDITORIA DA MCC
Os próximos itens detalham os Quesitos (Q
n
), a serem ponderados pelo usuário, para
avaliação de cada Critério (C
n
). A desfuzzyficação dos conjuntos
Fuzzy
formados pela agregação
dos critérios avaliados resulta na avaliação da Etapa “n”. Tais Critérios e seus respectivos
Quesitos se referem a Auditoria.
F.2.1 Auditoria_Etapa 0
Critério 1 (C1) – Confiabilidade da Análise:
Q1
→
Os pré-requisitos desta etapa foram atendidos em um nível satisfatório ou, caso contrário,
uma política de melhoramento dos fatores negativos foi planejada e implementada antes do
início da etapa.
Obs.: Neste quesito responda com a Nota obtida na análise dos Pré-Requisitos da Etapa 0
(Adequação da MCC).
287
Q2
→
Todas as decisões tomadas durante a Etapa 0 (Adequação da MCC) foram documentadas,
atendem as exigências de Saída do procedimento de referência e tem consistência para um
a
auditoria futura.
Q3
→
Os questionamentos referentes à análise dos Pré-Requisitos e Auditoria da Etapa 0
(Adequação da MCC) foram ou estão sendo respondidos por membros da equipe de
manutenção, operação, gerência e demais interessados ou afetados pelo programa de MCC
ou pelos sistemas candidatos a sua implantação. A tomada de decisão se deu pela médi
a
ponderada das respostas individuais.
Q4
→
Normas, bibliografias e especialistas foram consultados para avaliar os benefícios e os
desafios de um programa de MCC.
Q5
→
Programas similares de MCC foram consultados/estudados e poderão servir de
benchmarking para o processo de implantação.
F.2.2 Auditoria_Etapa 1
Critério 1 (C1) – Confiabilidade da Análise:
Q1
→
Os pré-requisitos desta etapa foram atendidos em um nível satisfatório ou, caso contrário,
uma política de melhoramento dos fatores negativos foi planejada e implementada antes do
início da etapa.
Obs.: Neste quesito responda com a Nota obtida na análise dos Pré-Requisitos da Etapa 1
(Preparação).
Q2
→
Todas as decisões tomadas durante a Etapa 1 (Preparação) foram documentadas, atendem as
exigências de Saída do procedimento de referência e tem consistência para uma auditori
a
futura.
Q3
→
Os questionamentos referentes à análise dos Pré-Requisitos e Auditoria da Etapa 1
(Preparação) foram ou estão sendo respondidos por membros da equipe de manutenção,
operação, gerência e demais interessados ou afetados pelo programa de MCC ou pelos
sistemas candidatos a sua implantação. A tomada de decisão se deu pela média ponderad
a
das respostas individuais.
Q4
→
Todos os envolvidos no processo de implantação da MCC – equipe de manutenção,
operação, gerência e demais interessados ou afetados pelo programa de MCC – entenderam,
aceitaram e acreditam ser exeqüível o plano de implantação, o qual está documentado de
forma auditável.
Q5
→
O contexto operacional, cultural, histórico e político da empresa/sistema foram considerados
para balizar os objetivos e resultados esperados e delinear a estratégia que compõe o plano
de implantação.
Q6
→
Os clientes, internos e externos, foram contemplados e/ou envolvidos, com algum grau de
comprometimento, no processo de implementação da MCC.
Critério 2 (C2) – Recursos e Responsabilidades:
Q1
→
O papel dos atores da equipe de implantação da MCC está claro, acordado entre os
p
articipantes e documentado de forma auditável. As seguintes funções prioritárias estão
claramente definidas: Comitê Gestor, Equipe de Análise e Facilitador.
Q2
→
Existe uma estrutura para gestão da informação e divulgação dos resultados e da cronologi
a
da implantação da MCC, tanto para a equipe de implementação, como para os interessados
ou afetados pelo programa de MCC.
Q3
→
O patrocinador interno entendeu e aceitou suas atribuições (mobilização de recursos
288
humanos e financeiros para o programa de MCC) e acredita ser possível desempenhá-las de
forma adequada e com a brevidade exigida pelos procedimentos de implementação das
etapas da MCC.
Q4
→
Para compatibilizar o tamanho da equipe de implementação da MCC com a complexidade
do sistema a ser analisado foram utilizados como modelos “
templates
”, sistemas similares
em complexidade e domínio de conhecimento.
Critério 3 (C3) – Competências e Habilidades da Equipe:
Q1
→
A equipe de implantação da MCC, de manutenção, gerentes e diretores participaram de
treinamento na metodologia/filosofia da MCC.
Q2
→
A equipe de implementação do programa de MCC tem conhecimento das técnicas e
métodos de Gestão de Projetos. Ex.: PMBOK (
Project Management Body of Knowledge
) do
PMI (
Project Management Institute
).
Q3
→
Membros da equipe de implantação da MCC já participaram de um projeto piloto de
contexto similar ao que se está pretendendo.
Q4
→
Existe um procedimento, documentado de forma auditável, para troca de membros d
a
equipe de implementação da MCC, que garanta a igualdade de conhecimento com relação
aos demais membros da equipe, em qualquer etapa do processo de implementação.
Critério 4 (C4) – Certificação das Decisões:
Q1
→
Todas as etapas, do procedimento de referência para implantação da MCC, fora
m
consideradas no planejamento e concebidas nos moldes recomendados para gestão de
p
rojetos, com: inicialização, planejamento, execução, controle e encerramento. E envolve
m
as seguintes áreas de conhecimento: integração, escopo, tempo, custo, qualidade, recursos
humanos, comunicação, risco e aquisições.
Q2
→
O projeto, de implantação da MCC, é o único no qual a equipe de implementação est
á
envolvida, além de suas atividades diárias na empresa.
Q3
→
Os resultados práticos e de amadurecimento na metodologia MCC, obtidos no projeto
piloto, foram contemplados no planejamento do processo de implantação da MCC.
Q4
→
O plano, de implantação da MCC, está documentado de forma auditável, e foi divulgado
para todos os clientes internos, externos e demais interessados e/ou afetados pelo program
a
de MCC, incluindo a alta gerência.
F.2.3 Auditoria_Etapa 2
Critério 1 (C1) – Confiabilidade da Análise:
Q1
→
Os pré-requisitos desta etapa foram atendidos em um nível satisfatório ou, caso contrário,
uma política de melhoramento dos fatores negativos foi planejada e implementada antes do
início da etapa.
Obs.: Neste quesito responda com a Nota obtida na análise dos Pré-Requisitos da Etapa 2
(Seleção do Sistema e Coleta de Informações).
Q2
→
Todas as decisões tomadas durante a Etapa 2 (Seleção do Sistema e Coleta de Informações)
foram documentadas, atendem as exigências de Saída do procedimento de referência e te
m
consistência para uma auditoria futura.
Q3
→
Os questionamentos referentes à análise dos Pré-Requisitos e Auditoria da Etapa 2 (Seleção
do Sistema e Coleta de Informações) foram ou estão sendo respondidos por membros d
a
289
equipe de manutenção, operação, gerência e demais interessados ou afetados pelo program
a
de MCC ou pelos sistemas candidatos a sua implantação. A tomada de decisão se deu pel
a
média ponderada das respostas individuais.
Q4
→
A equipe de implementação utilizou critérios para avaliação dos sistemas candidatos que
consideraram: as questões ambientais e de segurança, que permeiam um programa de MCC;
e as conseqüências econômicas advindas para a empresa e seus processos produtivos.
Q5
→
Foram utilizados os dados confiabilísticos e de mantenabilidade disponíveis para os sistemas
candidatos e a escolha do sistema, ao qual a MCC será implantada, se deu a partir de um
a
abordagem quantitativa.
Critério 2 (C2) – Certificação dos Resultados:
Q1
→
O sistema escolhido para ser submetido à análise da MCC, suas fronteiras e o nível de
detalhamento que será adotado nas análises da equipe de implementação está definido,
descrito e documentado de forma auditável.
Q2
→
A equipe de implementação do programa de MCC possui representantes com competênci
a
em todas as áreas de conhecimento relacionadas aos sistemas candidatos e o sistem
a
escolhido obteve o consenso do grupo.
Q3
→
A empresa possui em seu quadro funcional especialistas com conhecimento técnico
profundo sobre o sistema escolhido para ser submetido à análise da MCC.
Q4
→
O escopo e seu nível de detalhamento estão adequados para o tamanho da equipe de
implantação, considerando o número de modos de falha por item/componente e o tempo
previsto para término da análise.
F.2.4 Auditoria_Etapa 3
Critério 1 (C1) – Confiabilidade da Análise:
Q1
→
Os pré-requisitos desta etapa foram atendidos em um nível satisfatório ou, caso contrário,
uma política de melhoramento dos fatores negativos foi planejada e implementada antes do
início da etapa.
Obs.: Neste quesito responda com a Nota obtida na análise dos Pré-Requisitos da Etapa 3
(Análise dos Modos de Falha, seus Efeitos e sua Criticidade - FMECA).
Q2
→
Todas as decisões, tomadas durante a Etapa 3 (Análise dos Modos de Falha, seus Efeitos e
sua Criticidade - FMECA) foram documentadas, atendem as exigências de Saída do
procedimento de referência e tem consistência para uma auditoria futura.
Q3
→
Os questionamentos referentes à análise dos Pré-Requisitos e Auditoria da Etapa 3 (Análise
dos Modos de Falha, seus Efeitos e sua Criticidade - FMECA) foram ou estão sendo
respondidos por mem
b
ros da equipe de manutenção, operação, gerência e demais
interessados ou afetados pelo programa de MCC ou pelo sistema escolhido para su
a
implantação. A tomada de decisão se deu pela média ponderada das respostas individuais.
Q4
→
Existe um procedimento documentado e devidamente divulgado para os envolvidos com o
sistema no qual a MCC será implantada, para atualização e correção da FMECA. Este
p
rocedimento aponta todas as razões e circunstâncias que motivam as atualizações e/o
u
correções.
Q5
→
A FMECA possui uma conexão com um plano e/ou procedimento onde constem as ações
a
serem tomadas na ocorrência dos modos de falha.
Critério 2 (C2) – Itens, Funções e Falhas Funcionais:
290
Q1
→
Os itens, analisados na FMECA pertencem ao menor nível manutenível do sistema.
Q2
→
O contexto operacional da instalação foi definido e documentado de forma auditável.
Q3
→
Todas as funções do item/sistema (primárias / secundárias / de proteção, monitoramento e
controle – SCADA e instrumentação) foram identificadas e documentadas de form
a
auditável e sua definição contém um verbo, um objeto e um padrão de desempenho
(quantificado em cada caso possível).
Q4
→
Os padrões de desempenho, incorporados nas definições das funções, são níveis de
desempenho desejados pelo proprietário ou usuário do item/sistema no seu contexto
operacional.
Q5
→
Todos os estados de falha associados às funções foram identificados de forma completa, são
compatíveis com a função e foram documentados de forma auditável.
Critério 3 (C3) – Modos de Falha:
Q1
→
Todos os modos de falha, razoavelmente prováveis de causar cada falha funcional, fora
m
identificados e documentados de forma auditável. O método usado para decidir o que
constitui um modo de falha “razoavelmente provável” foi aceito pelo proprietário ou usuário
do item/sistema e documentado de forma auditável.
Q2
→
Os modos de falha foram identificados a um nível de causalidade que torna possível
identificar uma política apropriada para gerenciamento da falha.
Q3
→
Foram incluídos na lista de modos de falha aqueles que: tenham ocorrido anteriormente;
estão atualmente sendo prevenidos por programas existentes de manutenção; ainda não
ocorreram, mas que são julgados como razoavelmente prováveis de ocorrer (factíveis) no
contexto operacional. Todos os casos foram documentados de forma auditável.
Q4
→
Foram incluídos, na lista de modos de falha, qualquer evento ou processo que possa causa
r
uma falha funcional, incluindo deterioração, defeitos de projeto, e erros humanos se
causados por operadores ou mantenedores.
Q5
→
Foram levados em consideração os modos de falha externos aos domínios e/ou controle d
a
empresa, por exemplo: modos de falha devido a fornecedores e problemas logísticos.
Critério 4 (C4) – Efeitos e Causas da Falha:
Q1
→
A descrição dos efeitos inclui o que aconteceria se nenhuma tarefa específica fosse realizad
a
p
ara antecipar, prevenir, ou detectar a falha. Estas informações estão documentadas de
forma auditável.
Q2
→
A descrição dos efeitos inclui todas as informações necessárias para avaliar se a
conseqüência da falha: é evidente ou, no caso de falhas ocultas, o que acontece se uma falh
a
múltipla ocorrer; pode provocar a morte ou ferir alguém; pode provocar um efeito adverso
ao meio ambiente; pode afetar adversamente a operação ou a produção. Estas informações
estão documentadas de forma auditável.
Q3
→
A descrição dos efeitos inclui todas as informações necessárias para avaliar se, como
conseqüência da falha, existe a possibilidade de causar danos físicos e o que deve ser feito
para restaurar a função do sistema após a falha. Estas informações estão documentadas de
forma auditável.
Q4
→
A descrição das causas da falha revela porque o modo de falha do item/sistema ocorreu.
Estas informações estão documentadas de forma auditável.
291
F.2.5 Auditoria_Etapa 4
Critério 1 (C1) – Confiabilidade da Análise:
Q1
→
Os pré-requisitos desta etapa foram atendidos em um nível satisfatório ou, caso contrário,
uma política de melhoramento dos fatores negativos foi planejada e implementada antes do
início da etapa.
Obs.: Neste quesito responda com a Nota obtida na análise dos Pré-Requisitos da Etapa 4
(Seleção das Funções Significantes e Classificação de seus Modos de Falha).
Q2
→
Todas as decisões tomadas durante a Etapa 4 (Seleção das Funções Significantes e
Classificação de seus Modos de Falha) foram documentadas, atendem as exigências de
Saída do procedimento de referência e tem consistência para uma auditoria futura.
Q3
→
Os questionamentos referentes à análise dos Pré-Requisitos e Auditoria da Etapa 4 (Seleção
das Funções Significantes e Classificação de seus Modos de Falha) foram ou estão sendo
respondidos por membros da equipe de manutenção, operação, gerência e demais
interessados ou afetados pelo programa de MCC ou pelo sistema escolhido para su
a
implantação. A tomada de decisão se deu pela média ponderada das respostas individuais.
Q4
→
A imagem da empresa e/ou os danos para os usuários, clientes ou terceiros fora
m
contemplados no processo de tomada de decisão.
Critério 2 (C2) – Certificação dos Resultados:
Q1
→
As conseqüências de cada modo de falha estão classificadas formalmente, sendo que, os
modos de falha ocultos estão separados dos evidentes e há uma distinção clara entre eventos
que tenham conseqüências de segurança e/ou ambientais daqueles com conseqüências
econômicas e/ou operacionais. Esta classificação está documentada de modo auditável.
Q2
→
A avaliação das conseqüências das falhas é realizada como se nenhuma tarefa específic
a
estivesse sendo realizada para antecipar, prevenir ou detectar a falha.
Q3
→
Todas as funções apontadas como significantes afetam de modo adverso um ou outro dos
seguintes aspectos: segurança, meio ambiente, operação, economia do processo produtivo
e/ou a função já é protegida por alguma atividade de manutenção.
Q4
→
As funções tidas como não significantes, as quais não seguirão na análise do grupo de
implantação da MCC, foram documentadas de forma auditável.
F.2.6 Auditoria_Etapa 5
Critério 1 (C1) – Confiabilidade da Análise:
Q1
→
Os pré-requisitos desta etapa foram atendidos em um nível satisfatório ou, caso contrário,
uma política de melhoramento dos fatores negativos foi planejada e implementada antes do
início da etapa.
Obs.: Neste quesito responda com a Nota obtida na análise dos Pré-Requisitos da Etapa 5
(Seleção das Tarefas de Manutenção Aplicáveis e Efetivas).
Q2
→
Todas as decisões tomadas durante a Etapa 5 (Seleção das Tarefas de Manutenção
Aplicáveis e Efetivas) foram documentadas, atendem as exigências de Saída do
procedimento de referência e tem consistência para uma auditoria futura.
Q3
→
Os questionamentos referentes à análise dos Pré-Requisitos e Auditoria da Etapa 5 (Seleção
das Tarefas de Manutenção Aplicáveis e Efetivas) foram ou estão sendo respondidos po
r
membros da equipe de manutenção, operação, gerência e demais interessados ou afetados
292
p
elo programa de MCC ou pelo sistema escolhido para sua implantação. A tomada de
decisão se deu pela média ponderada das respostas individuais.
Q4
→
A escolha das atividades de manutenção mais adequadas foi guiada pela associação do
mecanismo da falha com as potencialidades e custo benefício das ações de manutenção
adotadas e não unicamente pela disponibilidade de competências e recursos internos d
a
empresa.
Critério 2 (C2) – Seleção e Programação das Tarefas:
Q1
→
A seleção das políticas de gestão de falhas é conduzida como se nenhuma tarefa específic
a
estivesse sendo executada atualmente, para antecipar, prevenir ou detectar a falha. Alé
m
disto, todo o processo de seleção está documentado de modo auditável.
Q2
→
O processo de seleção da gestão da falha considera o fato de que: a probabilidade
condicional de alguns modos de falha aumenta com a idade; a de outros não muda com
a
idade; e a de alguns diminui com a idade.
Q3
→
Todas as tarefas programadas são tecnicamente viáveis e atrativas (aplicáveis e efetivas) e se
duas ou mais atividades enquadram-se nesta situação, a atividade selecionada é aquela mais
efetiva em termos de custos.
Q4
→
No caso de um modo de falha evidente, que tenha conseqüências de segurança ou ambiental,
a tarefa programada (se existente) reduz a probabilidade do modo de falha a um nível que é
tolerável ao proprietário ou usuário da instalação.
Q5
→
N
o caso de um modo de falha oculto, onde a falha múltipla associada tenha conseqüências
de segurança ou am
b
iental, a tarefa programada (se existente) reduz a probabilidade do
modo de falha oculto a um valor cuja probabilidade da falha múltipla associada é tolerável
ao proprietário ou usuário da instalação.
Q6
→
No caso de um modo de falha evidente, que não tenha conseqüências de segurança o
u
ambiental, os custos diretos e indiretos de execução da tarefa programada (se existente) são
menores que os custos diretos e indiretos do modo de falha, quando medidos em períodos
comparáveis de tempo.
Q7
→
No caso de um modo de falha oculto, onde a falha múltipla associada, não tenha conseqüências
de segurança ou ambiental, os custos diretos e indiretos de execução da tarefa programada (se
existente) são menores que os custos diretos e indiretos da falha múltipla mais o custo de reparo
do modo de falha oculto, quando medidos em períodos comparáveis de tempo.
Critério 3 (C3) – Serviço Operacional e Inspeção Preditiva:
Q1
→
As tarefas classificadas como sendo de serviço operacional, reduzem a taxa de deterioração
funcional e o risco à segurança e de perda da operação, além de ter custo reduzido.
Q2
→
Existe uma falha potencial claramente definida, para cada Inspeção Preditiva programada.
Q3
→
Existe um intervalo PF identificável (ou período de desenvolvimento da falha), para cad
a
Inspeção Preditiva programada.
Q4
→
O intervalo da tarefa é menor que o menor intervalo PF provável, para cada Inspeção
Preditiva programada.
Q5
→
É fisicamente possível realizar a tarefa a intervalos menores que o intervalo PF, para cad
a
Inspeção Preditiva programada.
Q6
→
O menor tempo entre a descoberta de uma falha potencial e a ocorrência da falha funcional
(o intervalo PF menos o intervalo da tarefa) é suficiente para que a ação determinada sej
a
293
tomada para evitar, eliminar ou minimizar as conseqüências do modo de falha, para cad
a
Inspeção Preditiva programada.
Critério 4 (C4) – Restauração e Substituição Preventiva:
Q1
→
Existe uma idade claramente definida (preferivelmente demonstrável), na qual ocorre u
m
aumento na probabilidade condicional do modo de falha considerado, para cada Restauração
Preventiva programada.
Q2
→
Uma proporção elevada de ocorrências do modo de falha considerado ocorre após um
a
determinada idade, o que reduz a probabilidade de falha prematura a um nível que é
tolerável pelo proprietário ou usuário da instalação, para cada Restauração Preventiv
a
programada.
Q3
→
A tarefa restaura a resistência à falha (condição) do componente a um nível que é tolerável
pelo proprietário ou usuário da instalação, para cada Restauração Preventiva programada.
Q4
→
Existe uma idade claramente definida (preferivelmente demonstrável), na qual ocorre u
m
aumento na probabilidade condicional do modo de falha em consideração, para cad
a
Substituição Preventiva programada.
Q5
→
Uma proporção elevada de ocorrências do modo de falha considerado ocorre após um
a
determinada idade, o que reduz a probabilidade de falha prematura a um nível que é
tolerável pelo proprietário ou usuário da instalação, para cada Substituição Preventiv
a
programada.
Critério 5 (C5) – Inspeção Funcional e Manutenção Combinada:
Q1
→
A determinação do intervalo da tarefa de inspeção leva em conta, para cada Inspeção
Funcional programada, a necessidade de reduzir a probabilidade da falha múltipla do
sistema protegido a um nível que é tolerável pelo proprietário ou usuário da instalação (não
aplicável a modos de falha evidentes).
Q2
→
A tarefa de inspeção confirma que todos os componentes cobertos pela descrição do modo
de falha estão funcionando, para cada Inspeção Funcional programada (não aplicável
a
modos de falha evidentes).
Q3
→
A tarefa de Inspeção Funcional e o processo de seleção do intervalo associado levam e
m
conta qualquer probabilidade de que a tarefa por si só pode deixar a função oculta em u
m
estado de falha, para cada Ins
p
eção Funcional programada (não aplicável a modos de falh
a
evidentes).
Q4
→
É fisicamente possível realizar a tarefa nos intervalos especificados, para cada Inspeção
Funcional programada (não aplicável a modos de falha evidentes).
Q5
→
No caso das atividades classificadas como sendo de manutenção combinada, nenhum
a
atividade de manutenção isolada consegue identificar e/ou corrigir a falha, somente um
a
combinação de tarefas.
Q6
→
No caso das atividades classificadas como sendo de manutenção combinada, o custo de tais
atividades é inferior ao custo da falha, além disto, reduzem a taxa de deterioração funcional
e o risco à segurança e de perda da operação.
Critério 6 (C6) – Mudança de Projeto e Reparo Funcional:
Q1
→
Os procedimentos adotados pelo programa de MCC tenta extrair o desempenho desejado do
sistema, tal como está configurado e operado atualmente, pela aplicação de tarefas
294
programadas apropriadas.
Q2
→
Quando as tarefas programadas não foram aplicáveis e efetivas, com falha oculta, e co
m
falha múltipla associada com conseqüência de segurança e ambiental, foi proposto um
a
Mudança de Projeto que reduziu a probabilidade da falha múltipla a um nível tolerável par
a
o proprietário ou usuário da instalação.
Q3
→
Quando as tarefas programadas não foram aplicáveis e efetivas, com modo de falha evidente e
conseqüência de segurança ou ambiental, foi proposto uma Mudança de Projeto que reduziu
a
probabilidade do modo de falha a um nível tolerável para o proprietário ou usuário da instalação.
Q4
→
Quando as tarefas programadas não foram aplicáveis e efetivas, com modo de falha oculto e
e falha múltipla associada sem conseqüência de segurança e ambiental, as Mudanças de
Projeto propostas são atrativas em termos de custo na opinião do proprietário ou usuário d
a
instalação.
Q5
→
Quando as tarefas programadas não foram aplicáveis e efetivas, com modo de falh
a
evidente, e sem conseqüência de segurança e ambiental, as Mudanças de Projeto propostas
são atrativas em termos de custo na opinião do proprietário ou usuário da instalação.
Q6
→
Reparos Funcionais são utilizados nos seguintes casos: falha oculta sem uma atividade
p
rogramada apropriada, e com falha múltipla associada sem conseqüência de segurança o
u
ambiental; ou falha evidente sem uma atividade programada apropriada e com modo de
falha associado sem conseqüência de segurança ou ambiental.
F.2.7 Auditoria_Etapa 6
Critério 1 (C1) – Confiabilidade da Análise:
Q1
→
Os pré-requisitos desta etapa foram atendidos em um nível satisfatório ou, caso contrário,
uma política de melhoramento dos fatores negativos foi planejada e implementada antes do
início da etapa.
Obs.: Neste quesito responda com a Nota obtida na análise dos Pré-Requisitos da Etapa 6
(Definição dos Intervalos Iniciais e Agrupamento das Tarefas de Manutenção).
Q2
→
Todas as decisões tomadas durante a Etapa 6 (Definição dos Intervalos Iniciais e
Agrupamento das Tarefas de Manutenção) foram documentadas, atendem as exigências de
Saída do procedimento de referência e tem consistência para uma auditoria futura.
Q3
→
Os questionamentos referentes à análise dos Pré-Requisitos e Auditoria da Etapa 6
(Definição dos Intervalos Iniciais e Agrupamento das Tarefas de Manutenção) foram o
u
estão sendo respondidos por membros da equipe de manutenção, operação, gerência e
demais interessados ou afetados pelo programa de MCC ou pelo sistema escolhido para su
a
implantação. A tomada de decisão se deu pela média ponderada das respostas individuais.
Q4
→
Os intervalos de manutenção foram otimizados com base nos dados estatísticos de
confiabilidade e mantenabilidade do item/sistema. O equacionamento matemático, utilizado
no processo decisório, é logicamente robusto e foi disponibilizado e/ou aprovado pelo
proprietário ou usuário da instalação.
Q5
→
As decisões tomadas contemplaram critérios heurísticos, dos operadores e mantenedores,
p
reliminares a análise e em nenhum caso estes critérios heurísticos foram negligenciados,
sem uma justificativa de consenso entre o grupo de implantação e os demais envolvidos o
u
afetados pelo programa de MCC.
Q6
→
Todas as ações corretivas foram revisadas e os critérios que levaram a sua decisão
ratificaram sua escolha como a ação de manutenção mais adequada para o modo de falha e
m
questão.
295
Q7
→
As tarefas de manutenção foram agrupadas, levando em conta o ciclo operacional do
sistema, de modo a minimizar o impacto na sua disponibilidade.
Critério 2 (C2) – Abrangência da Análise:
Q1
→
O contexto operacional e os riscos para a segurança, meio ambiente e financeiros, decorrentes
da perda da função, estão documentados de forma auditável e foram levados em conta no
processo de tomada de decisão (especialmente no caso de adiamento de ações preventivas).
Q2
→
Um programa de exploração da idade do item/sistema foi proposto para todos os casos e
m
que as tarefas de manutenção não puderam ser associadas a curvas de degradação, dados
históricos ou conhecimento heurístico prévio que justificasse seus intervalos iniciais.
Q3
→
O planejamento estratégico da empresa ratifica as decisões tomadas referentes aos
agrupamentos e intervalos iniciais de manutenção, principalmente no que diz respeito a:
disponibilidade de pessoal, material, peças sobressalentes e equipamentos.
Q4
→
O setor e/ou os responsáveis pelos sobressalentes e terceirizações foram comunicados das
novas necessidades e prazos para disponibilização de peças, materiais, equipamentos e
serviços definidos pelo programa de MCC a ser implantado.
Critério 3 (C3) – Impacto das Decisões:
Q1
→
As atividades de manutenção relacionadas com a preservação da segurança e do meio
ambiente não tiveram seu período de execução estendido além do limite de garantia do
p
adrão mínimo de segurança estabelecido pela MCC, inclusive nas inspeções funcionais,
quando uma falha múltipla afetar a segurança.
Q2
→
As atividades de manutenção com impactos apenas operacionais ou econômicos, se
necessário, tiveram seu período de execução ajustado com as demais atividades após um
a
avaliação de custo benefício. Incluindo inspeções funcionais de itens com falhas múltiplas
sem impacto na segurança ou meio ambiente.
Q3
→
As atividades de manutenção de restauração e substituição preventiva não foram proteladas
além do limite de vida útil estabelecido pela MCC.
Q4
→
As atividades de manutenção de inspeção preditiva, quando necessário, tiveram seu período
de execução ajustado, dentro do período PF, com as demais atividades após uma avaliação
de custo/benefício.
Q5
→
O tamanho da equipe de manutenção foi levado em consideração para estipular as
freqüências e o agrupamento das tarefas de manutenção.
F.2.8 Auditoria_Etapa 7
Critério 1 (C1) – Confiabilidade da Análise:
Q1
→
Os pré-requisitos desta etapa foram atendidos em um nível satisfatório ou, caso contrário,
uma política de melhoramento dos fatores negativos foi planejada e implementada antes do
início da etapa.
Obs.: Neste quesito responda com a Nota obtida na análise dos Pré-Requisitos da Etapa 7
(Redação do Manual e Implementação).
Q2
→
Todas as decisões tomadas durante a Etapa 7 (Redação do Manual e Implementação) fora
m
documentadas, atendem as exigências de Saída do procedimento de referência e te
m
consistência para uma auditoria futura.
Q3
→
Os questionamentos referentes à análise dos Pré-Requisitos e Auditoria da Etapa 7 (Redação
296
do Manual e Implementação) foram ou estão sendo respondidos por membros da equipe de
manutenção, operação, gerência e demais interessados ou afetados pelo programa de MCC
ou pelo sistema escolhido para sua implantação. A tomada de decisão se deu pela médi
a
ponderada das respostas individuais.
Q4
→
As questões técnicas, humanas, gerenciais, ambientais e de segurança, relacionadas ao
desempenho da manutenção e do programa de MCC, estão contempladas e documentadas d
e
forma auditável, no manual da MCC, na seção referente aos objetivos e propósitos do programa.
Q5
→
A fase implementação da MCC foi encerrada conforme as boas práticas da Gestão de
Projetos. Ex.: PMBOK (Project Management Body of Knowledge) do PMI (Projec
t
Management Institute).
Critério 2 (C2) – Organização para Execução do Programa de MCC:
Q1
→
As tarefas de manutenção estão claramente estabelecidas, descritas, documentadas de form
a
auditável e pactuadas entre a equipe de manutenção e a alta gerência da empresa ou gestores
do ativo/sistema.
Q2
→
O manual do programa de MCC estabelece procedimentos e recomendações, documentados
de forma auditável, para: garantir a revisão e a realimentação do programa com dados
confiabilísticos e de mantenabilidade; e consolidar os dados estatísticos e taxas de
degradação da função, inclusive para aquelas falhas não previstas pelo programa de MCC.
Q3
→
Todas as tarefas e controles propostos pela MCC, que resultaram em mudança de projeto na
maneira de operar o ativo/sistema ou nos procedimentos rotineiros da equipe de
manutenção/operação, foram implementadas adequadamente e incorporadas ao sistema de
gestão da manutenção e na rotina dos operadores e mantenedores.
Q4
→
Todos os operadores e mantenedores receberam treinamento adequado com base no novo
p
rograma de manutenção proposto pela MCC e estão aptos a desenvolver e documentar suas
atividades e relatar possíveis inconsistências do programa de MCC para futuras revisões.
F.2.9 Auditoria da Etapa 8
Critério 1 (C1) – Confiabilidade da Análise:
Q1
→
Os pré-requisitos desta etapa foram atendidos em um nível satisfatório ou, caso contrário,
uma política de melhoramento dos fatores negativos foi planejada e implementada antes do
início da etapa.
Obs.: Neste quesito responda com a Nota obtida na análise dos Pré-Requisitos da Etapa 8
(Acompanhamento e Realimentação).
Q2
→
Todas as decisões tomadas durante a Etapa 8 (Acompanhamento e Realimentação) fora
m
documentadas, atendem as exigências de Saída do procedimento de referência e te
m
consistência para uma auditoria futura.
Q3
→
Os questionamentos referentes à análise dos Pré-Requisitos e Auditoria da Etapa 8
(Acompanhamento e Realimentação) foram ou estão sendo respondidos por membros d
a
equipe de manutenção, operação, gerência e demais interessados ou afetados pelo program
a
de MCC, ou pelo sistema escolhido para sua implantação. A tomada de decisão se deu pel
a
média ponderada das respostas individuais.
Q4
→
Existe entendimento, apoio e comprometimento com o programa de MCC, envolvendo:
equipe de manutenção, operação e alta gerência, e neste último caso, incluindo suporte
financeiro.
Q5
→
A gestão da informação e do conhecimento está contemplada e adequadamente tratada e se
297
mostrou satisfatória, ao longo da execução do programa de MCC.
Critério 2 (C2) – Melhorias e Mudanças Internas:
Q1
→
Os índices de desempenho da manutenção, assim como, os índices de aderência do
programa de MCC estão sendo acompanhados e realimentam o programa de MCC.
Q2
→
Os resultados do programa de MCC estão aceitáveis para a empresa, equipe de manutenção,
operadores e interessados e/ou afetados pelo programa de MCC. O que leva a acreditar que
as expectativas de todos foram atendidas.
Q3
→
A estratégia das ações de manutenção, para o sistema no qual a MCC foi implementada,
mudou após a implantação da MCC.
Q4
→
Aumentou a importância dada ao registro dos dados de confiabilidade e mantenabilidade do
sistema no qual a MCC foi implementada.
Q5
→
O programa de MCC tem recebido melhoramentos contínuos, entre os quais: treinamentos
p
ara a equipe de manutenção; modernização de equipamentos para as ações de manutenção,
especialmente preditivas; e investimentos para coleta e processamento de dados para
a
manutenção.
Critério 3 (C3) – Planejamento e Controle:
Q1
→
As freqüências individuais das tarefas de manutenção estão compatíveis com o tamanho d
a
equipe.
Q2
→
As análises feitas ao longo do processo de implantação da MCC se confirmaram, caso
contrário, as realimentações e revisões do programa estão sendo conduzidas de acordo co
m
o planejamento inicial.
Q3
→
Os desvios do planejamento inicial da MCC estão sendo monitorados para garantir su
a
atualização e otimização dos resultados. Entre os principais itens monitorados estão: reparos
funcionais não previstos; modificações no projeto das instalações e/ou sistemas;
disponibilidade de novas técnicas e/ou informações; custo benefício; e alterações no
contexto operacional.
Q4
→
Os sistemas computacionais, de apoio a manutenção e a MCC, se mostraram adequados ao
tamanho e complexidade do sistema no qual a MCC foi implantada. Esta adequação se
refere tanto as funcionalidades de uso geral da equipe/setor de manutenção quanto às
específicas da MCC.
298
299
APÊNDICE G
IMPLEMENTAÇÃO COMPUTACIONAL
Apresenta a implementação computacional do DALF-MCC e suas
ferramentas complementares com relação às funcionalidades e detalhes
da interface com o usuário
300
301
APÊNDICE G
IMPLEMENTAÇÃO COMPUTACIONAL
G.1 DALF-MCC
Este item apresenta aspectos complementares àqueles mostrados no Capítulo 6, referentes
ao DALF-MCC (Diagnóstico Auxiliado por Lógica
Fuzzy
para a Manutenção Centrada na
Confiabilidade).
G.1.1 Processo de Fuzzyficação e Desfuzzyficação
Os objetivos deste item são: explicitar como o DALF-MCC determina quais os termos
primários do conjunto
Fuzzy
, referentes a uma determinada variável lingüística, serão afetados
pela atribuição de uma nota a um determinado quesito, ou seja, uma fuzzyficação; e como ocorre
a conversão de um conjunto
Fuzzy
, resultante de um processo de agregação, em uma nota (valor
crisp
), ou seja, uma desfuzzyficação.
No DALF-MCC, o usuário pode parametrizar os termos primários (Ruim, Baixa, Boa, Alta
ou Ótima) que compõem uma variável lingüística, a qual será utilizada no processo de inferência de
qualquer uma das maneiras mostradas na Figura G.1.
μ
1
A B
C D
AB
C D
AB
C D
A B
C D
A B
C D
AB
C D
A B
C D
Figura G.1 – Possíveis Configurações dos Termos Primários no DALF-MCC.
Para exemplificar o processo de fuzzyficação e desfuzzyficação, será tomando como
exemplo, a atribuição de uma nota 1,8 ao quesito Q1 (Estratégia de Manutenção) do Critério C2
(Condição e Desempenho Atual da Manutenção) pertencente à Etapa 0 (Adequação da MCC),
com a parametrização dos termos primários conforme mostrado na Figura G.2.
Q1 - Estratégia de Manutenção
Ruim Baixa Boa Alta Ótima
1 2 3 4
5 6 7 8 9 10
μ
1
Nota = 1,8
μ = 0,8
μ = 0,2
Figura G.2 – Exemplo de Ponderação para Et_0_C_2_Q_1.
302
Os termos primários, afetados pela atribuição da nota (1,8), dependem da função de
pertinência dos mesmos, neste caso, a equação da reta suporte dos pontos que compõe cada um
dos termos primários de Q1 (laterais, núcleo e suporte dos paralelogramos que representam cada
termo primário). Nesta equação de reta, respeitando-se seu intervalo de existência, substitui-se a
nota atribuída (1,8) e encontra-se o valor correspondente ao grau de pertinência da nota ao termo
primário que, neste caso, corresponde ao ponto de corte (
α-cut
) proporcionado pela referida nota.
A equação de uma reta que passa por 2 pontos [
(x
1
, y ) e (x
1 2
, y )] é dada por:
2
(x
2
, y
2
)
, y
1
)
G.1
(x
1
)x-.(x
)x-(x
)y-(y
=y-y
1
12
12
1
ou
11
12
12
y+)x-.(x
)x-(x
)y-(y
=y
Com base na Figura G.2, os seguintes pontos compõem os termos primários utilizados
neste exemplo: (Ruim (0 0) (0 1) (1 1) (2 0)) / (Baixa (1 0) (2 1) (3 1) (4 0)) / (Boa (3 0) (4 1) (6 1)
(7 0)) / (Alta (6 0) (7 1) (8 1) (9 0)) e (Ótima (8 0) (9 1) (10 1) (10 0). Tomando como referência a
Equação G.1 e substituindo os pontos 2 a 2, com o cuidado de verificar o intervalo de existência
de cada função de pertinência (reta suporte), têm-se as seguintes equações relativas à função de
pertinência de cada termo primário:
Ruim: Para 0 ≤ x ≤ 1 tem-se:
1=
y
xy
−
=
2
Para 1 < x ≤ 2, adotando-se os pontos (1 1) (2 0) tem-se:
1
−
=
xy
Baixa: Para 1 ≤ x < 2, adotando-se os pontos (1 0) (2 1) tem-se:
Para 2 ≤ x ≤ 3 tem-se:
1=
y
xy
−
=
4
Para 3 < x ≤ 4, adotando-se os pontos (3 1) (4 0) tem-se:
3
−
=
xy
Boa: Para 3 ≤ x < 4, adotando-se os pontos (3 0) (4 1) tem-se:
Para 4 ≤ x ≤ 6 tem-se:
1=
y
xy
−
=
7
Para 6 < x ≤ 7, adotando-se os pontos (6 1) (7 0) tem-se:
6
−
=
xy
Alta: Para 6 ≤ x < 7, adotando-se os pontos (6 0) (7 1) tem-se:
Para 7 ≤ x ≤ 8 tem-se:
1=
y
xy
−
=
9
Para 8 < x ≤ 9, adotando-se os pontos (8 1) (9 0) tem-se:
8
−
=
xy
Ótima: Para 8 ≤ x < 9, adotando-se os pontos (8 0) (9 1) tem-se:
1
=
y
Para 9 ≤ x ≤ 10 tem-se:
Substituindo a nota 1,8 nos intervalos de existência afetados por ela, tem-se:
Ruim: Para 1 < x ≤ 2: . Portanto com Nota = 1,8 tem-se:
xy
−= 2
2,0
=
y
303
1
−
=
xy
Baixa: Para 1 ≤ x < 2: . Portanto com Nota = 1,8 tem-se:
8,0=
y
Portanto, a nota 1,8 afeta ou pertence ao termo primário Ruim com um Grau de
Pertinência (μ) = 0,2, e ao termo primário Baixa com um Grau de Pertinência (μ) = 0,8. Este
procedimento caracteriza a fuzzyficação, cujo resultado impacta o processo de implicação que irá
determinar os conseqüentes das regras durante a inferência
Fuzzy
.
O processo inverso do anterior, ou seja, a determinação de um valor numérico (
crisp
) a
partir de um conjunto
Fuzzy
, resultante de uma agregação, caracteriza a desfuzzyficação, para a
qual o DALF-MCC se utiliza da Equação G.2.
)(
).(
Ci
UC
CiCi
UC
A
Ax
S
Ci
Ci
∈∀
∈∀
∑
∑
=
G.2
Onde:
• S é o valor numérico de saída (valor
crisp
);
• é a área de cada subconjunto
Fuzzy
, que compõe um conjunto
Fuzzy
C, resultante de
um processo de agregação, em um universo de discurso U;
Ci
A
• é o baricentro geométrico de cada elemento ;
Ci
x
Ci
A
Para o cálculo da área de cada subconjunto
Fuzzy
presente na Equação G.2, o DALF-
MCC utiliza a Equação G.3, incluída na Figura G.3, para todos os casos permitidos de
parametrização dos termos primários.
Limite
Limite
Núcleo
μ
Suporte
U
μ = 1
A Equação G.3 se aplica a todas as parametrizações possíveis feitas pelo usuário, tais
como: retângulos, quadrados, trapézios regulares ou irregulares e triângulos (b = 0). Incluindo
termos primários cortados (0 < α-cut ≤ 1) resultantes de um processo de fuzzyficação.
G.1.2 Interface com o Usuário
O propósito deste item é elucidar os principais aspectos da interface com o usuário do
DALF-MCC, a qual estrutura e conduz a metodologia proposta, tanto na fase de análise dos pré-
requisitos quanto na fase de auditoria.
A tela inicial do DALF-MCC (Menu Início), mostrada na Figura G.4, aborda seus
aspectos gerais e objetivos. Nesta tela estão disponíveis
hiperlinks
, que dão acesso a área de ajuda.
μ = 0
Altura (h)
Base Maior (B)
Base Menor (b)
2
).(
hbB
A
Ci
+
=
Equação G.3
Figura G.3 – Determinação da Área
Ci
A
da Equação G.2.
304
A ajuda trata-se de um arquivo HTML, com
hiperlinks
internos, o qual esclarece os principais
conceitos inerentes à metodologia proposta, seu domínio de conhecimento e os pontos passíveis
de dúvidas por parte do usuário.
Figura G.4 – Tela Inicial do DALF-MCC (Menu Início).
Na análise dos pré-requisitos, as características e necessidades da empresa e do sistema no qual a MCC será
implantada são confrontados com os requisitos exigidos pelo Procedimento de Referência, adotado por este
trabalho, para implantação da MCC. Como resultado deste processo, tem-se um relatório de diagnóstico
ponderando, a aptidão ou não da empresa/sistema, para implementar a etapa sob análise.
toria, os atributos de cada etapa são comparados com aqueles do procedimento de referência, adotado
por este trabalho, e de outros procedimentos normatizados ou de consenso entre os especialistas em MCC.
Como resultado deste processo, tem-se um relatório de diagnóstico ponderando se a equipe está apta ou não,
guir com o processo de implantação da MCC.
Para apoio a implementação, o DALF-MCC propõe soluções para auxiliar o processo decisório durante a
ementação de algumas etapas, as quais são importantes para o sucesso do programa de MCC. As soluções
adas contemplam as etapas 3 a 5 do procedimento de referência.
A metodologia proposta será orientada por um SBC Fuzzy
Na audi
para se
impl
apresent
(Sistema Baseado em Conhecimento - Fuzzy) que
incorpora critérios para diagnóstico e tomada de decisão, ponderando aspectos inerentes à Gestão do
Conhecimento.
O objetivo do DALF-MCC
(Diagnóstico Auxiliado por
Lógica Fuzzy para a Manutenção Centrada na
Confiabilidade) é auxiliar a implantação e a gestão da
MCC, tratando as incertezas do processo de análise e
tomada de decisão. As funcionalidades do DALF-MCC,
para cada etapa da MCC, incluem: Análise dos Pré-
Requisitos, Auditoria e Apoio a Implementação.
Informações para o usuário
com
hiperlinks
para arquivo de
ajuda em HTML.
O arquivo de ajuda detalha os
p
rincipais conceitos e termos
utilizados no DALF-MCC.
Na tela de identificação e caracterização da empresa do DALF-MCC (Menu Empresa),
mostrada na Figura G.5, o usuário pode inserir os dados gerais da empresa, as datas e os responsáveis
pelos estudos, anterior e atual, desenvolvidos pelo DALF-MCC bem como as observações gerais que
julgue necessárias. Estes dados irão compor o relatório final do DALF-MCC (cabeçalho do relatório),
tanto para a fase de análise dos pré-requisitos quanto para a fase de auditoria.
Para incorporar a incerteza por imprecisão (léxica), ambos, critérios e quesitos, serão
tratados como variáveis lingüísticas
Fuzzy
, cujos termos primários compõem a avaliação de cada
etapa (pré-requisitos e auditoria). Estas variáveis lingüísticas são configuradas na tela de
Parametrização
Fuzzy
do DALF-MCC (Figura G.6).
Figura G.5 – Tela de Identificação e Caracterização da Empresa (Menu Empresa).
Dados gerais da Empresa.
Data e Responsáveis pelo
estudo atual e anterior.
Observações gerais que o
usuário julgar necessárias.
Informações e instruções para
o usuário.
eencha os campos solicitados e se desejar inclua as observações que julgar necessárias no campo
ações Gerais”. Estas informações irão compor o relatório de Análise dos Pré-Requisitos e de Auditoria
a etapa analisada, conforme o Procedimento de Referência proposto para implantação da MCC.
Obs.:
Pr
“Observ
de cad
305
O DALF-MCC
Os dados inseridos na tela de Parametrização
Fuzzy
são utilizados para a ponderação de
todos os quesitos, os quais compõem os critérios que servirão de base para avaliação dos pré-
requisitos e auditoria de todas as etapas do procedimento de implantação da MCC. Para proceder
à modificação dos termos primários o usuário deve: escolher a variável lingüística a ser
modificada (Ruim, Baixa, Boa, Alta ou Ótima); alterar seus valores (X0, X1, X2, X3), conforme
desejado; e, uma vez estabelecida a parametrização desejada para cada termo primário, clicar no
botão atualizar. Conforme enfatizado no Capítulo 5 o processo de parametrização deve ser
conduzido por um especialista em MCC e no domínio da aplicação. O conhecimento/experiência
deste especialista servirá de base para a definição das funções de pertinência, as quais definirão os
termos primários e, assim duas situações poderão ocorrer:
1. A parametrização é concebida de forma condizente com o domínio da aplicação e, neste
caso, a ponderação dos quesitos irá, indiretamente, retratar o grau de maturidade e
aderência da empresa quando comparada com outras do mesmo domínio de aplicação;
2. A parametrização retrata o consenso entre o(s) especialista(s) e os membros da equipe de
implementação, levando em conta as especificidades da aplicação.
Em ambas as situação a parametrização deve ser conhecida pelos usuários para que a
ponderação dos quesitos retrate, da maneira mais íntegra possível, a realidade da empresa/sistema.
Na tela de ponderação dos pré-requisitos (Figura G.7) e auditoria (Figura G.8) o usuário
atribui uma nota ou um conceito para cada quesito submetido a análise, sendo que: a nota deve estar
dentro do universo de discurso configurado na tela de parametrização
Fuzzy
(no DALF-MCC o
universo de discurso poderá assumir qualquer intervalo entre 0 e 10); e o conceito poderá ser
qualquer um dos termos primários
Fuzzy
disponíveis (Ruim, Baixa, Boa, Alta ou Ótima). A
conjunção de nota e conceito possibilita ao usuário utilizar-se do mecanismo que lhe seja mais
Figura G.6 – Tela de Parametrização (Menu Parametrização Fuzzy).
avalia os pré-requisitos e faz a auditoria de cada etapa da MCC segundo determinados critérios, os quais possuem
quesitos a serem ponderados. O responsável pela análise deverá ponderar cada quesito com uma nota (0 a 10) ou um conceito
(Ruim, Baixa, Boa, Alta ou Ótima), referente à aderência de sua empresa ou sistema àquele quesito sob análise.
A nota ou conceito, atribuído a cada quesito, serão avaliados por um SBC Fuzzy
Informações e
instruções para o
usuário com
hiperlinks
para
arquivo de ajuda
em HTML.
. As variáveis lingüísticas, referentes à partição
do conjunto Fuzzy, as quais serão utilizadas no processo de análise podem ser parametrizadas abaixo.
O gráfico abaixo mostra valores pré-parametrizados “default”, que representam valores médios de consenso entre especialistas em
MCC. Caso estes valores estejam adequados, para a empresa ou sistema a ser analisado, siga para a próxima etapa da metodologia
(Análise dos Pré-Requisitos, Auditoria ou Apoio a Implementação).
Caso a parametrização, mostrada no gráfico abaixo, não esteja adequada para a empresa ou sistema específico a ser analisado,
altere sua parametrização utilizando os campos ao lado do gráfico, procedendo da seguinte maneira:
1) Escolha a variável lingüística a ser modificada (Ruim, Baixa, Boa, Alta ou Ótima);
2) Altere seus valores (X0, X1, X2, X3), conforme desejado;
3) Estabelecida a parametrização desejada, para cada variável lingüística, clique no botão Atualizar.
Conjunto
Fuzzy
atual “
default
”
Parametrização
dos Termos
Primários
306
intuitivo para a ponderação dos quesitos. Como resultado desse processo se espera obter uma
ponderação que espelhe a realidade da empresa/sistema, da maneira mais confiável possível.
Figura G.7 – Tela de Ponderação dos Pré-Requisitos (Menu Pré-Requisitos).
Critérios para
avaliação da etapa
Ponderação com nota
ou conceito e acesso
ao arquivo de ajuda
Quesitos a serem Ponderados pelo usuário
Avaliação
da etapa
Critérios avaliados e nota
resultante
Avaliação
do critério
Q1
Q2
Q3
Q4
– Todas as Entradas, Controles e Mecanismos da Etapa 0 (Adequação da MCC), do
procedimento de referência para implantação da MCC, estão disponíveis.
– Existe uma documentação consistente das ações de manutenção.
– Os sistemas candidatos a implantação da MCC possuem uma documentação técnica
adequada.
– O planejamento estratégico da empresa, com relação à manutenção, está documentado
de forma auditável.
onibilidade da
rmação/Recursos
Disp
Info
Condição e Desempenho
Atual da Manutenção
Sistema Computacional
de Suporte
Cultura da
Manutenção/Empresa
Gerenciamento Estratégico
da Manutenção
Somente após ponderar todos os quesitos que compõem um critério, o usuário poderá
solicitar uma avaliação do respectivo critério (botão inferior direito das telas de análise de pré-
requisitos e auditoria). Os critérios avaliados e as respectivas notas obtidas aparecem na parte
inferior das telas de análise de pré-requisitos e auditoria. Cada quesito tem associado a ele um
botão de ajuda (lado direito dos campos de ponderação) que dá acesso a explicações
pormenorizadas de cada quesito para que o usuário possa balizar sua ponderação. Avaliados todos
os critérios da etapa, o usuário poderá solicitar a avaliação da respectiva etapa (botão inferior
esquerdo das telas de análise de pré-requisitos e auditoria).
Figura G.8 – Tela de Ponderação para Auditoria (Menu Auditoria).
Critérios para
avaliação da etapa
Ponderação com nota
ou conceito e acesso
ao arquivo de ajuda
Avaliação
da etapa
Critérios avaliados e nota
resultante
Avaliação
do critério
Confiabilidade
da Análise
Q1 –
Q2 – T
Q3 –
Q4 –
Q5 –
Os pré-requisitos desta etapa foram atendidos, em um nível satisfatório, ou caso contrário, uma política de
melhoramento dos fatores negativos foi planejada e implementada antes do início da etapa. Obs.: Neste
quesito responda com a Nota obtida na análise dos Pré-Requisitos da Etapa 0 (Adequação da MCC).
odas as decisões, tomadas durante a Etapa 0 (Adequação da MCC), foram documentadas, atendem as
exigências de Saída do procedimento de referência, e tem consistência para uma auditoria futura.
Os questionamentos, referentes à análise dos Pré-Requisitos e Auditoria da Etapa 0 (Adequação da MCC), foram
ou estão sendo, respondidos por membros da equipe de manutenção, operação, gerência e demais interessados
ou afetados pelo programa de MCC, ou pelos sistemas candidatos a sua implantação. A tomada de decisão se deu
pela média ponderada das respostas individuais.
Normas, bibliografias e especialistas foram consultados para avaliar os benefícios e os desafios de um
programa de MCC.
Programas similares de MCC foram consultados/estudados e poderão servir de benchmark para o processo
de implantação.
Quesitos a serem Ponderados pelo usuário
307
Para as etapas avaliadas, o DALF-MCC gera um relatório (acessado através do menu
Resultados e Conclusões) contendo as ponderações do usuário e os desdobramentos do processo
de inferência
Fuzzy
incluindo seus resultados e conclusões. O próximo item mostra em detalhes o
conteúdo dos relatórios de análise dos pré-requisitos e auditoria desenvolvidos pelo DALF-MCC.
G.1.3 Resultados e Conclusões do Processo de Inferência
Os resultados e conclusões do processo de inferência
Fuzzy
são condensados em um
relatório, o qual está dividido nas seguintes seções: cabeçalho; resultados, conclusões e sugestões
referentes à Avaliação da Etapa; e resultados, conclusões e sugestões referentes à Avaliação dos
critérios e seus respectivos quesitos.
O Cabeçalho mostra os dados que foram inseridos na tela de identificação e caracterização
da empresa do DALF-MCC (Menu Empresa). Os dados que compõem o Cabeçalho são mostrados
em todos os relatórios, tanto para a fase de análise dos pré-requisitos quanto para a fase de auditoria.
A Figura G.9 mostra um Cabeçalho genérico preenchido com os dados esperados em cada campo.
Figura G.9 – Relatório (Cabeçalho Pré-Requisitos e Auditoria).
Dados Gerais
Nome da Empresa: Nome da Empresa/Sistema onde a MCC será Implantada
Endereço: Endereço da Empresa/Sistema onde a MCC será Implantada
Data do Estudo Atual: Data Atual de Avaliação da Etapa
Responsável pelo Estudo Atual: Nome do Responsável pela Avaliação Atual da Etapa
Data do Estudo Anterior: Data Anterior de Avaliação da Etapa
Responsável pelo Estudo Anterior: Nome do Responsável pela Avaliação Anterior da Etapa
Observações Gerais: Quaisquer Observações que o Usuário Julgar Necessárias
Dados inseridos pelo
usuário na tela de
Identificação e
Caracterização da
Empresa (Menu Empresa)
Na parte do relatório referente aos resultados e conclusões relativas à avaliação da etapa, os
seguintes dados são submetidos ao usuário para auxiliar sua tomada de decisão: os conjuntos
Fuzzy
relativos à avaliação dos critérios, formados após a agregação referente à ponderação dos quesitos,
com suas respectivas notas resultantes desfuzzyficadas; o conjunto
Fuzzy
relativo à avaliação da
etapa sob análise, formado após a agregação dos conjuntos
Fuzzy
referentes à avaliação dos
critérios, com sua respectiva nota resultante desfuzzyficada; as conclusões e sugestões do SBC-
Fuzzy
relativas ao resultado final de avaliação da etapa sob análise. A Figura G.10 mostra os
resultados da avaliação dos pré-requisitos da Etapa 0, a partir da ponderação dos quesitos
conforme ilustrado no Capítulo 6.
Após a avaliação da etapa, o relatório mostra os resultados, conclusões e sugestões
referentes à avaliação dos critérios e a ponderação de seus respectivos quesitos. A Figura G.11
mostra os resultados da avaliação do Critério 3 da Etapa 0, a partir da ponderação de seus quesitos
conforme ilustrado no Capítulo 6.
308
Conjuntos
Fuzzy
resultantes da
avaliação dos
critérios e da etapa
sob análise
Resultados da
inferência Fuzzy:
Conclusões e
sugestões para o
usuário devidas a
avaliação da etapa
sob análise
a Nota Final de avaliação da Etapa 0 - Adequação da MCC nos patamares atuais (5 < Nota < ou = 7) a MCC É VIÁVEL para esta empresa/sistema,
a política de treinamento na metodologia de MCC deve ser considerada para maximizar os resultados do programa de MCC.
críticos apresentados na seção de resultados, tanto na ponderação dos Quesitos quanto na avaliação dos critérios, devem ser trabalhados internamente
a para propiciar um ambiente adequado para uma implementação futura da MCC. As seguintes referências podem auxiliar a condução deste processo:
ND
Com um
porém um
Os pontos
na empres
BACKLU
, Fredrik, Managing the Introduction of Reability Centred Maintenance.
Os dados constantes nesta parte do relatório (avaliação dos critérios e seus quesitos)
explicitam o processo de inferência que resultou na avaliação da etapa e as conseqüentes conclusões
e sugestões para o usuário. Os seguintes dados são submetidos ao usuário para auxiliar sua tomada
de decisão: os quesitos, os quais foram ponderados pelo usuário para avaliação do critério; os
conjuntos
Fuzzy
relativos à ponderação dos quesitos, com suas respectivas notas ou conceitos
atribuídos pelo usuário; o conjunto
Fuzzy
relativo à avaliação do critério sob análise, formado após
a agregação dos conjuntos
Fuzzy
referentes à ponderação dos quesitos, com sua respectiva nota
resultante desfuzzyficada; as conclusões e sugestões do SBC-
Fuzzy
, com seus respectivos graus de
pertinência, relativas à ponderação dos quesitos feita pelo usuário; e as conclusões e sugestões do
SBC-
Fuzzy
, relativas ao resultado final de avaliação do critério sob análise.
Resultados semelhantes aos exemplificados nos parágrafos precedentes, em formato e
funcionalidade, são obtidos nos relatórios relativos à avaliação dos pré-requisitos e auditoria de
todas as etapas que compõem o procedimento de referência, incorporado ao DALF-MCC.
Portanto, além dos resultados da desfuzzyficação, o DALF-MCC inclui: subsídios que auxiliam a
tomada de decisão e a gestão do conhecimento inerente aos
atributos atuais da empresa e sua
relação com as necessidades e fatores críticos de sucesso da MCC;
explicação sobre o processo
de inferência que culminou com as conclusões e sugestões apresentadas; comentários, conclusões e
sugestões referentes à aderência ou não da empresa às necessidades da MCC; e recomendações para
ações futuras com base na situação atual da empresa/sistema.
BLOOM, Neil B., Reliability Centered Maintenance: Implementation Made Simple.
FUENTES, Fernando Félix Espinosa, Metodologia para Inovação da Gestão da Manutenção Industrial.
Y
MOUBRA , J., Reliability Centered Maintenance.
A
SIQUEIR , Iony Patriota de. Manutenção Centrada na Confiabilidade: Manual de Implementação.
SMITH, Anthony M. e HINCHCLIFFE, Glenn R., RCM: Gateway to World Class Maintenance.
Figura G.10 – Relatório (Avaliação da Etapa 0).
309
Figura G.11 – Relatório (Etapa 0 – Critério 3).
Quesitos que
foram
ponderados pelo
usuário
Conjuntos
Fuzzy
resultantes da
ponderação dos
quesitos feita
pelo usuário
Resultados da
inferência
Fuzzy
:
respostas para o
usuário devidas
a ponderação
dos quesitos
Resultados da
inferência
Fuzzy
:
respostas para o
usuário devidas
a avaliação do
critério
critério 3: Sistema Computacional de Suporte
Quesitos Ponderados
Q1 – Para auxiliar a implantação do programa de MCC, um sistema computacional de automação de escritório estará disponível com as seguintes funcionalidades: desenho técnico,
processamento de texto, banco de dados e planilhas eletrônicas.
Q2 – Existe um sistema de gestão da informação integrado, implantado na empresa, que atende de forma satisfatória as necessidades do setor/equipe de manutenção.
Q3 – A gestão da manutenção conta com um sistema computacional adequadamente dimensionado, para o tamanho da empresa e do sistema que se quer implantar a MCC.
Q4 – O sistema computacional de gestão da manutenção é de uso amigável, toda a equipe possui treinamento adequado para utilizá-lo, e sua utilização faz parte da rotina de trabalho
da equipe de manutenção.
Q5 – O sistema computacional de gestão da manutenção permite integração com softwares específicos de implantação e gestão da MCC ou, caso contrário, conta com no mínimo as
seguintes funcionalidades: inclusão de novas tarefas com períodos customizados; controle estatístico da manutenção; e agrupamento de tarefas de manutenção de forma otimizada.
Resultados da Inferência Fuzzy – Ponderação dos Quesitos
Et_0_C3_Q1_Boa Grau de Pertinência: 1
Quanto à automação de escritório, a implantação da MCC não exige muitos recursos, bastam os programas tradicionais de processamento de texto, planilhas eletrônicas e banco de
dados. Para padronizar a análise a empresa pode adotar softwares específicos para implantação da MCC.
Neste caso uma aderência BOA a este Quesito, está adequada para a implantação da MCC, porém uma análise mais aprofundada, das funcionalidades e recursos computacionais
disponíveis, deve ser conduzida para o caso da implantação da MCC em sistemas de elevada complexidade.
Et_0_C3_Q2_Ruim Grau de Pertinência: 0.200
A MCC é muito dependente de um sistema de gestão da informação implantado na empresa para apoio a manutenção.
Neste caso uma aderência RUIM a este Quesito, indica que a adequação do sistema de gestão de informação, está muito abaixo da desejada, e pode inviabilizar a implantação da MCC,
especialmente para sistemas muito complexos.
Et_0_C3_Q2_Baixa Grau de Pertinência: 0.800
A MCC é muito dependente de um sistema de gestão da informação implantado na empresa para apoio a manutenção.
Neste caso uma aderência BAIXA a este Quesito, indica que o sistema de gestão da informação é pouco adequado e pode inviabilizar a implantação da MCC, especialmente para
sistemas muito complexos.
Et_0_C3_Q3_Baixa Grau de Pertinência: 1
A MCC baseia suas decisões em dados estatísticos de falhas, assim, pode haver benefícios para o programa de MCC caso Sistemas Computacionais de Gestão da Manutenção já tenham
sido introduzidos e/ou são utilizados na empresa para gestão da manutenção.
Neste caso uma aderência BAIXA a este Quesito indica que os sistemas computacionais de gestão da manutenção estão pouco adequados, o que pode ser prejudicial para o programa de
MCC ou exigir um treinamento mais detalhado da equipe de manutenção.
Et_0_C3_Q4_Baixa Grau de Pertinência: 0.500
Os sistemas computacionais de apoio a MCC, tanto na fase de implantação como na fase de execução, só serão efetivos se a equipe de manutenção tem afinidade com os mesmos e o
seu uso está incorporado em suas práticas diárias, o que pressupõe que tal sistema deva ser uso amigável.
Neste caso uma aderência BAIXA a este Quesito indica pouca afinidade da equipe de manutenção com os sistemas computacionais de gestão da manutenção, o que pode ser prejudicial
ao programa de MCC. Recomenda-se um programa de treinamento e conscientização dos mantenedores, o qual deve preceder a implantação da MCC.
Et_0_C3_Q4_Boa Grau de Pertinência: 0.500
Os sistemas computacionais de apoio a MCC, tanto na fase de implantação como na fase de gestão, só serão efetivos se a equipe de manutenção tem afinidade com os mesmos e o seu
uso está incorporado em suas práticas diárias, o que pressupõe que tal sistema deva ser uso amigável.
Neste caso uma aderência BOA a este Quesito está aceitável para a implantação da MCC, restando apenas manter um programa permanente de treinamento e conscientização dos
mantenedores para uso de tais recursos computacionais.
Et_0_C3_Q5_Alta Grau de Pertinência: 1
Para facilitar e garantir as boas práticas na condução do programa de MCC, o software utilizado na gestão da manutenção deve ter as funcionalidades mínimas exigidas pela
metodologia MCC. Caso contrário o mesmo deve permitir a integração com softwares específicos para gestão da MCC, garantindo assim, a padronização, realimentação e customização
do programa de MCC, dentro dos padrões vigentes.
Neste caso uma aderência ALTA a este Quesito indica uma adequação elevada entre as funcionalidades do software atual utilizado para gestão da manutenção e as necessidades da
MCC. Este resultado pressupõe funcionalidades adequadas, do sistema computacional atual de gestão da manutenção, para manter a padronização, realimentação e adequação, do
programa de MCC, aos padrões vigentes.
Resultados da Inferência Fuzzy – Avaliação do critério 3
Está é uma Análise Parcial, que depende de outros critérios para avaliação desta Etapa.
Uma Nota Final de avaliação para a Etapa 0 - critério 3 (Sistema Computacional de Suporte) nos patamares atuais (3 < Nota < ou = 5) demonstra que a empresa/sistema ESTÁ POUCO
PREPARADA para a implantação da MCC.
Com base neste critério a implantação da MCC é POUCO VIÁVEL. As funcionalidades e a abrangência, do Sistema Computacional da empresa, como ferramenta de suporte à gestão
da manutenção, e a afinidade dos mantenedores com sua utilização, estão com um nível de aderência no limite do aceitável, para uma implantação adequada e efetiva de um programa
de MCC. A implantação da MCC pode exigir treinamento, mudanças internas e investimentos consideráveis, para garantir o sucesso do programa de MCC. Sugere-se neste caso uma
revisão do cronograma de implantação da MCC, para melhoria prévia dos Quesitos, nos quais sua ponderação revelou pouca aderência da empresa/sistema.
G.2 OPEN-FMECA
Este item apresenta informações complementares, àquelas presentes no Capítulo 6,
referentes ao OpenFMECA, um software para auxiliar o uso da técnica FMECA desenvolvido
para ser instalado em um servidor e utilizado via navegador de internet (
browser
).
310
G.2.1 Interface e Estrutura do OpenFMECA
A estrutura de tabelas e informações relativas à FMECA, utilizada no OpenFMECA,
segue as recomendações da SAE J1739. A tela de abertura (
home
), ilustrada na Figura G.12, está
dividida em 3 seções: Apresentação, Sistemas, e Configurações.
Na seção “Configuração” pode-se fazer a seleção das pessoas que farão parte da equipe de
cada FMECA e também estipular a faixa de valores dos índices de Severidade (S), Ocorrência (O)
e Detecção (D), conforme ilustrado na Figura G.13. Adicionalmente, é possível alterar os limites
dos índices que compõem o NPR a fim de dar mais peso a um determinado atributo, por exemplo:
Severidade variando de 1 a 20, Ocorrência variando de 1 a 10 e Detecção variando de 1 a 5, o que
resultaria em um peso relativo de 4 para 2 para 1, respectivamente. Caso se deseje cadastrar um
novo participante das FMECA’s existentes, pode-se fazê-lo a partir do botão “Cadastrar Pessoa”,
ilustrado na Figura G.14.
Na seção “Sistemas – Elaboração da FMECA” seleciona-se o sistema que se deseja analisar
ou cria-se um novo sistema. Uma vez selecionado, pode-se abrir a FMECA do sistema na mesma ou
em uma nova aba do navegador. A Figura G.15 ilustra uma tela de FMECA de um sistema exemplo.
Figura G.12 – Tela de Apresentação do OpenFMECA.
Figura G.13 – Tela de Configurações do OpenFMECA.
311
O primeiro passo da seção “Sistemas”, no OpenFMECA, é o desdobramento do sistema
em subsistemas até a resolução desejada. Para tanto, utiliza-se a opção “Novo Subsistema” na
barra lateral direita. Pode-se, então, incluir os possíveis Modos de Falha (MF) dos subsistemas
que estão no último nível do desdobramento. Desta forma, a FMECA é elaborada no formato de
árvore, o que melhora a visualização e o entendimento.
O passo seguinte é a inclusão dos possíveis efeitos e causas de cada modo de falha, para cada
subsistema. As opções apresentadas na barra lateral são adaptadas ao contexto. Quando selecionado
um modo de falha, por exemplo, exibem-se opções como “Avaliar” e “Reavaliar” índices, enquanto
que, no caso de se selecionar um subsistema, apresentam-se opções como “Relatório
Standard
” e
“Relatório Descritivo”, situações ilustradas nas Figuras G.15 (a) e (b), respectivamente.
Figura G.14 – Tela de Inclusão de Participante na Base de Dados do OpenFMECA.
O passo seguinte é a determinação dos índices que irão compor a criticidade. Para tanto,
seleciona-se a opção “Índices → Avaliar” na barra lateral (Figura G.15 a) e uma nova aba abrirá com
campos para serem preenchidos com as estimativas dos índices, conforme ilustrado na Figura G.16.
(a) Modo de Falha (b) Subsistema
Figura G.15 – Tela de Elaboração da FMECA (Exemplo Disjuntor).
Figura G.16 – Tela de Avaliação de Índices.
312
Assim que os índices de severidade, ocorrência e de detecção forem inseridos, o
OpenFMECA
apresentará o valor do NPR. Pode-se, então, incluir as ações que deverão ser tomadas
para a redução do NPR. Na opção “Nova Ações”, disponível quando se seleciona uma causa, pode-
se inserir, além da descrição da ação, o responsável, a data limite para a execução e a estimativa de
custo. Selecionada uma determinada causa, pode-se também incluir como está sendo feita a
detecção usando a opção “Novo Controle Atual”. Adicionalmente, pode-se gerenciar o cadastro de
Efeitos, Controles Atuais e Plano de Ações. Esses elementos da FMECA devem ser cadastrados no
OpenFMECA para serem atribuídos a um determinado modo de falha. Assim, nestas seções pode-se
excluir, substituir ou modificar elementos existentes ou criar novos (Figura G.17).
(a) Gerenciamento de Ações (b) Gerenciamento de Controles Atuais
Figura G.17 – OpenFMECA: Gerenciamento de Ações e Controles Atuais.
Pode-se rever a estimativa dos valores dos índices, após a implementação do plano de ações,
na opção “Índices → Reavaliar” (Figura G.15), o que resultará na tela mostrada na Figura G.18.
Figura G.18 – Tela de Reavaliação de Índice.
Quanto aos relatórios, gerados pelo OpenFMECA, a versão atual disponibiliza: a Tabela
STD, que é a usual da FMECA, baseada na estrutura apresentada na SAE J1739; e o Relatório
Descritivo de cada elemento que compõem a FMECA. Situações ilustradas nas Figuras G.19 (a) e
(b), respectivamente.
Além de servir aos propósitos deste trabalho e do NEDIP, o OpenFMECA estará disponível
em uma página criada no sítio SourceForge.net (
http://sourceforge.net/), o que viabilizará um canal
de relato de problemas (
bugs
) e sugestões de melhorias na interface e no código.
313
(a) Relatório em Tabela STD (SAE J1739)
(b) Relatório descritivo
Figura G.19 – Relatórios OpenFMECA.
G.3 FMECA-DELPHI
Este item apresenta informações complementares, àquelas presentes no Capítulo 6, referentes
ao FMECA-Delphi, um software que utiliza a técnica Delphi para elicitação do Número de Prioridade
de Risco (NPR) com especialistas não presenciais, cooperando em um ambiente virtual.
G.3.1 Interface e Estrutura do FMECA-Delphi
Para proporcionar uma comunicação mais eficiente entre os especialistas e o moderador da
FMECA, foi implementada uma página na internet para que cada especialista pudesse expressar sua
opinião quanto aos índices que compõem a avaliação da criticidade, seguindo a estrutura do método
proposto. A página foi desenvolvida em PHP, JavaScript (biblioteca XAJAX) e MySQL e permite
que cada usuário tenha um ambiente individualizado, a Figura G.20 ilustra a tela de
login
.
Figura G.20 – Tela de
Login
do FMECA-Delphi.
314
Cada especialista tem, no respectivo ambiente, a possibilidade de consultar textos sobre: o
método proposto; a técnica FMECA; e sobre o sistema técnico em análise. Adicionalmente, o
especialista é solicitado a preencher suas informações profissionais, mostradas na Figura G.21,
destacadamente o tempo de experiência, o qual será utilizado no cálculo dos índices.
Figura G.21 – Tela do Formulário Sobre o Especialista.
O usuário poderá, então, iniciar o preenchimento dos campos da FMECA referentes à
primeira iteração do método. A Figura G.22 ilustra esse processo, na qual os campos destacados
em amarelo evidenciam que o especialista ainda não entrou com uma estimativa para o valor do
respectivo índice ou grau de confiança.
Ao final do prazo para a execução da primeira iteração, o moderador, que tem um ambiente
distinto, poderá verificar as estatísticas dos índices (S, O, D e GC), no relatório “Tabela Geral 1”
Figura G.22 – Tela da Primeira Iteração.
315
e, posteriormente, definir o próximo passo do processo, selecionando o botão de opções
“Informações” e pressionando o botão de ação “Definir” (Figura G.23).
Figura G.23 – Tela do Relatório da Primeira Iteração.
Na próxima vez que o usuário entrar na página do FMECA-Delphi, a barra lateral
esquerda apresentará como única opção da seção “Elicitação dos Índices”, a ligação para
“Informações Adicionais”, conforme observado na Figura G.24. Na tela de Informações
Adicionais, o especialista é orientado a expor as informações em que se baseou na avaliação dos
índices destacados na cor Vermelha, os quais são as estimativas feitas por ele que ficaram fora da
faixa de um desvio padrão, abaixo ou acima da média. O especialista tem liberdade de incluir
informações sobre os índices que achar conveniente, no entanto, solicita-se que, no mínimo, entre
com as informações referentes aos índices destacados em vermelho.
Figura G.24 – Tela de Coleta de Informações Adicionais.
316
Para inserir informações adicionais, o especialista deve selecionar a caixa de texto
referente a um determinado índice, ao qual deseja inserir informações, e preenchê-las na caixa de
texto disposta na parte inferior da tela. Após a inclusão da justificativa, o índice passará a ser
destacado na cor verde.
Ao final do prazo para inclusão das informações adicionais, o moderador poderá verificar
o resultado deste processo no relatório “Informações” (Figura G.25). Nesta tela o moderador tem
acesso a todas as informações coletadas e pode editá-las em uma caixa de texto na parte inferior
da coluna referente ao respectivo índice. Após entrar com os textos, o moderador define o
próximo passo do processo, selecionando a opção “2ª Iteração” e pressionando o botão “Definir”.
Figura G.25 – Tela do Relatório das Informações Adicionais.
Por fim, o especialista é solicitado a reavaliar os valores atribuídos a cada índice podendo,
inclusive, reavaliar todas as estimativas (Figura G.26). No entanto, solicita-se que o especialista se
atenha, no mínimo, aos índices destacados em vermelho, os quais foram estimados fora da faixa de
um desvio padrão abaixo e acima da média.
Os índices destacados em amarelo indicam que há alguma informação relevante
disponível e, apesar da avaliação inicial se encontrar dentro da faixa central, recomenda-se
atenção às informações coletadas e, caso o especialista considere apropriado, pode reavaliar a
estimativa da primeira iteração. Ao selecionar a caixa de texto referente a um determinado índice
que se deseja reavaliar, informações adicionais editadas pelo moderador são apresentadas e as
estatísticas referentes ao índice, dispostas na parte inferior da tela. É possível, também, alterar o
valor do Grau de Confiança de cada avaliação dos índices.
317
Figura G.26 – Tela da Segunda Iteração.
O especialista tem, ainda, a possibilidade de verificar os valores que atribuiu a cada índice
nas duas iterações, no relatório “Tabela Individual”, ilustrado na Figura G.27.
Figura G.27 – Tela do Relatório Individual do Especialista.
Uma vez finalizada a segunda e última iteração, o moderador tem condição de retirar do
relatório “Tabela Geral 2” os valores das estimativas dos índices e dos respectivos graus de confiança.
De posse destes valores, pode-se calcular a estimativa de cada índice, utilizando a Equação 7.1.
318
G.4 NPR-FUZZY
Este item apresenta informações complementares, àquelas presentes no Capítulo 6, referentes
ao NPR-Fuzzy, um software para avaliação do NPR que utiliza a lógica
Fuzzy
como ferramenta
de apoio a tomada de decisão e tratamento das incertezas inerentes.
G.4.1 Interface e Estrutura do NPR-Fuzzy
O NPR-Fuzzy utiliza a máquina de inferência do FuzzyClips e sua interface foi
desenvolvida em
Visual Basic
, nos mesmos moldes do DALF-MCC.
A tela inicial do NPR-Fuzzy (Menu Início), mostrada na Figura G.28, aborda os aspectos
gerais do software e seus objetivos. Nesta tela estão disponíveis
hiperlinks
, os quais dão acesso a
área de ajuda do NPR-Fuzzy. A ajuda é um arquivo HTML com
hiperlinks
internos, o qual
esclarece os principais conceitos inerentes à metodologia proposta, seu domínio de conhecimento
e os pontos passíveis de dúvidas por parte do usuário.
Figura G.28 – Tela Inicial do NPR-Fuzzy.
Este software (NPR-Fuzzy) se originou de uma necessidade da MCC detectada durante a fase
de elicitação do conhecimento do DALF-MCC
. Seu objetivo é determinar o NPR (Número de
Prioridade de Risco), utilizado na concepção da FMECA (Etapa 3 do processo de implantação
da MCC
) para comparar itens e assim priorizar ações corretivas para os casos mais críticos.
O NPR-Fuzzy
A tela de Parametrização e Ponderação (Figura G.29), acessada através do menu de
mesmo nome, permite ao usuário: parametrizar os conjuntos
Fuzzy
a serem utilizados na
ponderação dos itens que compõe a avaliação do NPR (Severidade, Ocorrência e Detecção); e
proceder a ponderação destes itens para todas as causas do modo de falha sob análise. Esta tela
está dividida em 3 partes, a saber: Parametrização dos Conjuntos
Fuzzy
, Abrangência e
Considerações da Análise, e Ponderação para Avaliação da Criticidade (NPR):
Na Parametrização dos Conjuntos
Fuzzy
, o usuário pode, de forma independente,
parametrizar os termos primários que serão utilizados pelo NPR-Fuzzy para ponderar a
Severidade, a Ocorrência e a Detecção. Cada item dispõe de 5 termos primários cuja parametrização
determina o NPR a partir da agregação Fuzzy dos índices de Severidade (S) Ocorrência (O) e Detecção (D) e posterior
desfuzzyficação do conjunto Fuzzy resultante. Este método procura minimizar os inconvenientes decorrentes da multiplicação dos 3
índices (S.O.D), comumente utilizado nas abordagens tradicionais.
Os termos primários utilizados na abordagem proposta pelo NPR-Fuzzy para ponderação dos índices de compõem o NPR são mostrados
abaixo. Estes termos primários podem ser acessados e parametrizados a partir do menu Parametrização e Ponderação. Caso se deseje,
esta parametrização pode ser concebida em harmonia com as tabelas normatizadas
, propostas pela SAE J1739.
Severidade do Efeito (S) Probabilidade de Ocorrência da Falha (O) Chances de Detecção (D)
Pequena Remota Certa
Baixa Baixa Alta
Moderada Moderada Moderada
Alta Alta Remota
Muito Alta Muito Alta Muito Remota
319
deve seguir critérios de consenso do grupo de FMECA baseados em heurísticas e/ou tabelas
normatizadas (Ex.:
SAE J1739/2002).
Na parte relativa à Abrangência e Considerações da Análise, o usuário informa a
Quantidade de Causas (QC) que o modo de falha a ser avaliado possui e como será considerada
a análise da Severidade. Neste último caso, d
iferentemente da Ocorrência e da Detecção, as quais
estão vinculadas às causas, a Severidade está vinculada aos efeitos. Assim,
o usuário deve escolher
entre
2 situações, Global ou Individual, as quais serão mutuamente exclusivas, sendo que: na
análise
Global, o valor atribuído a Severidade é único para um determinado grupo de efeitos e, neste
caso, o usuário atribui a severidade média do grupo ou o valor correspondente ao efeito mais severo
(Obs.: esta última é considerada a escolha padrão “
default
”); na análise Individual, todos os efeitos
serão analisados, devendo o usuário atribuir um valor para cada efeito individualmente, e todos os
efeitos avaliados irão compor o conjunto
Fuzzy
resultante para a Severidade. Neste caso, o usuário
deverá informar o Número de Efeitos (NE) a serem analisados. O valor final da Severidade será
associado: ao conjunto
Fuzzy
formado pela composição de todos os efeitos; e ao valor
crisp
,
resultante da desfuzzificação do referido conjunto
Fuzzy
(Obs.: se o usuário escolhe esta opção o
Número de Efeitos (NE) padrão “
default
” é 1).
Figura G.29 – Tela de Parametrização e Ponderação do NPR-Fuzzy.
Concluídas as informações referentes à Abrangência e Considerações da Análise, o usuário
tem acesso, através do Botão Avançar, a parte de Ponderação para Avaliação da Criticidade (NPR).
Nesta fase, o usuário deve atribuir uma nota ou conceito, levando em conta que:
320
• No caso da Severidade, como esta se refere aos efeitos, se a opção escolhida anteriormente
foi Global, a atribuição de nota ou conceito acontecerá somente uma vez. Se a opção
escolhida anteriormente foi Individual, a atribuição de nota ou conceito se dará para cada
efeito. Neste caso, o Efeito sob análise varia de 1 até NE.
• No caso da Ocorrência, o usuário deve atribuir uma nota ou conceito ao quão provável
é a Ocorrência da causa sob análise, a qual varia de 1 até QC;
• No caso da Detecção, o usuário deve atribuir uma nota ou conceito referente as chances
(facilidade/dificuldade) de Detecção da causa sob análise, a qual varia de 1 até QC.
Em todos os casos os Botões “← →” servem para avançar ou retroceder na avaliação das
causas ou efeitos sob análise. Concluído o processo de ponderação, o Botão Avaliar gera o
relatório de avaliação do NPR do modo de falha sob análise (Figura G.30). O Botão Reiniciar
volta para a parte relativa à Abrangência e Considerações da Análise apagando todos os dados
inseridos na parte relativa à Ponderação para Avaliação da Criticidade (NPR).
Figura G.30 – Relatório de Avaliação do NPR-Fuzzy.
O relatório final gerado pelo NPR-Fuzzy é composto, para cada causa do modo de falha, de:
número da causa avaliada; conjuntos
Fuzzy
(Severidade, Ocorrência e Detecção) formados pela
ponderação dos efeitos e causas; conjunto
Fuzzy
resultante, para a Criticidade (NPR), formado pela
agregação dos conjuntos anteriores; e v
alores
crisp
, desfuzzificados para cada um dos conjuntos
anteriores. Na tela do
relatório final os Botões “← →” servem para navegação entre as causas.
G.5 DALF-DIAGRAMAS (ETAPA 4)
Este item apresenta informações complementares, àquelas presentes no Capítulo 6, referentes
ao DALF-Diagramas, um Sistema Baseado em Conhecimento
Fuzzy
(SBC-
Fuzzy
) que auxilia a
seleção e a caracterização das funções significantes listadas na Etapa 3, utilizando um processo de
inferência
Fuzzy
baseado na ponderação de quesitos.
321
G.5.1 Interface e Estrutura do DALF-Diagramas para a Etapa 4
O DALF-Diagramas divide a análise da Etapa 4 em 2 partes, a saber: a Parte 1 trata da
identificação/definição da significância ou não da função; e a Parte 2 trata da classificação das
conseqüências
dos modos de falha das funções significantes. As funcionalidades do DALF-
Diagramas, para a Etapa 4, são acessadas a partir da Tela de Abertura (Figura G.31) no menu
Arquivo → Novo → Função para a Parte 1 e Arquivo → Novo → Falha para a Parte 2.
Toda a
análise segue os requisitos e a sistemática proposta pela
IEC 60300-3-11, adotada pelo
procedimento de referência detalhado no Capítulo 5.
Este aplicativo foi incorporado ao DALF-MCC para apoiar a tomada de decisão da equipe de implantação da MCC durante a implementação das seguintes Etapas:
Etapa 4 - Seleção das Funções Significantes e Classificação de seus Modos de Falha
Etapa 5 - Seleção das Tarefas de Manutenção Aplicáveis e Efetivas
As seguintes funcionalidades estão disponíveis neste aplicativo:
• Definição/Identificação de Significância ou Não da Função;
• Classificação dos Modos de Falha das Funções Significantes;
• Determinação das Ações de Manutenção para Falhas ESA (Evidente / Segurança / Ambiental)
• Determinação das Ações de Manutenção para Falhas EEO (Evidente / Economico / Operacional)
• Determinação das Ações de Manutenção para Falhas OSA (Oculta / Segurança / Ambiental)
• Determinação das Ações de Manutenção para Falhas OEO (Oculta / Economico / Operacional)
PARA INICIAR SELECIONE: Menu ARQUIVO - Opção NOVO:
FUNÇÃO - Para Definição/Identificação de Significância ou Não da Função;
FALHA - Para classificação dos Modos de Falha das Funções Significantes;
ESA , EEO , OSA ou OEO - Para Determinar as Ações de Manutenção Aplicáveis e Efetivas.
O DALF_Diagramas utiliza em seu processo de inferência os diagramas de decisão propostos pela IEC 60300-3-11. Tais diagramas de decisão podem ser percorridos
em qualquer sentido, individualmente ou seqüencialmente.
O processo de inferência do DALF_Diagramas utiliza afirmações, sobre os tópicos a serem avaliados, que devem ser ponderadas pelo usuário com uma Nota ou um
Conceito (Fuzzy). Os termos primários das variáveis lingüísticas utilizadas (Conceitos) podem ser parametrizados individualmente a cada seção de inferência.
Todas as informações inseridas pelo usuário e os resultados do processo de inferência Fuzzy podem ser salvos e/ou recuperados a partir do Menu Arquivo.
O DALF_Diagramas emite relatórios em formato HTML, que contém textualmente e graficamente todas as informações e resultados pertinentes ao processo de inferência.
Adicionalmente os termos lingüísticos e os diagramas de decisão utilizados podem ser visualizados em tempo de execução (Menu - Ver).
Figura G.31 – Tela de Abertura do DALF-Diagramas.
Parte 1 – Identificação/Definição da Significância ou Não da Função
A tela de abertura da Parte 1 pode ser vista na Figura G.32. O DALF-Diagramas permite ao
usuário "percorrer", através dos botões de navegação e em qualquer sentido, cada uma das telas que
compõem o processo de inferência
Fuzzy
, inerentes ao respectivo diagrama de decisão. É possível
avançar ou retroceder (para rever uma ponderação – Figura G.32 à G.35a), neste caso, estando em
qualquer tela ou avançar por afirmação ou negação, nas telas finais do processo de inferência o que,
neste caso, significa concordar ou não com os resultados do DALF-Diagramas (Figura G.36a). Cada
tela possui, ainda, um botão que dá acesso a uma janela de ajuda sensível ao contexto da tela em pauta.
ETAPA 4 - PARTE 1: SELEÇÃO DAS FUNÇÕES SIGNIFICANTES
O objetivo da Etapa 4 - Seleção das Funções Significantes e Classificação de seus Modos de Falha é analisar
cada função identificada na Etapa 3 - Análise dos Modos de Falha seus Efeitos e sua Criticidade (FMECA),
e determinar se a falha funcional tem efeito significante, e caso afirmativo, classificá-la levando em conta
o impacto nos aspectos pilares da MCC: segurança, meio ambiente, operação e economia do processo.
O DALF_Diagramas divide a implementação da Etapa 4 em 2 partes a saber:
PARTE 1: SELEÇÃO DAS FUNÇÕES SIGNIFICANTES
PARTE 2:CLASSIFICAÇÃO DOS MODOS DE FALHA DAS FUNÇÕES SIGNIFICANTES
Observação: O DALF_Diagramas utiliza, para composição do procedimento de referência, a lógica
de seleção das funções significantes e classificação de seus modos de falha, proposta pela
IEC 60300-3-11 (Dependability Management - Part 3-11: Application Guide - Reliability Centred Maintenance).
Informações
para o usuário
Botões de
N
avegação
Ajuda
Figura G.32 – Tela de Abertura do DALF-Diagramas – Etapa 4 – Parte 1.
322
Avançando na tela inicial, o usuário tem acesso a tela de identificação e descrição da
função que se quer avaliar (Figura G.33).
Figura G.33 – Tela de Identificação e Descrição da Função.
Para incorporar a incerteza por imprecisão (léxica), os quesitos a serem ponderados pelo
usuário serão tratados como variáveis lingüísticas
Fuzzy
. Os termos primários destas variáveis são
configurados na tela de Parametrização
Fuzzy
(Figura G.34). Os parâmetros inseridos nesta tela
serão utilizados para a ponderação de todos os quesitos, os quais alimentarão o processo de
inferência
Fuzzy
para identificação das funções significantes e classificação dos seus modos de
falha, seguindo a lógica dos diagramas de decisão da MCC. Para proceder à modificação dos termos
primários, o usuário deve: escolher a variável lingüística a ser modificada (Ruim, Baixa, Boa, Alta
ou Ótima); alterar os valores de seus vértices, conforme desejado; e, estabelecida a parametrização
desejada, para cada variável lingüística, clicar no botão avançar (→).
Figura G.34 – Tela de Parametrização dos Termos Primários.
323
Para a avaliação da significância ou não das funções, identificadas na Etapa 3, o DALF-
Diagramas submete à ponderação do usuário alguns quesitos, os quais verificam se a função pode
ser considerada como protegida ou se tem algum impacto nos aspectos pilares da MCC
(segurança, meio ambiente, operação e economia do processo). Estes quesitos são apresentados
para o usuário como “afirmações” cuja aderência da empresa/sistema, a tais afirmações, deve ser
ponderada pelo usuário com uma nota (valor
crisp
) ou um conceito (termo primário
Fuzzy
). Além
dos quesitos a serem ponderados (Figura G.35a), o usuário pode acessar (através do Menu Ver) o
Diagrama de Decisão e seu respectivo item atualmente em avaliação, destacado em amarelo,
(Figura G.35b) bem como a parametrização dos Termos Primários
Fuzzy
atualmente em uso
(Figura G.35c). Tais quesitos e os respectivos efeitos correlatos, com base no diagrama de decisão
adotado pelo procedimento de referência, são os seguintes:
Efeito na Segurança e/ou Ambiente:
Q1
→
A falha funcional representa uma ameaça à vida pessoal do operador dentro ou fora dos
limites do sistema/empresa.
Q2
→
A falha funcional representa uma ameaça à vida coletiva dentro ou fora dos limites do
sistema/empresa.
Q3
→
A falha funcional resulta em infração de uma lei ou padrão ambiental dentro ou fora dos
limites do sistema/empresa.
Q4
→
A Severidade das conseqüências da falha funcional ou do modo de falha é: Moderada,
Crítica ou Muito Crítica.
Q5
→
O Grau de Risco relativo à falha funcional ou ao modo de falha é Crítico (1) Sério (2) ou
Moderado (3).
Efeito na Operação:
Q1
→
A falha funcional reduz a produtividade do sistema.
Q2
→
A falha funcional afeta a qualidade do produto.
Q3
→
A falha funcional afeta o serviço prestado ao cliente (interno ou externo).
Q4
→
A falha funcional afeta outros processos e/ou equipamentos do sistema produtivo.
Impacto Econômico:
Q1
→
A falha funcional aumenta o consumo do sistema (combustível, energia, etc...).
Q2
→
A falha funcional aumenta o desperdício de matéria prima.
Q3
→
A falha funcional apresenta um alto custo de reparo.
Q4
→
A falha funcional causa danos secundários mais onerosos do que o custo do seu reparo.
Função Protegida:
Q1
→
A falha funcional já possui uma ação associada a ela no programa atual de manutenção.
Q2
→
A equipe de implementação e os especialistas envolvidos com a implantação da MCC
concordam em manter alguma ação de manutenção associada à falha funcional sob análise.
Q3
→
A falha funcional é oculta para a equipe de o
p
eração e/ou possui falhas múltiplas
associadas.
Q4
→
A falha funcional impacta de maneira negativa na imagem da empresa perante a sociedade
ou aos seus clientes internos e/ou externos.
324
No item Função Protegida o DALF-Diagramas acrescenta, para ponderação do usuário, o
impacto que a falha funcional tem sobre a imagem da empresa perante a sociedade ou aos seus clientes
internos e/ou externos. Este quesito não está contemplado em nenhuma norma ou bibliografia
referente à MCC, porém, é um fator importante na estratégia de gestão de ativos de qualquer empresa.
c) Parametrização
Fuzzy
atual
a) Quesito a ser Ponderado
b) Diagrama de Decisão
Figura G.35 – Tela de Ponderação dos Quesitos – Etapa 4 – Parte 1.
Concluída a ponderação de todos os quesitos, inicia-se o processo de inferência
Fuzzy
de
avaliação da significância ou não da função sob análise. Na seqüência, o DALF-Diagramas apresenta
para o usuário os resultados do processo de inferência
Fuzzy
a partir da ponderação dos quesitos
(Figura G.36a). São apresentados para o usuário o Conjunto
Fuzzy
, resultante do processo de
inferência, e uma nota resultante da desfuzzyficação de tal conjunto. Adicionalmente, é apresentada,
com base nos resultados anteriores, a opinião do DALF-Diagramas sobre a significância ou não da
função. O usuário tem a opção de aceitar ou não a opinião do DALF-Diagramas. Caso aceite, tem fim
o processo de avaliação da significância da função (Figura G.36b), senão, segue-se no processo de
inferência com a apresentação de novos quesitos, referentes ao passo seguinte do Diagrama de
Decisão da MCC. Este processo se repete até o último passo do Diagrama de Decisão onde uma
resposta negativa à significância da função a define automaticamente como Função Não Significante.
a) Conjunto Fuzzy Resultante do Processo
de Inferência
b) Resposta Final para o Usuário
Figura G.36 – Tela de Resultados do Processo de Inferência
Fuzzy
– Etapa 4.
325
Concluída a análise da significância da função, o DALF-Diagramas inicia a Parte 2 do
processo de inferência.
Parte 2 – Classificação das Conseqüências dos Modos de Falha das Funções Significantes
A Parte 2 do DALF-Diagramas para a Etapa 4 segue os mesmos preceitos da Parte 1,
mudando apenas os quesitos a ponderar, visto que agora dizem respeito à Classificação das
Conseqüências do Modo de Falha e/ou dos seus Efeitos referentes às funções identificadas como
significantes. Os quesitos a serem ponderados e as respectivas conseqüências que se quer inferir,
com base no Diagrama de Decisão adotado pelo procedimento de referência, são os seguintes:
Modo de Falha e/ou Efeito Evidente / Oculto
Q1
→
O operador percebe o Modo de Falha ou o Efeito do Modo de Falha durante suas
atividades normais.
Q2
→
N
ão é necessária nenhuma inspeção para detecção do Modo de Falha ou do Efeito do
Modo de Falha.
Q3
→
Não é necessário nenhum teste e/ou ensaio para detecção do Modo de Falha ou do Efeito
do Modo de Falha.
Q4
→
N
ão é necessário nenhum outro evento ocorrer para detecção do Modo de Falha ou do
Efeito do Modo de Falha.
Q5
→
Qualquer anormalidade associada ao Modo de Falha ou ao Efeito do Modo de Falha é
sinalizada por um sistema automático de supervisão.
Modo de Falha e/ou Efeito com Implicações de Segurança / Ambiental
Q1
→
O Modo de Falha ou o Efeito do Modo de Falha representa uma ameaça à vida pessoal do
operador dentro ou fora dos limites do sistema/empresa.
Q2
→
O Modo de Falha ou o Efeito do Modo de Falha representa uma ameaça à vida coletiva
dentro ou fora dos limites do sistema/empresa.
Q3
→
O Modo de Falha ou o Efeito do Modo de Falha resulta em infração de uma lei ou padrão
ambiental dentro ou fora dos limites do sistema/empresa.
Q4
→
A Severidade das conseqüências do Modo de Falha ou do Efeito do Modo de Falha é:
Moderada, Crítica ou Muito Crítica.
Q5
→
O Grau de Risco relativo ao Modo de Falha ou ao Efeito do Modo de Falha é Crítico (1)
Sério (2) ou Moderado (3).
A Figura G.37 mostra a tela de ponderação dos quesitos da Parte 2 e o respectivo
Diagrama de Decisão inerente com o item atualmente em avaliação, destacado em Amarelo.
Como conclusão da Parte 2 tem-se a classificação do
Modo de Falha sob análise, dentre
as seguintes opções: ESA (Evidente / Segurança / Ambiental), EEO (Evidente / Econômico /
Operacional), OSA (Oculto / Segurança / Ambiental) e OEO (Oculto / Econômico / Operacional).
As funcionalidades das telas de conclusão da Parte 2 seguem os mesmos preceitos daquelas da
Parte 1, já apresentadas. Concluídas as análises referentes à Etapa 4 Parte 2 o DALF-Diagramas
passa automaticamente para a Etapa 5, levando em consideração os resultados do processo de
inferência e as decisões do usuário.
326
a) Quesito a ser Ponderado
b) Diagrama de
Decisão
Figura G.37 – Tela de Ponderação dos Quesitos – Etapa 4 – Parte 2.
G.6 DALF-DIAGRAMAS (ETAPA 5)
Este item apresenta informações complementares, àquelas presentes no Capítulo 6,
referentes ao software DALF-Diagramas, parte integrante do software proposto para a Etapa 4.
Trata-se de um SBC-
Fuzzy
que auxilia a seleção das tarefas de manutenção aplicáveis e efetivas,
para cada uma das funções significantes apontadas na Etapa 4, utilizando um processo de
inferência
Fuzzy
baseado na ponderação de quesitos.
G.6.1 Interface e Estrutura do DALF-Diagramas para a Etapa 5
A tela de abertura do DALF-Diagramas, para a Etapa 5, pode ser vista na Figura G.38. As
telas de Identificação e Descrição da Função e de Parametrização dos Termos Primários
Fuzzy
possuem as mesmas funcionalidades e aparência das telas de mesmo nome, mostradas na Etapa 4.
Figura G.38 – Tela de Abertura do DALF-Diagramas – Etapa 5.
Para inferir sobre qual é a atividade de manutenção mais adequada para cada um dos
Modos de Falha das Funções Significantes, o DALF-Diagramas submete à ponderação do usuário
alguns quesitos. Assim como na Etapa 4, estes quesitos são apresentados para o usuário como
“afirmações” cuja aderência da empresa/sistema, a tais afirmações, deve ser ponderada pelo
usuário com uma nota (valor
crisp
) ou um conceito (termo primário
Fuzzy
). Os quesitos a serem
ponderados, atrelados às respectivas atividades de manutenção que se quer inferir, com base no
Diagrama de Decisão adotado pelo procedimento de referência, são os seguintes:
327
Serviço Operacional:
Q1
→
A tarefa de manutenção reduz a taxa de deterioração funcional. Exemplo de tarefas deste
grupo: lubrificação manual, suprimento de consumíveis e pequenas atividades passíveis de
serem executadas pelo operador.
Q2
→
A tarefa de manutenção tem baixa complexidade não exigindo treinamento es
p
ecializado
do operador.
Q3
→
Em caso de ESA ou OSA a tarefa de manutenção reduz o risco de falha. Em caso de EEO ou
OEO a tarefa de manutenção reduz o risco de falha a nível aceitável e tem custo reduzido.
Q4
→
A tarefa de manutenção atende a um requisito de projeto conforme recomendação do
fabricante.
Q5
→
A tarefa de manutenção possui uma freqüência de execução aceitável, ou seja, que não tem
impacto significante na rotina operacional.
Inspeção Preditiva:
Q1
→
É possível identificar ou prever uma deterioração funcional por teste ou inspeção, sem
desmontagem do equipamento/ativo/sistema.
Q2
→
O intervalo PF (Falha Potencial / Falha Funcional) é consistente.
Q3
→
O intervalo PF (Falha Potencial / Falha Funcional) é suficiente para uma ação de
prevenção.
Q4
→
É prático monitorar o equipamento/ativo/sistema a intervalos inferiores ao intervalo PF
(Falha Potencial / Falha Funcional).
Q5
→
Em caso de ESA ou OSA a tarefa reduz o risco ou a probabilidade de falha garantindo a
operação segura. Em caso de EEO ou OEO a tarefa reduz o risco de falha a nível aceitável
e tem custo reduzido, menor que o custo da falha evitada.
Restauração Preventiva:
Q1
→
A degradação é função do tempo em operação ou da última manutenção realizada.
Q2
→
É possível uma ação preventiva antes do período de desgaste.
Q3
→
O ativo/sistema mostra degradação em uma idade identificável.
Q4
→
Uma proporção alta de ativos/sistemas sobrevive à idade onde a degradação é
identificável.
Q5
→
É possível restaurar o ativo/sistema a um padrão especificado que seja adequado.
Q6
→
Em caso de ESA ou OSA a tarefa reduz o risco ou a probabilidade de falha garantindo a
operação segura. Em caso de EEO ou OEO a tarefa reduz o risco de falha a nível aceitável
e tem custo reduzido, menor que o custo da falha evitada.
Substituição Preventiva:
Q1
→
A degradação é função do tempo em operação ou da última manutenção realizada.
Q2
→
A substituição garante a condição original do item.
Q3
→
O ativo/sistema mostra degradação em uma idade identificável.
Q4
→
Uma proporção alta de ativos/sistemas sobrevive à idade onde a degradação é
identificável.
Q5
→
A restauração do ativo/sistema é impossível ou antieconômica.
Q6
→
Em caso de ESA ou OSA a tarefa reduz o risco ou a probabilidade de falha garantindo a
operação segura. Em caso de EEO ou OEO a tarefa reduz o risco operacional a nível
aceitável e tem custo reduzido, menor que o custo da falha evitada.
328
Inspeção Funcional:
Q1
→
A tarefa de manutenção é capaz de revelar falha ou defeito oculto.
Q2
→
A falha não se revela na operação normal do ativo/sistema.
Q3
→
A falha só aparece na ocorrência de outra falha ou evento.
Q4
→
É possível exercitar o funcionamento do item sem danificá-lo.
Q5
→
Em caso de OSA a tarefa deve detectar a falha ou defeito, ocultos, reduzindo o risco de
falhas múltiplas. Em caso de OEO a tarefa deve detectar a falha ou defeito, ocultos,
evitando transtornos operacionais e econômicos com custo reduzido.
Manutenção Combinada:
Q1
→
Nenhuma ação de manutenção anterior pode, isoladamente, identificar/corrigir a falha. Isso
só é possível com uma combinação de tarefas de manutenção.
Q2
→
A freqüência com que as tarefas de manutenção combinadas serão executadas é viável
técnica e economicamente.
Q3
→
Em caso de ESA ou OSA a combinação de tarefas reduz o risco ou a probabilidade de
falha. Em caso de EEO ou OEO a tarefa reduz o risco operacional a nível aceitável e tem
custo reduzido, menor que o custo da falha evitada.
Mudança de Projeto:
Q1
→
Não há viabilidade técnica e/ou econômica para uma ação de manutenção preventiva
(Inspeção Preditiva, Inspeção Funcional, Restauração Preventiva ou Substituição
Preventiva).
Q2
→
O ativo/sistema tem alta prioridade e/ou a análise de custo benefício é favorável.
Q3
→
Nenhuma ação de manutenção anterior pode isoladamente ou em conjunto
identificar/corrigir a falha.
Q4
→
Em caso de ESA ou OSA a combinação de tarefas não reduz o risco ou a probabilidade de
falha. Em caso de EEO ou OEO a tarefa não reduz o risco operacional a nível aceitável e
tem custo superior ao custo da falha.
Reparo Funcional:
Q1
→
N
ão há viabilidade técnica e/ou econômica para uma ação de manutenção preventiva
(Inspeção Preditiva, Inspeção Funcional, Restauração Preventiva ou Substituição
Preventiva).
Q2
→
As conseqüências da falha são insignificantes.
Q3
→
O ativo/sistema tem baixa prioridade.
Q4
→
O reparo funcional é mais atrativo do que uma mudança de projeto e é aceitável do ponto
de vista da segurança e preservação ambiental.
A Figura G.39a mostra a Tela de Ponderação dos quesitos. Assim como na Etapa 4, o
usuário pode acessar (através do Menu Ver) o Diagrama de Decisão com seu respectivo item
atualmente em avaliação, destacado em amarelo, (Figura G.39b) e a parametrização dos Termos
Primários Fuzzy atualmente em uso (idem Figura G.35c).
Concluída a ponderação de todos os quesitos, inicia-se o processo de inferência
Fuzzy
de
avaliação da atividade de manutenção aplicável e efetiva para o Modo de Falha sob análise. Como
resultado do processo de inferência
Fuzzy
, o DALF-Diagramas apresenta para o usuário um
329
Conjunto
Fuzzy
e uma nota resultante da desfuzzyficação de tal conjunto (Figura G.40a).
Adicionalmente, é apresentada, com base nos resultados anteriores, a opinião do DALF-Diagramas
sobre qual é a atividade de manutenção aplicável e efetiva para o Modo de Falha sob análise.
Figura G.39 – Tela de Ponderação dos Quesitos – Etapa 5.
a) Quesito a ser Ponderado b) Diagrama de Decisão
O usuário tem a opção de aceitar ou não a opinião do DALF-Diagramas, caso aceite, tem
fim o processo de avaliação (Figura G.40b), senão, as seguintes conclusões são apresentadas: Para
Modos de Falha classificados com ESA ou OSA, caso nenhuma outra atividade de manutenção seja
aplicável e efetiva o DALF_Diagramas conclui, sem a ponderação dos respectivos quesitos, que a
atividade de manutenção para estes Modos de Falhas é a Mudança de Projeto. Para os Modos de
Falha classificados como EEO e OEO, a não aderência a nenhuma outra atividade de manutenção
resulta, sem a ponderação dos respectivos quesitos, na indicação de Reparo Funcional.
Figura G.40 – Tela de Resultados do Processo de Inferência
Fuzzy
– Etapa 5.
a) Conjunto Fuzzy Resultante do
Processo de Inferência
b) Resposta Final para o usuário
O DALF-Diagramas permite ao usuário iniciar o processo de inferência
Fuzzy
em pontos
estratégicos, sem a necessidade de “percorrer” todos os diagramas de decisão. Assim é possível
definir de forma independente: a definição/identificação da significância ou não da função; a
classificação dos modos de falha das funções significantes; e as atividades de manutenção aplicáveis
330
e efetivas, para os respectivos modos de falha. Para isso basta selecionar, respectivamente: Menu
Arquivo → Opção Novo: FUNÇÃO; FALHA; e ESA , EEO , OSA ou OEO.
Todas as informações inseridas, bem como os resultados do processo de inferência podem
ser salvos, recuperados e editados (arquivos com extensão .ddf). Além disto, o DALF-Diagramas
gera relatórios em formato HTML com todos os dados inseridos e os respectivos resultados do
processo de inferência
Fuzzy
. Tal relatório será detalha no próximo item deste trabalho.
G.7 RELATÓRIO DE RESULTADOS E CONCLUSÕES DO DALF-DIAGRAMAS
Os resultados e conclusões do processo de inferência
Fuzzy
do DALF-Diagramas são
condensados em um relatório, o qual está dividido nas seguintes seções: cabeçalho e
parametrização
Fuzzy
; “caminhos” seguidos nos Diagramas da Decisão, pelo processo de
inferência, para obtenção das respostas; e ponderação dos quesitos e resultados do processo de
inferência
Fuzzy
. A Figura G.41 mostra o cabeçalho, com os dados informados na tela de
identificação e descrição da função e a parametrização dos termos primários
Fuzzy
(Coordenadas e respectivas Funções de Pertinência), estabelecida pelo usuário. Esta parte do
relatório do DALF-Diagramas é comum às Etapas 4 e 5.
Identificação
Nome: Teste
Descrição: Teste do DALF_Diagramas
Parametrização Fuzzy:
Termos Coordenadas
Ruim (0,0 0,0) (0,0 1,0) (1,0 1,0) (2,0 0,0)
Baixa (1,0 0,0) (2,0 1,0) (3,0 1,0) (4,0 0,0)
Boa (3,0 0,0) (4,0 1,0) (6,0 1,0) (7,0 0,0)
Alta (6,0 0,0) (7,0 1,0) (8,0 1,0) (9,0 0,0)
Ótima (8,0 0,0) (9,0 1,0) (10,0 1,0) (10,0 0,0)
Figura G.41 – Cabeçalho e Parametrização
Fuzzy
.
As conclusões do DALF-Diagramas são apresentadas de duas formas, a saber: de
forma gráfica, utilizando os diagramas de decisão da MCC adotados pelo procedimento de
referência (
IEC 60300-3-11); e em forma de resposta textual associada ao conjunto
Fuzzy
,
resultante da avaliação dos quesitos ponderados pelo usuário. A Figura G.42 mostra exemplos
de resultados passíveis de serem fornecidos pelo DALF-Diagramas evidenciando, de forma
gráfica, os “caminhos” seguidos nos Diagramas da Decisão pelo processo de inferência. Nos
331
casos exemplificados, os seguintes diagramas são utilizados: (a) Função Significante (b)
Classificação da Função e (c) Atividade de Manutenção.
Figura G.42 – Diagramas da Decisão Resultantes.
O Fluxograma abaixo sintetiza o Resultado do Processo de Inferência do DALF_Diagramas.
Os próximos itens detalham cada etapa e seus respectivos resultados parciais que culminaram com o resultado final.
a) Função Significante b) Classificação da Função c) Atividade de Manutenção
A Figura G.43 exemplifica uma ponderação de quesitos, feita pelo usuário, e os resultados
do processo de inferência
Fuzzy
. O exemplo se refere à seleção de funções significantes devido ao
efeito na segurança e/ou meio ambiente. Esta parte do relatório inicia com a resposta do usuário que,
neste caso, concorda com a opinião do DALF-Diagramas cujo resultado é mostrado no final do
relatório onde é explicitado o conjunto
Fuzzy
resultante do processo de inferência.
=== ETAPA 4 - PARTE 1: SELEÇÃO DAS FUNÇÕES SIGNIFICANTES / Efeito na Segurança e/ou Ambiente ===
Resposta do usuário:
Sim
Avaliação das Asserções:
Quanto a Falha Funcional sob análise, pondere com um Conceito ou uma Nota a Aderência de sua Empresa e/ou Sistema à seguinte Afirmação:
A falha funcional representa uma ameaça à vida pessoal do operador.
Quanto a Falha Funcional sob análise, pondere com um Conceito ou uma Nota a Aderência de sua Empresa e/ou Sistema à seguinte Afirmação:
A falha funcional representa uma ameaça à vida coletiva.
Quanto a Falha Funcional sob análise, pondere com um Conceito ou uma Nota a Aderência de sua Empresa e/ou Sistema à seguinte Afirmação:
A falha funcional resulta em infração de uma lei ou padrão ambiental.
Quanto a Falha Funcional sob análise, pondere com um Conceito ou uma Nota a Aderência de sua Empresa e/ou Sistema à seguinte Afirmação:
A Severidade das conseqüências da falha funcional ou do modo de falha é: Moderada, Crítica ou Muito Crítica.
Quanto a Falha Funcional sob análise, pondere com um Conceito ou uma Nota a Aderência de sua Empresa e/ou Sistema à seguinte Afirmação:
O Grau de Risco relativo à falha funcional ou ao modo de falha é: Crítico (1) Sério (2) ou Moderado (3).
Processamento Fuzzy:
Resposta Nota Coordenadas
Sim 6,1 (1,0 0,0) (2,0 1,0) (3,0 1,0) (3,5 0,5) (4,0 1,0) (6,0 1,0) (6,5 0,5) (7,0 1,0) (8,0 1,0) (8,5 0,5) (9,0 1,0) (10,0 1,0) (10,0 0,0)
Alta
Boa
Baixa
9,0
8,0
Figura G.43 – Ponderação dos Quesitos e Resultados do Processo de Inferência.
332
333
APÊNDICE H
ÍNDICES
Apresenta os Índices Onomástico e Remissivo
334
335
ÍNDICE ONOMÁSTICO
ABEL, Mara (2005) → 55 | 59 | 68 | 69 | 262 | 263
ABNT (1994) → 33
ABRAMAN (2007) → 20 | 21 | 22 | 23 | 24 | 67
ABS (2004) → 34 | 44 | 46 | 99 | 223 | 226
ALIBERAS, J.; PINTÓ, R.; GÓMEZ, R. (1996) → 76
ALKAIM, João Luiz (2003) → 23 | 26 | 30 | 40 | 144 | 225
ANTONIETTI, Leandro Escagion (2002) → 27 | 130 | 180 | 222 | 225
BACKLUND, Fredrik (2003) → 26 | 114 | 115 | 116 | 125 | 194 | 197
BÁRDOSSY, A.; DUCKSTEIN, L. (1995) → 92
BARREIRO, S. R. (1999) → 183
BENJAMINS, V. R.; FENSEL, D. (1998) → 235
BERTLING, L.; ALLAN, R.; ERIKSSON, R. (2003) → 26
BEYON, Davis P. (1991) → 69
BITTENCOURT, Guilherme (2001) → 80 | 81 | 245 | 246
BLANCO, Santiago Sotuyo (2007) → 23 | 29 | 125 | 126 | 194
BLOOM, Neil B. (2006) → 137
BOEHM, B.; BROWN, J. R.; KASPAR, H.; LIPOW, M.;
MACLEOD, G. J.; MERRIT, M. J. (1978)
→ 248
BOFF, L. H., (2001) → 60
BOOSE, J. H.; BRADSHAW, J. M. (1988) → 242
BOWLES, John B. (2003) → 178
CAMPOS, Pio Filho (2004) → 24 | 87 | 193
CARMO, Annibal José Roris Rodriguez Scavarda (2004) → 176 | 177
CARVALHO, Lucimar Fossatti de, (1995) → 242 | 244
CASTILLO E. V. (2003) → 247 | 248
CHANDRASEKARAN, B.,(1988) → 235
CHANDRASEKARAN, B.; JOSEPHSON, J. R.;
BENJAMINS, V. R (1999)
→ 247
CISL (2008) → 173
CLANCEY, W. J. (1989) → 235
CLEAL, D. M.; HEATON, N.O (1988) → 76
COX, E., (1994) → 90 | 251
DALKEY, Norman C., (1967) → 79 | 175 | 238
DALKEY, Norman C., (1968)
→ 175 | 238
DALKEY, N.; BROWN, B.; COCHRAN, S. (1969) → 79
DAMSKI, J. C. B.; LIMA, J. G. M.; GIORNO, F. G.;
VALENTE, A. S. M. (1993)
→ 234
DNV – Det Norske Veritas (2003) → 183
DAVENPORT, T; PRUSAK, L., (1998) → 54
DURKIN, John, (1994) → 61 | 71 | 276
ESHELMAN, L.; BOOSE, J.; GAINES, B.; MOLE (1988) → 241
FEIGENBAUM, E. A (1979) → 69
FERNANDES, A. M. da R.; BASTOS, R. C. (2001) → 252 | 254 | 97
FERNANDES, Anita Maria da Rocha (2003) → 70 | 71 | 80 | 85
FERNANDES, Anita Maria da Rocha (2004) → 30
FORSYTHIE, D. E., BUCHANAN, B. G., (1989) → 76
FUENTES, Fernando Félix Espinosa (2006) → 22 | 187 | 190 | 191 | 202
GARCIA, Pauli Adriano de Almada (2006) → 24 | 26 | 130 | 172
GASCHNIG, J.; HAYES-ROTH F.; WATERMAN, D. A.;
LENAT, D. B. (1983)
→ 248
336
GENARO, Sérgio (1986) → 76
GIARRATANO, J.; RILEY, G. (1998) → 53 | 54 | 68 | 70 | 71 | 76 | 84 | 248
GIL, A. C. (1996) → 31
GOBER, C. J.; SILVA, L. C. S. da; SANTOS, R. J. dos
(2008)
→ 190
GONZALEZ, A. J. e DANKEL, D. D. (1993) →
62 | 68 | 72 | 74 | 82 | 84 | 85 | 86 | 185
| 229 | 332
GRUBER, T. R. (1993) → 241
GUIDA, G.; SPAMPINATO, L. (1989) → 248
GUPTA, U. G.; CLARKE, R. E. (1996) → 176 | 237 | 238 | 239
HARMON, P.; MAUS, R.; MORRISSEY, W (1988) → 76
HART, Anna (1992) → 76
HAUGE, B. S.; JOHNSTON, D. C (2001) → 26 | 180 | 181 | 183
HEIJST, G.; SHREIBER, A. T.; WIELINGA, B. J. (1997) → 236 | 237
HOLLNAGEL, Erik (1989) → 250
IEC-60300-3-11 (1999) →
142 | 148 | 194 | 197 | 215 | 217 | 218 |
219
IEC-60706-4 (1992) → 42
JOHNSTON, D. C. (2002) → 26 | 114 | 180 | 181 | 183 | 194 | 197
KARDEC, A.; XAVIER, J. de A. N. (2003) → 19
KELLY, G. A. (1955) → 242
LAUDON, K. C.; LAUDON, J. P. (2002) → 70
LEBOWITZ, M., (1987) → 59
LEE, B., (2001) → 174
LIEBOWITZ, J. (1988) → 248 | 251
LIEBOWITZ, J.; WILCOX, L. C. (1997) → 59 | 251
LIMA, J. C. de Araujo (1999) → 188
LIRA, G. da S. de; FANTINATO M., (2005) → 61 | 62
LUCATELLI, M. V. → 114
MAMDANI, E. H.; ASSILIAN, S. (1975) → 93
MARCOT, B. (1987) → 248
McCARTHY, J.; MINSKY, M. L.; ROCHESTER, N.;
SHANNON, C. E. (1955)
→ 68
McDERMOTT, J. (1988) → 235
MELO, C. H. de; JUNIOR, J. M. S. G.; MORGADO, C. do
R. V. (2002)
→ 183
MICHEL, Bernardo Amarante (2002) → 100
MIL-STD-1629 A (1980) → 40
MIL-STD-2173 (AS) (1986) → 44
MONCHY, François (1989) → 35
MOTTA, E. (1998) → 236 | 240 | 241
MOUBRAY, J. (2001) →
19 | 23 | 25 | 33 | 34 | 35 | 36 | 37 | 38 |
39 | 40 | 44 | 47 | 48 | 49 | 99 | 114 |
115 | 116 | 120 | 125 | 132 | 180 | 181 |
194 | 197
MUSEN, M. A.; FAGAN, L. M.; COMBS, D. M.;
SHORTLIFFE E. H. (1987)
→ 236
NAVAIR 00-25-403 (2005) → 44
NASA (2000) → 25 | 34 | 44 | 47 | 99 | 194 | 197 | 251
NASSAR, Silvia Modesto (2004) → 86 | 87
NBR 5462 (1994) → 33 | 35 | 39
NONAKA, I.; TAKEUCHI, H. (1997) → 56 | 57 | 60
NOWLAN, F. S.; HEAP, H. F. (1978) → 25 | 34 | 35 | 37 | 44 | 46 | 47 | 48 | 99 |
337
194 | 197
ORTIZ, João Carlos Ross (2004) → 66
PALADY, Paul. (2004) → 132 | 133
PLUCKNETTE, Douglas J. (2008) → 130
POLYA, George (1957) → 56
PRESSMAN, Roger S. (2004) → 73 | 229 | 230 | 259 | 231 | 249 | 250
PROTÉGÉ-2000 (2005) → 248
PUERTA, R.; EDGAR, J. W.; TU, S. W.; MUSEN, M. A.
(1996)
→ 240
RABUSKE, Renato Antônio (1995) → 69
RAJOTTE, Claude, JOLICOEUR, Alain (2001) → 25 | 114 | 194
RAPOSO, José Luis Oliveira (2004) → 26 | 181 | 182 | 183
RAUSAND, Marvin; HØYLAND, Arnljot (2003) → 33
REZENDE, Solange Oliveira (2003) →
53 | 54 | 62 | 69 | 70 | 71 | 72 | 76 | 77 |
78 | 79 | 80 | 82 | 83 | 89 | 91 | 94 | 167
| 229 | 231 | 232 | 233 | 234 | 236 | 237
| 239 | 240 | 241 | 242 | 243 | 244 | 245
RIBEIRO, R. T.; ALVES, N. F. (2005) → 114 | 194 | 224 | 225 | 226
RIBEIRO, S.; CUNHA, H. (1987) → 70
RICH, E.; KNIGHT, K. (1993) → 56 | 81 | 244 | 245
RUSSELL, S. J.; NORVIG, P. (2004) → 68 | 80
SAE - JA1011 (1999) →
25 | 30 | 34 | 39 | 40 | 44 | 45 | 99 | 223
| 226 | 243 | 245 | 246 | 247
SAE - JA1012 (2002) →
25 | 30 | 34 | 39 | 40 | 44 | 45 | 99 | 188
| 223 | 226 | 243 | 245 | 246 | 247
SAE - J1739 (2002) →
39 | 41 | 196 | 244 | 246 | 247 | 248 |
249 | 250 | 251
SANTIAGO Jr., José Renato Sátiro (2004) → 54 | 55 | 56 | 57 | 59 | 63
SCHREIBER, A. T. (1992) → 235
SCHREIBER, G.; AKKERMANS, H.; ANJEWIERDEN,
A.; HOOG, R.; SHADBOLT, N.; DE VELDE, W. V.;
WIELINGA, B. (2002)
→ 62 | 63
SEIXAS, Eduardo de Santana (2004) → 36 | 37
SHAW, I. S.; SIMÕES, M. G. (2002) → 89
SILVA, Jonny Carlos da (1998) → 31 | 73 | 98
SILVA, E. L.; MENEZES, E. M. (2005) → 31
SIQUEIRA, Iony Patriota de (2005) →
19 | 23 | 34 | 35 | 36 | 37 | 38 | 39 | 40 |
41 | 42 | 114 | 116 | 121 | 124 | 125 |
126 | 127 | 132 | 136 | 138 | 193
SIQUEIRA, Iony Patriota de (2005a) → 26
SIQUEIRA, Iony Patriota de (2007) → 114
SMITH, A. M. (1993)
→ 25 | 34 | 48 | 49 | 50 | 99 | 194 | 197
SMITH, A. M.; HINCHCLIFFE, G. R. (2004) →
23 | 25 | 34 | 36 | 37 | 39 | 40 | 51 | 99 |
114 | 115 | 116 | 125 | 132 | 194 | 197
SMITH, S.; KANDEL, A. (1993) → 84 | 85 | 248 | 249
SOMMERVILLE, Ian (2004) → 73 | 229 | 230 | 231 | 249
STAMATIS, D. H. (1995) → 132
STUDER, R.; BENJAMINS, V. R.; FENSEL, D. (1998) → 234 | 235
SWARTOUT, W. ; GIL Y. ; VALENTE, A. (1999) → 240
TEIXEIRA A. (2001) → 19
TERRA, José Cláudio Cyrineu (2001) → 60
TSANG A. (1998) → 20
VERMESAN, A. I.; BENCH C. T. (1995) → 249
338
VIZZONI, E.; ROSÁRIO, G. J.; OLIVEIRA, J. J. C.;
FRANCESCHETT, J. G.; JANEIRO, M. P.; CASTRO, R.
T. (1999)
→ 114 | 194 | 197 | 224
WALTRICH, S.; TONDELLO, C. (2007) → 26 | 194
WATERMAN, Donald A. (1986) → 68 | 72 | 75
WIELINGA, B. J.; VELDE, Van De W.; SCHREIBER, G.;
AKKERMANS, H. (1992)
→ 235 | 240
WIREMAN, Terry (2005) → 132
WORLEDGE, D. (1993) → 114 | 115 | 116
YEN, J., LANGARI, R (1998) → 91 | 167
339
ÍNDICE REMISSIVO
Abstração ....................................................82
Agenda .......................................................71
Agregação dos Consequentes .....................95
Ajustes de Projeto .......................................75
Análise de Risco..........................................180
Análise.................................................... 54,74
Aprimoramento Contínuo ..........................115
Aquisição de Conhecimento.................. 76,232
Auditoria da Etapa 0 ...................................142
Auditoria da Etapa 1 ...................................143
Auditoria da Etapa 2 ...................................144
Auditoria da Etapa 3 ...................................145
Auditoria da Etapa 4 ...................................147
Auditoria da Etapa 5 ...................................148
Auditoria da Etapa 6 ...................................151
Auditoria da Etapa 7 ...................................152
Auditoria da Etapa 8 ...................................153
Avaliação dos Antecedentes .......................94
Base de Conhecimento................................70
Cálculo ........................................................54
Categorização..............................................54
Combinação.................................................58
Comparação.................................................54
Complemento..............................................89
Compreensão...............................................54
Comprometimento ......................................115
Condensação dos Consequentes .................96
Condensação ...............................................54
Conexão.......................................................55
Conhecimento - Dimensão Epistemológica 56
Conhecimento - Dimensão Ontológica.......56
Conhecimento ............................................54
Conhecimento de Domínio..........................55
Conhecimento Declarativo..........................55
Conhecimento Explícito..............................56
Conhecimento Heurístico............................55
Conhecimento Procedural...........................55
Conhecimento Profundo.............................55
Conhecimento Superficial........................... 55
Conhecimento Tácito.................................. 56
Conjunto
Fuzzy
- Limite ............................88
Conjunto
Fuzzy
- Núcleo ...........................88
Conjunto
Fuzzy
- Suporte ..........................88
Consequência.............................................. 54
Contextualização ........................................54
Contribuições .............................................29
Conversão do Conhecimento...................... 56
Conversão ................................................... 55
Correção...................................................... 54
Dado............................................................ 53
DALF-Diagramas - Interface...................... 321
DALF-Diagramas .......................................180
DALF-MCC - Conclusões..........................307
DALF-MCC - Critérios...............................279
DALF-MCC - Desenvolvimento ................ 158
DALF-MCC - Instalação ............................ 267
DALF-MCC - Interface .............................. 303
DALF-MCC - Organização das Regras...... 160
DALF-MCC - Processo de Desfuzzyficação. 301
DALF-MCC - Processo de Fuzzyficação...... 301
DALF-MCC - Processo de Inferência ........163
DALF-MCC - Quesitos...............................279
DALF-MCC - Relatório..............................307
DALF-MCC - Resultados...........................307
DALF-MCC - Validação ............................ 187
DALF-MCC - Verificação.......................... 185
DALF-MCC................................................157
Descrições de Domínio...............................77
Desenvolvimento de Software................73,74
Desfuzzificação ..........................................96
Efetivo Próprio ........................................... 20
Elicitação de Conhecimento ..................76,232
340
Encapsulamento ..........................................82
Engenharia do Conhecimento......................61
Engenharia do Conhecimento......................69
Engenheiro de Conhecimento (EC).............62
Entrevistas ..................................................77
Especialistas ................................................62
Especialização do Pessoal da Manutenção..67
Especificação ..............................................74
Espiral do Conhecimento ............................56
Estrutura do Trabalho .................................31
Etapa 0 ........................................................102
Etapa 1.........................................................102
Etapa 2 ........................................................103
Etapa 3 ........................................................104
Etapa 4 ........................................................105
Etapa 5 ........................................................106
Etapa 6 ........................................................108
Etapa 7 ........................................................109
Etapa 8 ........................................................109
Etapas - Controles .......................................101
Etapas - Entradas ........................................101
Etapas - Mecanismos ..................................101
Etapas - Objetivos .......................................101
Etapas - Saídas ............................................101
Etapas - Tarefas ..........................................101
Externalização .............................................57
Falha Funcional...........................................39
Fatores Gerenciais ......................................116
Fatores Técnicos..........................................116
Fatos ...........................................................71
Ferramentas Computacionais ......................171
FMECA-Delphi - Interface..........................313
FMECA-Delphi...........................................174
Função ........................................................39
Função de Pertinência..................................90
Funções Primárias ......................................39
Funções Secundárias ...................................39
Funções Significantes .................................41
Fuzzificação ...............................................94
FuzzyClips...................................................97
GC - Dimenções..........................................60
GC - Importância.........................................59
Gestão de Projetos.......................................116
Gestão do Conhecimento (GC) ..................53
Herança ......................................................83
Hierarquia do Conhecimento .....................54
Idade Média dos Equipamentos .................22
IDEF ...........................................................100
Implementação ...........................................75
Implementação Computacional...................157
Implicação ..................................................95
Incertezas ....................................................85
Indicadores de Desempenho .......................21
Indicadores de Disponibilidade ..................22
Informação .................................................53
Inteligência Artificial (IA) ..........................68
Interface com o Usuário..............................71
Internalização..............................................58
Interseção ....................................................89
ISO/IEC 9126 .............................................84
Justificativas ...............................................29
Lógica
Fuzzy
...............................................87
Mamdani ....................................................93
Manutenção Centrada na Confiabilidade ...33
Manutenção de Software.............................75
Máquina de Inferência.................................71
MCC - Atributos ........................................38
MCC - Critérios ..........................................38
MCC - Definição ........................................33
MCC - Evolução Histórica .........................34
MCC - Metodologias para Implantação......42
Memória Operacional..................................71
Metaconhecimento .....................................54
Metodologia - ABS.....................................44
Metodologia - IEC 60300-3-11 ..................42
Metodologia - Moubray .............................47
341
Metodologia - NASA..................................44
Metodologia - Nowlan e Heap ...................46
Metodologia - SAE JA1011........................44
Metodologia - SAE JA1012........................44
Metodologia - Smith ..................................48
Metodologia - Smith e Hinchcliffe .............50
Metodologia da Pesquisa ............................30
MIL-STD-1629A ........................................178
Modificadores Linguisticos ........................91
Modo de Falha - Classificação ...................41
Modo de Falha ............................................39
Monitoramento Automático .......................23
NBR 13596 .................................................84
NPR-Fuzzy - Interface ................................318
NPR-Fuzzy..................................................177
Objetivo Geral ............................................27
Objetivos Específicos .................................28
Open-FMECA - Interface............................309
OpenFMECA ..............................................173
Operações
Fuzzy
........................................89
Orientação a Objetos...................................82
Participação
Fuzzy
.....................................90
Peritos | Experts ..........................................62
Polimorfismo ..............................................83
Premissas da Pesquisa.................................23
Pré-Requisitos da Etapa 0 ..........................118
Pré-Requisitos da Etapa 1 ..........................123
Pré-Requisitos da Etapa 2 ..........................128
Pré-Requisitos da Etapa 3 ..........................130
Pré-Requisitos da Etapa 4 ..........................133
Pré-Requisitos da Etapa 5 ..........................134
Pré-Requisitos da Etapa 6 ..........................136
Pré-Requisitos da Etapa 7 ..........................137
Pré-Requisitos da Etapa 8 ..........................139
Problema de Pesquisa..................................23
Procedimento de Referência .......................99
Processamento da Linguagem Natural........68
Processamento de Conhecimento................68
Projeto Detalhado........................................75
Projeto Inicial.............................................. 75
Projeto Preliminar.......................................75
Publicações ................................................. 275
Qualificação do Pessoal da Manutenção ....20
Recursos .....................................................114
Regras de Produção ....................................82
Regras de Produção
Fuzzy
.........................91
Representação do Conhecimento (RC) ......80
Resultados e Benefícios ............................. 115
Retorno do Investimento ............................ 115
Robótica...................................................... 68
Ruído...........................................................53
SAE-J1739.................................................. 178
SBC - Desenvolvimento .............................231
Seleção de SBC´s .......................................75
Singleton
....................................................88
Síntese......................................................... 54
Sistema Baseado em Conhecimento (SBC)..69
Sistema Especialista.................................... 69
Sistemas Inteligentes (SI) ..........................69
Socialização ...............................................57
Susbsistema de Aquisição de Conhecimento 71
Susbsistema de Explicação......................... 71
Tarefas de Manutenção Aplicáveis.............41
Tarefas de Manutenção Efetivas ................41
Teachback ..................................................
78
Técnica
Delphi
............................................79
Tempo ........................................................115
Termos Primários ....................................... 90
Teste ...........................................................75
Trabalhos Futuros .......................................200
Trabalhos Relevantes .................................25
Treinamento do Pessoal da Manutenção .... 21
União...........................................................89
Validação ...................................................84
Variáveis Linguisticas ................................ 90
Verificação .................................................84
342
Livros Grátis
( http://www.livrosgratis.com.br )
Milhares de Livros para Download:
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas
Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo