See a worldwide directory.

 

ReliaSoft > Reliability Hotwire > Edição 20 > Assunto Hot
Reliability HotWire: eMagazine for the Reliability Professional
Reliability HotWire

Edição 20, Outubro 2006

Assunto Hot

Estimando a Disponibilidade com Simulação  

A Disponibilidade é uma medida que combina os conceitos de confiabilidade e de mantenabilidade. A Disponibilidade fornece a probabilidade de uma unidade estar disponível - não estar quebrada e não estar sob ação de reparo - quando solicitada para o uso. As indústrias que contam com determinadas peças chaves no equipamento têm um grande interesse em conseguir e poder modelar a disponibilidade destas máquinas. Fazendo com que os clientes dos fabricantes de sistemas reparáveis, tenham um grande interesse na disponibilidade dos produtos que estão comprando. A estimação da disponibilidade é feita mais freqüentemente com simulação. Neste artigo, nós mostraremos a maneira que o software BlockSim da ReliaSoft conduz a simulação da disponibilidade.

O BlockSim utiliza o método da simulação para estimar a disponibilidade do sistema e as medidas associadas. Isto inclui o número de falhas previstas, o número de ações previstas de manutenção, etc.. O processo de estimação envolve em sintetizar o processo do desempenho do sistema num número dado de funcionamento ou de laços da simulação. Cada laço emula como o sistema pôde executar na vida real baseando-se nas propriedades especificadas de falha e de funcionamento do sistema. Estas propriedades consistem nas inter-relações entre os componentes, como definidas no diagrama de bloco de confiabilidade (RBD), falha, reparo, e as propriedades quantitativa correspondentes da manutenção para cada componente.

Por exemplo, suponha que nós desejamos determinar a disponibilidade de um sistema complexo sobre o período de um ano. Um modelo para simulação do sistema poderia ser desenvolvido para emular as falhas aleatórias e os tempos de reparo dos componentes no sistema, assim criando um retrato mostrando o estado do tempo ativo e inativo do sistema, similar à figura seguinte. 

Up and down states for a system.

Para um dado tempo da operação, o tempo até a falha, se necessário, o tempo até o reparo, são gerados aleatoriamente. Se o componente ou os componentes que falham nesse período de tempo é vital à operação do sistema, o sistema é dito como inativo. Este processo é repetido para um número especificado de iterações e o resultado é a média calculada para o modelo geral desenvolvido da disponibilidade do sistema.

O processo será ilustrado com um simples exemplo de um sistema reparável com um componente. A distribuição de falha do componente é dada por uma distribuição Weibull de dois parâmetros, com parâmetro de forma = 1,5 e o parâmetro de escala = 150 horas. A distribuição de reparo é uma distribuição normal com mu = 5 horas e sigma = 2 horas. Nós não trataremos dos conceitos "avançados" tais como a manutenção preventiva ou tempos logístico adicionais.

No BlockSim, o usuário deve entrar com o número de "loops" para realizar simulação na janela Maintainability/Availability Simulation. (Note que o número de "loops" internos e externos é irrelevante para simulação de mantenabilidade; a simulação da mantenabilidade é concernida somente com o número total dos "loops".) Por exemplo, nós escolheremos apenas dez "loops" por causa da simplicidade. Em aplicações práticas, é sempre melhor e mais indicado ter um número elevado dos "loops" a fim obter uma simulação mais exata. É requerido ao usuário também, entrar com um tempo final da operação. Por exemplo, nós escolheremos 100 horas como nosso tempo do fim da operação.

Com a entrada destas informações, a simulação pode começar. Em cada loop, o simulador gera uma falha aleatória, usando-se do método de Monte Carlo, baseando na distribuição de falha para o componente. Haverá somente um tempo de falha para este sistema, pois ele consiste em somente um componente. Este tempo de falha é comparado ao tempo do fim da operação. Se o tempo de falha for maior do que o tempo do fim da operação, o loop será considerado como excedente e nenhum tempo de downtime é registrado para esse loop. Se o tempo de falha aleatória for menor do que o tempo do fim da operação, uma falha está registrada de encontro ao componente e, se a falha do componente resultar em uma falha do sistema, de encontro ao sistema também. Em nosso exemplo, uma falha do componente é equivalente a uma falha do sistema. Neste momento, um tempo de reparo é gerado baseando-se na distribuição de reparo do componente. Isto é registrado como tempo inativo do componente e/ou do sistema. As falhas acumuladas pelo componente nestas circunstâncias equivalente a vida é a soma do tempo de falha e tempo de reparo. Se esta soma, ou o tempo decorrido, for menor do que o tempo do fim da operação, um outro tempo de falha aleatória está gerada. Se este novo tempo de falha for menor do que o tempo restante (tempo do fim da operação), um outro tempo de reparo será registrado, e assim por diante. Esse processo de repetição de falha e de reparo decorre o quanto necessário para encontrar-se com ou exceder o tempo do final da operação do sistema, e o tempo indisponível e o número total das falhas para os loops são registrados.

Esse processo é repetido para cada loop, e o tempo de operação para cada loop (tempo final de operação menos o tempo indisponível) é calculado. No fim de todos os loops da simulação, o tempo indisponível é medido e dividido pelo tempo total da operação para determinar a disponibilidade média. A disponibilidade pontual é determinada dividindo o número total da época que o sistema estava operando até o final de cada loop pelo número de loop. 

Embora esta descrição possa parecer um pouco complexa, o processo pode ser esclarecido através deste exemplo pelo de loop e calculando os resultados.

  • LOOP 1 - O primeiro tempo de falha gerado é de 16,1 horas, que é um pouco menos do que o fim da operação de 100 horas, assim uma falha é registrada. Então um tempo de reparo de 8,6 horas é gerado. Isto significa que o sistema volta a funcionar outra vez tendo um tempo decorrido de 24,7 horas, com 75,3 horas restante até o fim da operação. Neste momento, uma segunda falha de 62,3 horas é gerada. Desde que este valor é menor do que a época restante de 75,3 horas, uma outra falha é registrada. Um outro tempo de reparo de 6,4 horas é gerado. Neste momento, o tempo decorrido no loop é de 93,4 horas (16,1 + 8,6 + 62,3 + 6,4 = 93,4). Este ainda é menor do que a época do fim da operação de 100 horas, tendo por resultado um tempo restante de 6,6 horas, assim um outro tempo de falha é gerado. Este tempo de falha é de 30,5 horas, que excede o tempo restante de 6,6 horas, assim o loop é terminado com um total de duas falhas registradas com um tempo indisponível de 15 horas (8,6 + 6,4 = 15). O sistema estava operando até o final do loop.

  • LOOP 2 - O primeiro tempo de falha gerado é de 141,2 horas. Desde que esta exceda o tempo até o final da operação, nenhuma falha ou tempo indisponível é registrados. O sistema estava operando até o final do loop.

  • LOOP 3 - O primeiro tempo de falha gerado é de 167,4 horas. Nenhuma falha ou tempo indisponível é registrados. O sistema estava operando até o final do loop. 

  • LOOP 4 - O primeiro tempo de falha gerado é de 199,4. Não teve falhas ou tempo indisponível. O sistema estava operando até o final do loop.

  • LOOP 5 - O primeiro tempo de falha gerado é de 74,8. Este é menor que o tempo final da operação, um tempo de de reparo de 6,1 horas é gerado. Até esse ponto, tem um tempo decorrido de 80,9 horas, com 19,1 horas restante para o final do tempo de operação. O segundo tempo de falha é de 202,8 horas. Este excede o tempo final e o loop termina com o sistema em operação. Assim foi registrado uma falha e um tempo indisponível de 6,1 horas.

  • LOOP 6 - O primeiro tempo de falha gerado é de 370,8 horas. Nenhuma falha e nenhum tempo indisponível. O sistema estava operando até o final do loop.

  • LOOP 7 - O primeiro tempo de falha gerado é de 101,4 horas. Nenhuma falha e nenhum tempo indisponível. O sistema estava operando até o final do loop.

  • LOOP 8 - O primeiro tempo de falha gerado é de 179,4 horas. Nenhuma falha e nenhum tempo indisponível. O sistema estava operando até o final do loop.

  • LOOP 9 - O primeiro tempo de falha gerado é de 205,7 horas. Nenhuma falha e nenhum tempo indisponível. O sistema estava operando até o final do loop.

  • LOOP 10 - O primeiro tempo de falha gerado é de 92,4 horas, assim uma falha é registrada. Um tempo de reparo de 7,8 horas é gerado. Este resultado de 100,2 horas ultrapassa o final final da operação de 100. Desde que exceda o final da operação por 0,2 horas, o sistema não estava operando no final da operação. Em outra palavras, o sistema foi considerado como submetido a reparo no final do loop.  Com isso o tempo indisponível é de 7.6 horas, menor que as 7,8 horas geradas como tempo de reparo. Isto porque se calcula somente até o fim da operação (100 - 92,4 = 7,6).

Uma visão geral resumida das atividades para cada loop:

Loop # # n de Falhas Tempo Indisponível Tempo Disponível Operando no final do Loop
1 2 15.0   85.0 1
2 0   0.0 100.0 1
3 0   0.0 100.0 1
4 0   0.0 100.0 1
5 1   6.1   93.9 1
6 0   0.0 100.0 1
7 0   0.0 100.0 1
8 0   0.0 100.0 1
9 0   0.0 100.0 1
10 1   7.6   92.4 0

MÉDIA:

  97.1 0.9

Assim, a média do tempo disponível no fim da simulação é de 97,1 horas. A disponibilidade média é calculada dividindo a média do tempo disponível pelo tempo total da operação ou 97,1/100 = 97,1%. A disponibilidade pontual em 100 horas é de 90%, desde que o sistema seja considerado como operando em 9 dos 10 loops. Isto é incomum, a disponibilidade do pontual é geralmente mais elevada do que a confiabilidade média. Isto mostra o perigo de executar uma simulação com um pequeno número de loop. Se nós usássemos um número maior de loop, a disponibilidade pontual, muito provável seria maior do que a disponibilidade média. 

Isto dá um exemplo simples de como é trabalhado a simulação da disponibilidade no BlockSim. Obviamente, o processo é mais complexo ao se tratar dos sistemas complexos. Nenhuma distinção foi feita entre o componente e a falha do sistema neste exemplo, mas em simulações de sistemas complexos devem-se tomar mais cuidado, se a falha do componente resulta em uma falha do sistema, se alguns componentes acumulam o tempo em que o sistema está indisponível, se há uma manutenção preventiva programada, etc.. O processo pode ser visto como uma questão contábil de manter-se disponível e indisponível dos componentes individuais assim como para o sistema inteiro.

 

Copyright © 2005 ReliaSoft Brasil, TODOS DIREITOS RESERVADOS

 

[Home]   [Softwares]   [Treinamentos]   [Consultorias]   [Painel de Confiabilidade]   [A Empresa]   [Clientes]   [weibull.com]

Copyright ©1998-2006 ReliaSoft Brasil, Todos os Direitos Reservados
Última Alteração: 17-10-06
 

LEGAL [Termos de Uso] [Links]
[Privacidade das Informações]

Contate Webmaster
Tel:
+55 11 2177-5456