© 1998-2022 Compass (Reliasoft Brasil Ltda.) Todos Os Direitos Reservados

© 1998-2022 Compass (ReliaSoft Brasil Ltda.
)
TODOS OS DIREITOS RESERVADOS
“Este material é de propriedade exclusiva da Compass e a sua utilização é somente

e exclusivamente autorizada para fins didáticos das pessoas expressamente
autorizadas pela Compass, sendo expressamente proibida a sua cópia, reprodução,
“download", distribuição, modificação, republicação ou quaisquer outras formas de
retransmissão sem a prévia e expressa autorização da Compass.”
Análise e Otimização da Confiabilidade,
Manutenibilidade e Disponibilidade de
Sistemas
(G522A)
Softwares de Apoio:
Notas Sobre o Curso
Estas notas são destinadas a

facilitar a compreensão do
material utilizando um
formato de apresentação.
A maioria das derivações

matemáticas e outros
detalhes de apoio foram
omitidas.
A cobertura do “Livro Texto"

pode ser encontrada em
referenciais teóricos da
ReliaSoft.
Referências Adicionais
Sistema de Confiabilidade e Princípios de Análises de Princípios de Análises de

Mantenabilidade Dados de Vida Testes Acelerados
Utilizados na definição de
compartilhamento de carga
Cobertura mais completa Usado para definir itens, bem como a obtenção
deste material do curso. distribuições para todos os de distribuições de vida do
eventos probabilísticos. nível de utilização para os
componentes.
Essas referências são publicadas na web em http://www.ReliaWiki.org.

Hipóteses / Pré-requisitos
• O conhecimento da teoria e princípios

de Análise de Dados de Vida.
• Ter concluído o curso "G400 -
Fundamentos de Engenharia de Análise
de Dados de Confiabilidade e
Modelagem" (ou ter conhecimentos
equivalentes).
• Familiaridade básica com os princípios
de probabilidade e estatística.
• Familiaridade com o MS Windows e
aplicativos como Word, Excel e
PowerPoint.
Typical Course Time Line (USA)
(May be adjusted*)
8:30 9:40 10:50 Lunch 13:00 14:10 15:20
Break
Break
Break
Break
até até até 11:45 am até até até
9:30 10:40 11:45 1:00 pm 14:00 15:10 16:30
Dia 1
Leitura Leitura
Dia 2
Leitura Leitura
Dia 3
Estudos de Caso em Grupo Estudos de Caso em Grupo
*Podem ser utilizadas dependendo do país / localização e horários de início

alternativas de local. Em tais casos, a linha de tempo pode ser alterada em
conformidade.
Introdução
Fundamentos da Confiabilidade de Sistemas
Have you heard of the wonderful one-hoss shay,

That was built in such a logical way
It ran a hundred years to a day,
And then of a sudden it -- ah, but stay,
I'll tell you what happened without delay,
Scaring the parson into fits,
Frightening people out of their wits, --
Have you ever heard of that, I say?
Oliver Wendell Holmes, “The Deacon’s Masterpiece,” 1858, Paragraph 1

Definindo um Sistema
• Neste curso, nós iremos definir um sistema como sendo uma

coleção de subsistemas, montagens e/ou um componente
arranjados de forma a alcançar uma funcionalidade desejada.
Sua definição de um “sistema” pode conter o número de níveis de análise que desejar.
Por exemplo, uma aeronave pode ser definida como um sistema com múltiplos
subsistemas e montagens. Ou, o trem de pouso da aeronave pode ser definido como um
sistema com múltiplas montagens e componentes.
Teoricamente, a definição de um sistema poderia chegar até o último nível possível.

Confiabilidade de Sistemas
Olhando para o Sistema
• Dado:
• Que um sistema é composto por componentes / subsistemas.
• As distribuições de vida (Confiabilidade) de um componente/subsistema
foram determinadas (estimada ou aproximada).
• Análise de Dados de Vida
• Testes Acelerados de Vida
• Dados de Campo
• Experiência do Engenheiro
• Dados de Projetos Similares
• Determine:
• O que é uma distribuição de vida (Confiabilidade) de um sistema?
Analisando o Sistema a Partir dos Componentes
• Realizar testes em sistemas para levantar a sua confiabilidade

pode ser impraticável.
• Pode ser mais fácil e mais barato testar
componentes/subsistemas e então testar o sistema completo.
• Tamanho
• Modos de Falha
• Controle das condições do teste
• Equipamento de teste
• Teste de vida é geralmente realizado pelos fornecedores dos

componentes.
Olhando para os Componentes
• A Confiabilidade de um componente é quantificada utilizando

um modelo matemático que descreve sua probabilidade de
falha (ou probabilidade de sucesso – Confiabilidade) para
diferentes idades.
• O “modelo” é uma função de densidade de probabilidade estatística
(pdf).
• Cada componente pode ser descrito por diferentes modelos.

Weibull
Componente Lognormal
A β, η Componente µ, σ
B
Normal
Componente µ, σ Exponential
C Componente λ
D
or MTBF
Nós podemos também entender um componente

como um “modo de falha” ou uma “função”.
• Utilize os modelos dos componentes para criar o modelo do

sistema.
Weibull
Componente
A β, η
Lognormal Sistema A
Componente µ, σ f(t)
B
Exponential
Θi
Componente λ
D
or MTBF
• Os tipos de componentes, suas quantidades, suas qualidades e

as configurações de projeto (arranjo lógico) tem efeito direto
na Confiabilidade de seu sistema.
• A Confiabilidade do sistema é derivada da Confiabilidade de seus
componentes.
• Os componentes possuem Confiabilidades que mudam com o passar
do tempo, bem como a do sistema.
Diagrama de Blocos de
Confiabilidade e Árvore
de Falha
Introdução aos RBDs
Introdução aos RBDs
• Utilizando a Abordagem de Diagrama de Blocos de Confiabilidade

(RBD) para Representar o Modelo de Confiabilidade do Sistema.
Chassis Undercarriage
Diagrama de Blocos de Confiabilidade (RBDs)
• Um Diagrama de Blocos de Confiabilidade é uma

representação gráfica dos componentes/subsistemas de um
sistema, e como eles estão logicamente (reliability-wise)
conectados.
• Pode ser entendido como um diagrama lógico de
Confiabilidade.
• É composto por:
• Blocos representam os componentes de um sistema.
• Linhas conectam os blocos.

• A disposição destas conexões definem a configuração de Confiabilidade
do sistema.
Blocos RBD
• Um bloco pode representar:

• Um componente
• Uma montagem (um subsistema ou sistema)
Subsistema Ignição
Bloco
Subsistema Freio
Subsistema Arrefecimento
.
.
.
etc.
Blocos RBD (continuação)
• Cada Bloco representa um componente, montagem, sistema

ou um subsistema de interesse.
• No mínimo um bloco de Confiabilidade pode incluir

informações de como o item falha (ex. o modelo de
Confiabilidade de um bloco).
Computer
Resistor
Blocos RBD (continuação)
• Os blocos de Confiabilidade possuem propriedades.

• Distribuição de Falha (requisito mínimo).
• Outras propriedades serão discutidas mais tarde.
Probability Density Function
2.400E-4
1.920E-4
Distribuição
Resistor
de Falha
1.440E-4
f(t)
9.600E-5
4.800E-5
0
0 1920.000 3840.000 5760.000 7680.000 9600.000
Time, (t)
Outras
Propriedades
Diagrama de Blocos de Confiabilidade
• Uma vez determinada as características de Confiabilidade, elas

podem ser conectadas de maneira lógica criando o Diagrama
de Blocos de Confiabilidade do sistema.
• Uma vez criado o RBD do sistema, este pode ser analisado para
determinar a Confiabilidade do sistema.
Componente Componente
A B
Introdução aos
Diagramas de Árvore de
Falhas
O que são Árvores de Falha?
• Um diagrama de árvore de falhas segue uma estrutura top-

down e representa um modelo gráfico dos caminhos dentro de
um sistema que pode conduzir a um evento previsível,
indesejável perda (ou falha).
• Os caminhos de conexão dos eventos e as condições de uso

são representados por meio de símbolos lógicos padrões.
• Probabilidades numéricas de ocorrência podem ser inseridas e

propagadas através do modelo para avaliar a probabilidade de
um evento indesejável, previsível de perda.
A Construção de Blocos de Árvores de Falha
EVENTO TOPO: • A falha de maior nível em que está

sob analise (evento de saída).
PORTA: • Símbolos lógicos que interligam os

Operador Lógico eventos e condições contributivas em
um diagrama de árvores de falha. Eles
determinam como as cadeias de
eventos (falhas) se propagam através
das árvores de falha.
EVENTO: •Contribuidores / indicadores (por

Falha Específica exemplo, falhas, erros humanos) ao
menor nível detalhado definido para a
análise. Eles são as entradas para a
Porta.
Passos para Construir uma Árvore de Falha
• Determinar um Evento Topo

• Qual é o evento previsível indesejável?
• Deve ser explicitamente definido.
• Deve valer a pena de se analisar/explorar.
• Definir o Escopo da Análise

• A amplitude da análise.
• Layout dos limites da análise.
• Determinar a granularidade da análise.
• Muito amplo: complica a análise.
• Muito estreito: O valor da análise fica comprometido.
Passos para Construir uma Árvore de Falha
• Identificar Eventos Contribuintes

• As causas dos eventos indesejados.
• Marcar o limite de resolução da análise (quais os eventos de nível mais
inferior).
• Relacionar os Acontecimentos / Efeitos com Portas Lógicas

• Trabalho Top Down.
Algumas Regras e Convenções
• Portas Lógicas não devem alimentar outras portas sem um

evento "intermediário".
NÃO SIM
Algumas Regras e Convenções
• Ser consistente ao nomear os mesmos eventos em toda a

árvore de falha.
• Indicar o que falhou e como.
Ex.: Contato do Temporizador falha ao Abrir
• Cada evento deve ser um colaborador imediato para o nível
acima.
Efeito
Causa
Algumas Regras e Convenções (continuação)
• As falhas em qualquer nível de análise devem ser

independentes*
(*) As Árvores de Falhas no

BlockSim permitem
algumas formas de
dependências tais como
Porta carga compartilhada,
porta Stand-by e Blocos
espelhos. Estes tópicos
Estes eventos são serão discutidos mais tarde
dependentes?
Tipos de Eventos para Árvores de Falha
Classificações de Árvores de Falhas
• Os diferentes eventos em uma árvore de falhas não são

tratadas de forma diferente vindo de uma perspectiva analítica
• As formas dos eventos são utilizados para transmitir
informações adicionais de uma forma visual
• Desde uma perspectiva de propriedades, todos eventos no
BlockSim podem ter probabilidades fixas, distribuição de
falhas, distribuições de reparo, equipes, sobressalentes, etc.
• Em outras palavras, blocos de evento de uma árvore de falha
podem ter todas as propriedades de um bloco de RBD. Isto é
um diferencial sobre as árvores de falhas tradicionais, as quais ,
de forma geral, incluem somente probabilidade fixa de
ocorrência e/ou taxas de falha constantes
TÍTULO
Evento Básico(Evento - Falha):

• Um evento básico inicial, ao qual não requer
desenvolvimento / desdobramento adicional
Evento Casa (Gatilho):

• Um evento que pode ser configurado para
ocorrer ou não ocorrer (que geralmente tem uma probabilidade
fixa, se for “0” Evento Casa Falho, se for “1”, Evento Casa Sempre
Funcionando).
• Normalmente usado para fazer caminhos de uma árvore
funcional ou não funcional.
• Observe que no BlockSim, um evento pode ser configurado
como “Não pode falhar” ou como “falho”
Classificações de Árvores de Falha
Evento não Desenvolvido

• Algumas propriedades com as de um evento
básico
• Representa um evento que poderia ter sido expandido dentro
de uma árvore de falha separada,
mas de fato não foi.
Evento Resultante:
• Especifica um Resultado.
• Possui todas as propriedades de um evento básico.
• Pode ser aplicado em qualquer porta
Classificações de Árvores de Falha
Evento Condicional:
• Especifica uma condição.
• Possui todas as propriedades de um
evento básico.
• Pode ser aplicado em qualquer porta
RBD vs. FTA
RBDs: FTs:
• Mais Fácil de construir • Mais fácil de construir quando
quando se modela sistemas se modela Modos de Falha
complexos • Tradicionalmente usado em
• Pode ser usado para análise de risco
identificar os pontos fracos • Pode ser utilizado para analisar
do projeto e para realizar a falhas, ou como uma
alocação de confiabilidade. ferramenta de investigação para
• Mais adequado para análise apontar causa raiz de um modo
de Mantenabilidade e de falha
Produção
Construção do RBD /
Árvore de Falhas - Básico
Configuração em Série
• Blocos são conectados em modo série.

• Podemos entender como um relacionamento lógico “OU”. “O
sistema falha se, A OU B falhar.”
• Isto implica em uma NÃO redundância dos componentes.
Componente Componente
A B
Configurações em Série
• Um sistema pode possuir itens conectados em série quando a

falha de qualquer item resulta na falha de todo o sistema.
Se itens estão conectados em série, então todos necessitam estar funcionando

para que o sistema também esteja. Se qualquer um dos itens em série falhar,
então o sistema também falha.
x
Visualize como uma corrente…se qualquer elo da corrente romper, então o
sistema “corrente” falha.
TÍTULO
Now in building of chaises, I tell you what,

There is always somewhere a weakest spot, --
In hub, tire, felloe, in spring or thill,
In panel or crossbar, or floor, or sill,
In screw, bolt, thoroughbrace, -- lurking still,
Find it somewhere you must and will, --
Above or below, or within or without, --
And that's the reason, beyond a doubt,
A chaise breaks down, but doesn't wear out.

Configurações em Série: Quantificações
• Todos os itens em série necessitam ter sucesso para que a

missão tenha sucesso:
• A Confiabilidade do sistema é a probabilidade de que o item 1 tenha
sucesso e que o item 2 tenha sucesso..., e que todos os n itens em
série no sistema tenham sucesso.
• A Confiabilidade do sistema é dada por:
𝑅𝑅𝑆𝑆 = 𝑅𝑅1 × 𝑅𝑅2 × ⋯ × 𝑅𝑅𝑛𝑛

Isto é similar à determinação da probabilidade de conseguir dois 6 em um jogo de dados. O
primeiro bloco é a probabilidade de conseguir 6 no primeiro dado (1/6) e o segundo bloco é
a probabilidade de conseguir o segundo 6 no segundo dado (1/6). Para ambos ocorrerem,
então eles estão conectados em uma configuração série com uma probabilidade de 1/36.
Rolling Rolling
6 6
Exemplo de Configurações em Série
• Três subsistemas estão conectados em série compondo um

sistema, e possuem as seguintes Confiabilidades para 100 h.
• Subsistema 1 tem uma Confiabilidade de 99,5%
• Qual é a Confiabilidade do sistema para uma missão de 100 h?
Sub 1 Sub 2 Sub 3

Solução do Exemplo
• Já que os subsistemas estão especificados para 100 h, a

Confiabilidade do sistema para uma missão de 100 h é
simplesmente calculada por:
𝑅𝑅𝑠𝑠 = 𝑅𝑅1 × 𝑅𝑅2 × 𝑅𝑅3

𝑅𝑅𝑠𝑠 = 0.9950 × 0.9870 × 0.9730
𝑅𝑅𝑠𝑠 = 0.955549245 𝑜𝑜𝑜𝑜
𝑅𝑅𝑠𝑠 = 95.55%
Observe que neste caso a Confiabilidade do sistema é sempre

menor do que a Confiabilidade do pior componente!
Solução no BlockSim
Porta “Ou”
• A equivalência da configuração série é uma porta “OU”

• Em uma porta “OU”, o evento de saída ocorre se pelo um dos
eventos de entrada ocorrer
• Em termos de confiabilidade de sistemas, isto implica que se
qualquer componente falhar (entrada), então o sistema irá
falhar(saída). (Sem redundância nestes componentes)
Configuração Paralela Simples
• Um sistema pode também possuir itens conectados em

paralelo (redundância); quando todos os itens necessitam
falhar para que o sistema também falhe.
• Podemos entender como um relacionamento lógico “E”. Ex.“O
sistema irá falhar se o item 1 E o item 2 E … e os n itens
falharem.”
n
Configuração Paralela Simples Quantificação
• No mínimo um dos itens em paralelo necessita ter sucesso para que a

missão tenha sucesso.
• A probabilidade de falha é a probabilidade de que o item 1 falhe, e o item 2
falhe, e …, e o n-ésimo item falhe.
• A Confiabilidade do sistema (assumindo independência) é dada então por:
𝑹𝑹𝑺𝑺 = 𝟏𝟏 − [ 𝟏𝟏 − 𝑹𝑹𝟏𝟏 × 𝟏𝟏 − 𝑹𝑹𝟐𝟐 × ⋯ 𝟏𝟏 − 𝑹𝑹𝒏𝒏 ]
Este conceito é similar à determinação da probabilidade de se obter pelo menos um seis

quando jogamos dois dados. O primeiro bloco é a probabilidade de se obter um seis
jogando o primeiro dado (1/6) e o segundo bloco a probabilidade de se obter outro seis
jogando o segundo dado (1/6). Para que qualquer um dos dois dados apresente seis, então
eles estarão configurados em paralelo com uma probabilidade de 11/36 (quase 1/3).
Configurações Paralela Simples Exemplo
• Considere o mesmo subsistema do exemplo anterior onde:

• subsistema 1 possui uma confiabilidade de 99,5%
• Determine a confiabilidade do sistema (para 100 h) se os
subsistemas estivesse conectados em paralelo.
Example Solution
• Já que os subsistemas estão especificados para 100 h, a

Confiabilidade do sistema para uma missão de 100 h é
simplesmente calculada por:
𝑹𝑹𝑺𝑺 = 𝟏𝟏 − 𝟏𝟏 − 𝟎𝟎. 𝟗𝟗𝟗𝟗𝟗𝟗𝟗𝟗 × 𝟏𝟏 − 𝟎𝟎. 𝟗𝟗𝟗𝟗𝟗𝟗𝟗𝟗 × 𝟏𝟏 − 𝟎𝟎. 𝟗𝟗𝟗𝟗𝟗𝟗𝟗𝟗

𝑹𝑹𝑹𝑹 = 𝟏𝟏 − 𝟎𝟎. 𝟎𝟎𝟎𝟎𝟎𝟎𝟎𝟎𝟎𝟎𝟎𝟎𝟎𝟎𝟎𝟎𝟎𝟎
𝑹𝑹𝑹𝑹 = 𝟎𝟎. 𝟗𝟗𝟗𝟗𝟗𝟗𝟗𝟗𝟗𝟗𝟗𝟗𝟗𝟗𝟗𝟗𝟗𝟗 𝒐𝒐𝒐𝒐 𝑹𝑹𝑹𝑹 = 𝟗𝟗𝟗𝟗. 𝟗𝟗𝟗𝟗𝟗
BlockSim Solution
Porta E
• A equivalência da configuração paralela simples é a porta “E”

• Em uma porta E, o evento de saída ocorre se todos os eventos
de entrada ocorrerem
• Em termos de confiabilidade de sistemas, isto implica que
todos os componentes devem falhar (entrada) para a falha do
sistema (saída). (Presença de redundância
Arranjo Físico vs. Arranjo de Confiabilidade
• Considere o seguinte circuito:
3Ω
3Ω
3Ω
A resistência equivalente deve ser sempre menor do que 1,2W.

O sistema será considerado em falha se a resistência equivalente
for maior do que 1,2W
Desenhe o diagrama de blocos de Confiabilidade (RBD) para este
circuito.
Resistores – Situação 1
• Todos os três resistores funcionando:
𝟏𝟏 𝟏𝟏 𝟏𝟏 𝟏𝟏
= + + =
𝒓𝒓𝒆𝒆𝒆𝒆 𝒓𝒓𝟏𝟏 𝒓𝒓𝟐𝟐 𝒓𝒓𝟑𝟑
𝟏𝟏 𝟏𝟏 𝟏𝟏
+ + = 𝟏𝟏𝛀𝛀
𝟑𝟑 𝟑𝟑 𝟑𝟑
𝑅𝑅 < 1.2𝛺𝛺
• Um resistor falha:
𝟏𝟏 𝟏𝟏 𝟏𝟏 𝟏𝟏 𝟐𝟐
= + + =
𝒓𝒓𝒆𝒆𝒆𝒆 ∞ 𝟑𝟑 𝟑𝟑 𝟑𝟑
Assim: 𝒓𝒓𝒆𝒆𝒆𝒆 = 𝟏𝟏. 𝟓𝟓𝛀𝛀 > 𝟏𝟏. 𝟐𝟐𝟐𝟐
𝑅𝑅 > 1.2𝛺𝛺
• Dois resistores falham:
𝟏𝟏 𝟏𝟏 𝟏𝟏 𝟏𝟏 𝟏𝟏
= + + =
𝒓𝒓𝒆𝒆𝒆𝒆 ∞ ∞ 𝟑𝟑 𝟑𝟑
Assim: 𝒓𝒓𝒆𝒆𝒆𝒆 = 𝟑𝟑𝛀𝛀 > 𝟏𝟏. 𝟐𝟐𝟐𝟐
• Todos os três resistores falham:
𝒓𝒓𝒆𝒆𝒆𝒆 = ∞ > 𝟏𝟏. 𝟐𝟐𝛀𝛀
• Logo, todos devem operar para o funcionamento do sistema

Resistores Solução
• Se r1 ou r2 ou r3 ou qualquer combinação dos três falharem,

o sistema falhará.
Ou
• r1 e r2 e r3 devem ter sucesso para que o sistema também
tenha sucesso, portanto:
Resistor 1 Resistor 2 Resistor 3
Os resistores estão fisicamente conectados em paralelo

mas em série pela lógica de confiabilidade
Combinando Sistemas em Série
e Paralelo Simples
• Qualquer combinação dos tipos de arranjos apresentados

podem ser utilizados simultaneamente em um diagrama.
• Considere um sistema com cinco subsistemas. Subsistemas 1 e
2 são conectados em série e os subsistemas 3 e 4 são
conectados também em série, mas em paralelo com o
subsistema 5 (e estes em série com os subsistemas 1 e 2),
como mostrado a seguir:
Configuração Paralela k de N
(k-out-of-N)
• Assuma que uma aeronave de 4 turbinas necessite, no mínimo,

de 2 funcionado (quaisquer 2) para uma viagem segura. Neste
caso, as quatro turbinas estão conectadas em uma
configuração paralela 2 boas em 4 (2-out-of-4). Onde k = 2 e n
= 4.
Configuração Paralela k de N
(k-out-of-N)
Motor 1
Motor 2
Sistema não falha
Motor 3
Motor 4
Motor 1
Motor 2
Sistema falha
Motor 3
Motor 4
Construção de Nós
• Um nó é utilizado para representar uma redundância k de n (k-

out-of-n).
• A propriedade básica de um nó será definir o número de
caminhos (de entrada) “Bons” necessários para que o sistema
seja “Bom”
k/n
Construção de Nós
Porta M-de-N (Votante)
• Em uma porta votação, o evento de saída ocorre se “k” ou mais

dos eventos de entrada ocorrerem.
• Em termos de confiabilidade de sistema, isto implica que se k-
de-n componentes vierem a falhar(entrada), logo o sistema irá
falhar(saída)
• FTA: k-de-n falhas, para a falha do sistema
Portas de Árvores de
Falhas Adicionais
Porta Inversora (NOT)
• A Porta Inversora (NOT) funciona como um inversor

• Em confiabilidade de sistemas, o resultado da saída dos
eventos conectados a esta porta é invertido (Verdadeiro se
torna Falso e Falso se torna verdadeiro)
• No BlockSim esta porta está disponível somente em Diagramas
analíticos de árvores de falhas
Porta Inversora
• A porta inversora funciona apenas com probabilidades fixas

nos eventos de entrada, a qual é checada na análise.
Exemplo Porta Inversora (NOT)
• Três subsistemas seguindo a lógica de confiabilidade, estão

conectados em uma configuração “E”, formando um sistema,
estes possuem as seguintes confiabilidades em 100 horas
• Subsistema 1 tem confiabilidade de 99.5%,
• Subsistema 2 tem confiabilidade de 98.7%,
• Subsistema 3 tem confiabilidade de 97.3% para uma missão de 100
horas
• O sistema tem um alarme que só desliga se o sistema falhar.
Qual é a probabilidade do alarme disparar?
• Conforme as especificações de confiabilidade dos subsistemas

para 100 horas, a confiabilidade dos sistema para 100 horas
para uma simples missão será:
𝑅𝑅𝑠𝑠 = 1 − 1 − 0.9950 × 1 − 0.9870 × 1 − 0.9730
𝑅𝑅𝑠𝑠 = 1 − 0.000001755
𝑅𝑅𝑠𝑠 = 0.999998245 𝑜𝑜𝑜𝑜 𝑅𝑅𝑅𝑅 = 99.99%
𝑃𝑃𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎 = 1 − 𝑅𝑅𝑅𝑅 = 0.000001755
Porta Inversora E (NAND)
• A porta “Inversora E” funciona como

uma combinação das portas “E” e
Inversora.
• A porta Inversora E possui um falso
evento de saída se no mínimo 1 input
for verdadeiro. Possui também o
evento de saída verdadeiro quando
todos forem falsos
• Disponível somente nos diagramas de
FTAs Analíticas
• A porta “Inversora.E” trabalha somente
com probabilidades fixas como forma
de entrada, a qual é checada na
modelagem
Porta “Inversora OU”(NOR)
• A porta “Inversora OU” funciona como

uma combinação da porta “OU”e a da
porta “Inversora”
• A porta Inversora OU possui um falso
evento de saída se no mínimo 1 input
for falso. Possui também o evento de
saída verdadeiro quando todos eventos
forem ocorrerem
• Disponível somente nos diagramas de
FTAs Analíticas
• A porta “Inversora OU” trabalha
somente com probabilidades fixas como
forma de entrada, a qual é checada na
modelagem
Porta Inibidora
• Em uma Porta Inibidora, o evento de

saída ocorre se todos os eventos de
entrada ocorrerem e um evento
adicional ocorrer
• Isto é, uma porta “E” com um evento
adicional
• A porta Inibidora não fornece
possibilidades adicionais em questão de
modelagem
• BlockSim fornece de forma explicita a
porta Inibidora. Esta porta funciona
como uma porta “E” com a ressalva de
que as características de falha / reparo
podem ser atribuídas à própria porta.
Porta Inibidora
• Uma linha de gasolina danificada devido ao congelamento

consiste em um evento de interesse. Tal evento pode ocorrer
apenas quando a temperatura 𝑇𝑇 é inferior a 𝑇𝑇𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐
(temperatura na qual a gasolina congela) e também quando a
linha está funcionando em plena capacidade.
• Evento de Saída: Linha de Gasolina danificada devido à

congelamento
• Evento de Entrada: Funcionando em plena capacidade,
𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 = 0.1
• Entrada condicional:𝑇𝑇 < 𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇, 𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 = 0.05
Solução do exemplo de
Porta Inibição
𝑃𝑃 𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿 𝑑𝑑𝑑𝑑 𝑔𝑔𝑔𝑔𝑔𝑔𝑔𝑔𝑔𝑔𝑔𝑔𝑔𝑔𝑔𝑔 𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑

= 𝑃𝑃 𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹 𝑎𝑎 𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃 ×
𝑃𝑃(𝑇𝑇 < 𝑇𝑇𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐 )
= (0.1)(0.05)
= 0.005
Configurações
Complexas
Configurações Complexas
• Configurações complexas não podem ser expressas como

simples combinações de configurações série e/ou paralelo e
portanto requerem tratamento analítico mais avançado.
• Uma rede de computadores é um bom exemplo de um sistema
complexo.
B E
A C G
D F
Combinações Complexas
• Combinações complexas são necessárias quando::

• Muitas redundâncias estão presentes,
• Levantar a confiabilidade de sistemas de rede,
• Utilizando blocos para representar a análise de modos de falha,
• Executar análises diferentes de confiabilidade (como produção
(throughput)).
• etc.
Bridge
Quantificando a Confiabilidade
de Sistemas Complexos
• Existem diversos métodos para se obter a confiabilidade de

sistemas complexos, tais como:
• Método do Teorema de Bayes
• Método Boolean truth table
• Método do Mapeamento da Probabilidade
• Método dos Diagramas Lógicos
• Método da Decomposição
• Método dos Eventos Espaçados
• Método do Traçado do Caminho
• A solução utilizando estes métodos são bastante trabalhosas e
consomem muito tempo, portanto para estas análises
softwares serão utilizados.
• Os detalhes desses métodos está além do escopo deste
treinamento
Configurações Complexas em
Árvores de Falha
• No caso de configurações complexas, determinados cenários

(tal como no exemplo do RBD anterior) requerem construções
avançadas para serem criadas.
• Esta é uma das maiores desvantagens das análises FT quando
comparadas aos RBDs
Exemplo Motor de Avião
• No exemplo anterior do avião possuíamos um k de n (k-out-of-

n), onde a exigência eram 2 turbinas boas em 4. Entretanto se
alterássemos a exigência para:
• 2 boas em 4, porém 1 turbina BOA em cada lado.

Exemplo – Motor de Avião
• Então o diagrama iria mudar para:

Exemplo – Motor de Avião
• E o Diagrama em FTA fica da seguinte forma

Modos de Falha
• Um item pode possuir diversos modos de falha A, B, C, D, E, F.

• Assuma que o sistema falhe se:
• O modo de falha B, C ou F ocorrerem.
• O modo de falha A & E ou A & D ou E & D ocorrerem.
Mais Configurações Complexas
• Sistema de uma Aeronave

Álgebra Completa vs. Simbólica
representada no BlockSim
Dependência do Tempo
Introdução a dependência do Tempo
• Até Então, nós estimamos a Confiabilidade Estática do

sistema
𝑅𝑅𝑠𝑠 𝑅𝑅1 × 𝑅𝑅2 × 𝑅𝑅3
• Os valores de R1, R2, e R3 foram especificados como

constante (ex. a um dado tempo comum).
• A Confiabilidade foi estimada unicamente para este
tempo.
• Esta solução analítica (estática) da Confiabilidade pode ser
convertida para uma equação de Confiabilidade
dependente do tempo.
Quantificação
• A Confiabilidade de cada componente será função do tempo, e

cada componente irá seguir uma distribuição de vida.
𝑅𝑅𝑠𝑠(𝑡𝑡) = 𝑅𝑅1(𝑡𝑡) × 𝑅𝑅2(𝑡𝑡) × 𝑅𝑅3(𝑡𝑡)
• Agora a Confiabilidade do sistema poderá ser estimada para

qualquer tempo.
Exemplo
• Dado três componentes em série, cada um deles seguindo uma

distribuição de vida Weibull com parâmetros β1, η1, β2, η2, β3,
e η3 respectivamente, então a equação da Confiabilidade será:
𝒕𝒕 𝛽𝛽1 𝒕𝒕 𝛽𝛽2 𝒕𝒕 𝛽𝛽3

− − −
𝑹𝑹𝒔𝒔 𝒕𝒕 = 𝒆𝒆 𝜂𝜂1 � 𝒆𝒆 𝜂𝜂2 � 𝒆𝒆 𝜂𝜂3
Uma vez obtida a equação do sistema e mantendo-se as

distribuições características de cada bloco , bem como a
configuração do diagrama, não será mais necessário analisar
o sistema novamente.
Expandindo para Outras Distribuições
• De forma similar, qualquer distribuição de vida pode ser

substituída dentro da equação da Confiabilidade do sistema.
𝒕𝒕 𝛽𝛽1 𝒕𝒕 − 𝝁𝝁𝟑𝟑
− −𝝀𝝀𝟐𝟐 𝒕𝒕
𝑹𝑹𝒔𝒔 𝒕𝒕 = 𝒆𝒆 𝜂𝜂1 � 𝒆𝒆 � 𝟏𝟏 − 𝚽𝚽
𝝈𝝈𝟑𝟑
Weibull Exponential Normal

Determinando a pdf do Sistema
• Uma vez obtida a equação de Confiabilidade do sistema, a

função densidade de probabilidade (pdf) pode ser
determinada
𝒅𝒅(𝑹𝑹𝒔𝒔 𝒕𝒕 )
𝒇𝒇𝒔𝒔 𝒕𝒕 = −
𝒅𝒅𝒅𝒅
• Uma vez obtida a pdf, todas os outros cálculos de

Confiabilidade podem ser obtidos.
Na maioria dos casos será necessário utilizar
cálculos diferenciais (Numerical differentiation)
utilizando computadores.
Outros Cálculos de Confiabilidade
• A taxa de falha do sistema para qualquer tempo:
𝒇𝒇𝒔𝒔(𝒕𝒕)
𝝀𝝀𝒔𝒔(𝒕𝒕) =
𝑹𝑹𝒔𝒔(𝒕𝒕)
• O tempo médio até a falha do sistema:
∞
𝑴𝑴𝑴𝑴𝑴𝑴𝑴𝑴 = � 𝑹𝑹𝒔𝒔(𝒕𝒕)𝝏𝝏𝝏𝝏
𝟎𝟎
Será necessário utilizar o computador para
obter soluções numéricas na maioria dos
casos.
Remember from Life Data Analysis
• Dado uma 𝒑𝒑𝒑𝒑𝒑𝒑, 𝑓𝑓(𝑡𝑡)
𝑡𝑡 𝑑𝑑(𝐹𝐹 𝑡𝑡 )
• 𝐴𝐴 𝑐𝑐𝑐𝑐𝑐𝑐 será 𝐹𝐹 𝑡𝑡 = ∫𝑜𝑜 𝑓𝑓 𝑠𝑠 𝑑𝑑𝑑𝑑 também 𝑓𝑓 𝑡𝑡 =
𝑑𝑑𝑑𝑑
• A Função Confiabilidade será 𝑅𝑅 𝑡𝑡 = 1 − 𝐹𝐹(𝑡𝑡)

𝑓𝑓(𝑡𝑡) 𝑓𝑓(𝑡𝑡)
• A Taxa de Falha será 𝜆𝜆 𝑡𝑡 = = 𝑡𝑡
𝑅𝑅(𝑡𝑡) 1−∫𝑜𝑜 𝑓𝑓 𝑠𝑠 𝑑𝑑𝑑𝑑
∞
• A Vida Média Será �
𝑇𝑇 = ∫𝑜𝑜 𝑡𝑡 � 𝑓𝑓 𝑡𝑡 𝑑𝑑𝑡𝑡
Outros Cálculos de Confiabilidade
• O tempo de garantia (tempo no qual a Confiabilidade estará

dentro de um certo nível especificado):
• Resolva a equação da Confiabilidade do sistema para qualquer tempo,
t:
𝒕𝒕 𝛽𝛽1 𝒕𝒕 − 𝝁𝝁𝟑𝟑
− −𝝀𝝀𝟐𝟐 𝒕𝒕
𝑹𝑹𝒔𝒔 𝒕𝒕 = 𝒆𝒆 𝜂𝜂1 � 𝒆𝒆 � 𝟏𝟏 − 𝚽𝚽
𝝈𝝈𝟑𝟑
Numerical solutions using a computer will be

required in most cases.
Confiabilidade Condicional
(Componentes já utilizados)
• Um bloco que já possua
alguma idade também
pode ser utilizada em um
RBD.
• A equação da
Confiabilidade será obtida
pela Confiabilidade
condicional, ou:
R(t + T )
R(t ; T ) =
R(T )
Onde :
T = Idade _ atual
t = Tempo _ da _ missão
Confiabilidade Condicional
(Componentes já utilizados)
• Um bloco que já possua
alguma idade também
pode ser utilizada em um
RBD.
• A equação da
Confiabilidade será obtida
pela Confiabilidade
condicional, ou:
R(t + T )
R(t ; T ) =
R(T )
Onde :
T = Idade _ atual
t = Tempo _ da _ missão
Ciclo de Operação
• O Ciclo de Operação permite que o usuário especifique a

quantidade de utilização do bloco como sendo uma fração da
utilização do sistema.
• Componentes do sistema podem não operar continuamente durante a
missão do sistema. Por exemplo:
• Componente A operando continuamente deveria possuir um Ciclo de
Operação de 1.
• Um drive de CD-ROM em um computador pode acumular somente 10
minutos de utilização a cada hora de operação do computador, e poderia
possuir um Ciclo de Operação de 0,167.
• Componentes podem estar sujeitos a maiores ou menores
carregamentos do que o valor da carga nominal durante a operação.
• Um valor maior do que 1 indica um carregamento que excede o valor da
carga nominal.
• Um valor menor do que 1 indica um carregamento menor do que o valor
da carga nominal.
• Ele pode também ser utilizado para levar em consideração as
alterações no meio ambiente (estressamento) que possam afetar a
operação do componente.
Ciclo de Trabalho
(duty cycle)
dc: ciclo de trabalho

t: tempo da missão
t′: idade acumulada
t' = dc × t
A confiabilidade do
Componente é:
R(t') = R(dc × t)
Revisão - Diagrama de Blocos Dependentes do
Tempo
• Um sistema dependente do tempo pode ser

representado por um diagrama de blocos de
Confiabilidade (RBD).
• Utilizando leis de probabilidade, o diagrama
pode ser reduzido a uma equação que
apresentará a probabilidade de sucesso, ou a
equação de Confiabilidade para um dado
tempo (a cdf do sistema).
• Através da cdf, nós podemos obter a pdf do
sistema.
• Uma vez obtidas as pdf/cdf do sistema, todos
os outros cálculos de interesse podem ser
derivadas.
Exercício Prático
• Faça este exercício em Grupos

• Grupos de 2 a 3 Pessoas.
• O software utilizado será o BlockSim.
• As respostas serão fornecidas no slide posterior ao exercício
Exercício Prático
Sistema de Supressão de Fogo
• Um sistema de supressão de fogo é composto de duas unidades de sensores (no mínimo

1 deve funcionar), uma unidade de controle, e uma unidade de pulverização de água.
• Os valores de confiabilidade estão na tabela abaixo
Unit Modelo de Confiabilidade

(anos)
Sensor 2-P Weibull:
Beta = 1.3, Eta = 10
Controlador Lognormal:
Log-Mean = 3, Log-Std = 0.2
Pulverizador 2-P Weibull:
Beta = 3.0, Eta = 20
• Qual é a confiabilidade do Sistema depois de 3 anos?

• Depois de quantos anos a confiabilidade irá chegar em 90%?
Exercício
Sonda Espacial
• Uma sonda espacial é lançada para explorar o sistema

solar.
• Depois de quatro anos, a sonda chegou a Plutão. Chegar a
final do sistema solar (borda), provavelmente irá levar um
tempo adicional de 8 anos.
• A sonda tem um sistema de navegação, um sistema de
energia, e conjuntos de dois propulsores de cada lado (um
Tipo 1 e um Tipo 2). Se ambos os propulsores falharem do
mesmo lado, ou se o sistema de navegação ou o sistema
de energia falhar, a missão falha.
Exercício
Sonda Espacial
• Dados da Confiabilidade:
Item Modelo de Confiabilidade
(anos)
Propulsor tipo 1 Exponencial:
MTTF: 25
Propulsor tipo 2 Exponencial:
MTTF: 35
Navegação Exponencial:
MTTF: 100
Sistema de Energia Exponencial:
MTTF: 150
• A NASA gostaria de usar árvores de falhas para determinar a probabilidade da
sonda chegar até a borda do sistema solar. Se todos os quatro propulsores
foram tipo 2, qual seria a probabilidade de sucesso?
Sistema de Supressão de Fogo
• 1. R = 0,961
• 2. t(R=0,9) = 4,52 anos, ou vida B10
Sonda Espacial
• 1. R = 0,715
• 2. R = 0,751
Redundâncias
Complexas(RBD) / Portas
Avançadas(FTA)
Esquemas de Redundâncias Complexas
Configurações Load Sharing

Em uma configuração load
sharing, se um componente
falha, então o outro
componente(s) sofre um
aumento de carregamento para
manter o sistema operando.
Configurações Standby
Em uma configuração standby, um
ou mais componentes estão
disponíveis para substituir o
componente ativo, se este falhar.
Introduzindo o Conceito de Containers
• Um container define a relação dos blocos (ou diagramas) para

as configurações load sharing e standby.
Configurações Load
Sharing
Load Sharing
• Quando os componentes de um sistema operam em uma

configuração load sharing (dependente), cada
componente suporta uma parte da carga total para o
funcionamento do sistema.
• Quando um ou mais componentes falham, os
componentes que sobraram em operação necessitam
suprir o carregamento do sistema de maneira a
compensar os itens em falha.
• Existe uma dependência entre os componentes
redundantes (lembre-se: a independência foi assumida para
configurações paralela simples).
Load Sharing
• As definições de um container load sharing.

• Um container define a quantidade de carregamento que será dividido pelo
componentes (ou uma combinação de itens) contidos no container.
• Um container pode também ser utilizado para definir o número de itens requeridos,
k/n.
• Não existe um único ponto de início requerido. Cada novo ponto de início define
um novo componente em load sharing.
Load Sharing Gate
3 3
Fator de Proporcionalidade de Carregamento
• Define a porção de carregamento que um item em particular pode

suportar quando operando, bem como a transição de
carregamento para os itens que continuarem funcionando após
um item falhar.
• Assuma que 3 itens (1, 2 e 3) são inseridos em um container load sharing com um
fator de proporcionalidade de carregamento de 1, 2 e 3 respectivamente (em uma
configuração de 1 bom em 3).
• Item 1 suporta [1/(1+2+3)]=0,166 ou 16,6% do carregamento total.
• Item 2 suporta [2/(1+2+3)]=0,333 ou 33,3% do carregamento total.
• Item 3 suporta [3/(1+2+3)]=0,50 ou 50% do carregamento total.
O carregamento atual de cada item torna-se então o produto do

carregamento total definido no container (ex. 100 lbs) vezes a porção
suportada pela aquele item (0,166 para 1), ou 100*0,166=16,6.
Fator de Proporcionalidade
de Carregamento
• Computando o carregamento quando um ou mais

componentes falham.
• No exemplo anterior, assuma que o item 1 falhou, causando uma
sobrecarga nos itens 2 e 3. Então:
• Item 1 falhou.
• Item 2 suporta [2/(2+3)]=0,40 ou 40% do carregamento total.
• Item 3 suporta [3/(2+3)]=0,60 ou 60% do carregamento total.
Load Sharing Gate
Definindo a Distribuição de Falha
• A distribuição a ser definida é a distribuição de falha

que o bloco teria se estivesse operando com a carga
total.
• Assim como um bloco padrão, isto pode ser:
• Uma simples distribuição de falha.
• Uma distribuição de falha e uma relação vida-estresse para
uma carga específica.
Ilustrando o Load Sharing
• Considere um sistema composto por dois itens conectados em

paralelo, onde necessitam fornecer uma tensão de saída de 8
volts.
• Se ambos estiverem em operação, então cada componente irá
gerar 50% do total da tensão se saída.
• Qual será a Confiabilidade do sistema para 2,500 horas (1 ano de
operação)?
Modelando o Load Share
O primeiro passo é determinar a distribuição de

falha para cada item.
Assuma que quando cada item opera em carga
total de 8 volts, a distribuição de falha é uma
Weibull com β = 1,92 e Ƞ = 2,504
Para este exemplo, os Itens 1 e 2 são o mesmo componente.

Portanto, um único conjunto de dados foi coletado.
Entretanto, é possível que os componentes que
compartilham carga não sejam os mesmos. Se este for o
caso, será necessário coletar dados par cada componente.
• A Confiabilidade do sistema a um dado tempo, t, deve ser

calculado diferentemente de maneira a levar em consideração as
dependências.
• Para este simples exemplo, a seguinte equação será utilizada:
• Onde:
• P1 e P2 representam a porção total do carregamento de cada item
que está fornecendo quando ambos estão operacional, S1 e S2
representam o load share que o Item 1 e o Item 2 devem suportar,
respectivamente, quando ambos estão em operação, e S é o total de
tensão de saída requerido.
• t1e é o tempo equivalente de operação para a unidade 1 se esta
tenha operado sob S em vez de S1.
• Uma representação gráfica de te é apresentada na figura a seguir. A
linha vermelha representa o baixo estressamento (load) e a linha
verde representa o alto estressamento (load).
Outros Exemplos Load Share
• Considere a Carruagem “One Hoss Shay.”

• Os aros (spokes) podem estar em redundância load share.
Configurações Standby
Itens Standby
• Itens em redundância standby são considerados “inativo ou

passivo” até serem necessários. Eles se tornam ativo quando a
unidade primária falhar.
• Itens podem consumir idade e falhar quando inativos.
• Um container pode novamente ser utilizado para definir uma
configuração standby.
Standby Gate
Containers / Portas Standby
• Definições de containers standby.

• Itens em um container standby são considerados em
redundância standby.
• O container também representa o mecanismo de comutação
(switching). Ele será responsável por tornar o item ativo on/off.
• Um container standby pode falhar e ser reparado. Uma falha do
container não causa falha dos sistema. Entretanto, uma falha do container
standby não irá ativar os itens se necessário.
• O container será também utilizado para definir o número
necessário de itens ativos, k/n.
• Não existe um único ponto de início requerido. Cada novo ponto
de início define um novo componente em standby.
Distribuição de Falha
Standby
• Os Blocos contidos em um container standby possuem duas

distribuições de falha.
• Distribuição de falha Ativa (como o item falha quando operando).
• Distribuição de falha em repouso - quiescent (como o item falha quando em standby).
• A suposição de danos acumulados será utilizada:
• Existe uma dependência entre a quantidade de tempo que cada componente esteve
em cada estado.
e1 Ativo
S2
S1 t1
Standby
t
Containers (Mecanismo de Comutação - Switching )
• O Container como um Mecanismo de Comutação - Switching

• A distribuição de falha em repouso (Quiescent) e a probabilidade de falha quando em
uso (ex. A probabilidade de performance do comutador quando em operação (se este
for infalível), ao longo das tentativas.
Container
Standby
(Comutador
Switch)
Mecanismo
de Comutação
Confiabilidade Comutador Ativo
• Probabilidade de comutação
quando requisitado (switching per
request)
• Probabilidade de comutação em
uma nova tentativa se ele falhar
• Numero de tentativas foi feita.
• Tempo (delay) entre
requisição e comutação.
Containers (Mecanismo de Comutação - Switching )
• Probabilidade de falha do comutador pela sua idade. Por exemplo, o

comutador deveria se degradar (wear-out) com a idade (ex. corrosão,
degradação do material, etc.).
• O comutador poderia falhar após ativar o componente. Se o componente
ativo não falhar até o fim da missão, e o comutador falhar, então o
sistema não falhará.
• Se o componente ativo falhar e o comutador também falhar, então o
sistema não poderá ser comutado para o componente em standby e
portanto o container falhará.
Container
Standby
(Comutador
Switch)
Probabilidade do Switch
• A probabilidade de que o comutador irá realizar sua função (ex.

comutação) quando requisitado.
• Isto será chamado de Probabilidade de Comutação por Requisição
(Switch Probability per Request) e será expresso como uma
probabilidade estática (ex. 90%).
A
Confiabilidade Comutador Ativo
• Probabilidade de comutação
quando requisitado (switching per
request)
sb • Probabilidade de comutação em
uma nova tentativa se ele falhar
• Numero de tentativas foi feita.
• Tempo (delay) entre requisição e
comutação.
Observações Sobre o Switch
• Observe que a metodologia utilizada NÃO é a mesma se

estivéssemos tratando um comutador como um componente
em um subsistema standby.
• Isto só seria válido se a falha do comutador pudesse resultar na falha
do sistema (ex. comutador falhar em aberto).
• Se a falha do comutador causa a falha do subsistema standby,
então o comutador pode ser modelado como um bloco
independente e em série com o subsistema standby.
Termos Utilizados Pelas Indústrias
• Cold Standby
• Componentes em standby não podem falhar quando em modo standby
(ex. Não existe distribuição de degradação em repouso - quiescent).
• Warm Standby
• Componentes em standby possuem a taxa de falha reduzida, quando
em modo standby, em relação a quando estão em modo ativo.
• Hot Standby
• Componentes standby possuem a mesma distribuição de falha em modo
standby do que quando em modo ativo (ex. um caso paralelo).
Para definir qualquer uma dessas opções no BlockSim, tudo o

que você precisa é definir apropriadamente a distribuição de
Repouso - Quiescent.
Ilustrando Termos
• Dois componentes estão em uma configuração standby.

• Componente 1 está ativo e tem uma distribuição de falha Weibull (beta=1,5,
eta=1000).
• Componente 2 está em standby. Quando o Componente 2 esta operando,
ele tem uma distribuição Weibull com β =1,5 e η =1000.
• Para a distribuição de degradação em repouso (quiescent) considere três
diferentes cenários:
• Mesma distribuição de quando está operando (hot standby).
• β=1,5, η=2000 (warm standby).
• Não pode falhar por degradação em repouso (quiescent) (cold standby).
Bloco no Container
Propriedades no BlockSim
Ativo (Energizado)
Distribuição de Falha para um bloco
no Container
Quiescent (em repouso)

Distribuição de Falha para um bloco no Container
Exemplo - Adicionando um Switch
• Assuma que quando o componente ativo falha, há 90% de

probabilidade de que o comutador irá comutar do componente
ativo para o componente standby.
• Além disso, assuma que o comutador pode também falhar

devido a uma falha por degradação, descrita por uma
distribuição Weibull com β = 1,7 e η=5000.
Propriedades do Container no BlockSim
Probabilidade de que o
Distribuição de falha para comutador irá executar a
um comutador quando ação de comutação com
operando (ex. esperando sucesso, e assumindo que
para executar a ação de o comutador está operando.
comutação).
Quantificando a Confiabilidade Standby
• A confiabilidade do sistema para um dado tempo, t, pode ser

calculada utilizando a seguinte equação:
t
R2, A (te + t − x)
R(t ) = R1 (t ) + ∫ f ( x) ⋅ R
0
1 2, sb ( x ) ⋅
R2, A (te )
⋅ Rsw,Q ( x) ⋅ Rsw, req dx
Onde:
R1 é a Confiabilidade do componente ativo,
f1 é a pdf do componente ativo,
R2,sb é a Confiabilidade do componente standby quando em modo standby (Confiabilidade em
repouso - quiescent),
R2,A é a Confiabilidade do componente standby quando em modo ativo,
Rsw,Q é a Confiabilidade em repouso (quiescent) do comutador,
Rsw,req é a probabilidade por requisição,
e
te é o tempo de operação equivalente para o item standby se este tenha operado no modo ativo.
Para esta formulação e o exemplo nós iremos considerar o caso de itens não reparáveis,
ex. quando um bloco ou container falham e não são reparados ou substituídos.
Confiabilidade do Sistema em Confiabilidade do Sistema em

Tipo Standby
1000 horas sem switch 1000 horas com switch
Hot 0.600439 0.572048
Warm 0.705684 0.663543
Cold 0.821201 0.764056
Porta Sequencial
• Esta variação da porta “E”, consiste em que cada evento

atrelado a porta, ocorra em uma sequencia. Em outras
palavras, eventos são obrigados a ocorrem numa sequência
específica e o evento de saída ocorre se todos os eventos de
entrada ocorrerem na sequência especificada
• Esta configuração é idêntica a uma redundância “Cold
Standby”,(ex. Unidades em Standby sem distribuição de falha
no estado de repouso “quiescent” e também sem
probabilidade de falha no Switch)
• No caso de múltiplos eventos Ativo/Standby, a sequencia é
determinada pela posição na árvore de falha, essa sequencia
segue da esquerda para direita
Porta Sequencial
• Esta configuração é idêntica a uma redundância “Cold

Standby”,(ex. Unidades em Standby sem distribuição de falha
no estado em repouso “quiescent” e também sem
probabilidade de falha no Switch)
Nota: No caso de
múltiplos eventos em
standby, a sequência é
determinada pela sua
posição na Árvore de
Falhas (a sequência vai
da a esquerda para a
direita)
Exemplo Porta Sequencial
Um circuito é protegido por 3

• Camada Externa
camadas ante estresse.
Quando o estresse é aplicado, • Camada do meio
a camada exterior se deteriora • Camada Interna

até que falhe. A camada
protetora do meio torna-se
vulnerável e começa a se
deteriorar. Quando se rompe
a camada interna torna-se
vulnerável.
Cada uma das camadas segue
com uma distribuição Weibull
com β = 1.5 and η = 1000.
“E” Prioridade
• Esta é uma Porta “E” onde o evento topo acontece se certos

eventos acontecem em uma ordem genérica.
• Ela se difere da porta Sequencial, permitindo que os eventos

possam ocorrer fora de uma sequencia definida.
Warm/Hot Warm/Hot
Construções Avançadas
• Construções RBD adicionais estão disponíveis no BlockSim.

• Como os containeres, estas não são construções RBD padrões,
mas melhorias da metodologia tradicional.
• As três construções adicionais são:
• Encapsulamento
• Multiplicidade
• Blocos Espelho
Encapsulando
• Um bloco pode encapsular um outro RBD e assim

receber as propriedades do RBD encapsulado.
• Isto permite criar e administrar de forma fácil RBDs complexos.
Comput Comput
er er
System System
1 2
Computer System 1 Computer System 2

Fan Fan
Power Power
Supply
Processor Hard Processor Hard
Supply
Drive Drive
Fan Fan
Encapsulando
Encapsulando (Link)
• Um encapsulamento padrão define um link direto com o

diagrama associado.
𝑅𝑅𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆
= 𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 1𝑅𝑅𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶 2
𝑅𝑅𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶 2 = (𝑅𝑅𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷(−𝑅𝑅𝐹𝐹𝐹𝐹𝐹𝐹𝑅𝑅𝐹𝐹𝐹𝐹𝐹𝐹 + 𝑅𝑅𝐹𝐹𝐹𝐹𝐹𝐹 + 𝑅𝑅𝐹𝐹𝐹𝐹𝐹𝐹))
𝑅𝑅𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶 1 = (𝑅𝑅𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷(−𝑅𝑅𝐹𝐹𝐹𝐹𝐹𝐹𝑅𝑅𝐹𝐹𝐹𝐹𝐹𝐹 + 𝑅𝑅𝐹𝐹𝐹𝐹𝐹𝐹 + 𝑅𝑅𝐹𝐹𝐹𝐹𝐹𝐹))

Encapsulando (Como Distribuição)
• No caso de diagramas muito complexos, o encapsulamento de

componentes (subdiagramas) pode ser representado por uma
única distribuição.
• Isto significa simplificar a análise, pela utilização de uma única
distribuição aproximada para a Confiabilidade, que substituirá
a solução exata (equação completa).
• Cuidados devem ser utilizados para assegurar que a
simplificação será apropriada para representar o componente
encapsulado.
• Se utilizada apropriadamente, esta simplificação irá permitir
obter resultados muito próximos da solução exata (equação
completa).
Solução Exata
RComputer 2= RPower SupplyRProcessorRHard Drive
(-RFanRFan+RFan+RFan)
Solucione para diferentes valores

de t e R adequando-se a RComputer 1
distribuição dada.
• Ilustrando:
β1
 t 
−    t − µ3  
Rs (t ) = e  η1 
⋅e − λ2t
⋅ 1 − Φ  
σ 
  3 
• Para R=1%, 2%, 3%, … 99% resolva por t.
• Utilize o Weibull++ (free form data) para se adequar a
distribuição.
• Realize o teste de aderência para escolher a distribuição mais
adequada.
• Selecione a distribuição adequada como a distribuição de falha
do bloco encapsulado.
Sistema - Computador
Comparação Link e Distribuição
Publicando o Modelo Analítico
• Além de poder publicar o modelo encapsulado de um RBD / FT

analítico, também é possível publicar o modelo analítico exato.
Desta forma, em vez de ter um único modelo de aproximação
do RBD / FT, a solução algébrica exata também pode ser
utilizada.
Blocos Espelhados
(Mirrored Blocks)
• Um bloco espelhado é a representação de um bloco idêntico

em um mesmo diagrama.
• Blocos espelhados permitem flexibilidades adicionais nas
modelagens de diagramas.
• Eles podem ser utilizados para modelar sistema mais complexos e
situações onde possam existir caminhos bidirecionais.
• Eles tornam-se úteis quando consideramos reparos e fatores de
restauração nos blocos.
• Ações de Manutenção e Restauração serão discutidas mais
tarde em outras sessões.
Blocos Espelhados
(Mirrored Blocks)
• As correntes elétricas que entram através de IN1 e IN2 podem

fluir em ambas as direções.
• Para que o sistema tenha sucesso é requerido que pelo menos
uma saída (O1, O2 ou O3) esteja funcionando.
O O IN
2 3 2
6 5 4
7 1 2
O IN
1 1
Blocos Espelhados
(Mirrored Blocks)
Multiplicidade
• Um único bloco pode representar múltiplos blocos idênticos.
6 Séries
6 Paralelos
Multiplicidade
Componente
A
N
RSystem = R
Mínimos Cortes
e Causas Comuns de
Falha
Mínimos Cortes
• Soluções Tradicionais (aproximações) de árvores de falhas,

envolve a determinação de Mínimos Cortes
• Mínimos Cortes são todas as combinações únicas das
falhas do componente que podem causar a falha do
sistema
• Especificamente, um conjunto de cortes pode ser
chamado de mínimo, quando qualquer evento básico for
removido do conjunto, os eventos remanescentes
coletivamente não possam ser mais cortados
• BlockSim não usa cortes mínimos pra resolver FTDs e
RBDs
Mínimos Cortes
• O Sistema irá falhar se {1,2, 3 e 4 falharem} ou {1, 2 e 3 fal} ou

{1, 2 e 4 falhar}. Todos estes são “cortes”. Porém, um corte
incluindo todos os componentes, não é um corte mínimo, pois
se 3 e 4 são removidos, os eventos restantes também é um
corte. Portanto, os mínimos cortes para esta configuração são
{1, 2 ,3} ou {1, 2, 4}.
Mínimos Cortes
• Cortes mínimos podem ser utilizados para entender uma

possível vulnerabilidade estrutural de um sistema
• Quanto menos cortes mínimos houver o sistema (ou
evento topo), menos vulnerável o sistema fica com a
combinação destes eventos.
• Por outro lado, diversos cortes indicam alta
vulnerabilidade
• Os Cortes também podem ser aplicados para descobrir
pontos isolados de falha(um elemento independente de
um sistema que pode causar perigo imediato para o
sistema devido a sua falha)
Tratando Modos de Falhas comuns
em Árvores de Falha
• Sistemas afetados por Modos de falha em comum, são

sistemas aos quais dois ou mais eventos tem o potencial
de ocorrerem devido a mesma causa
• Alguns modos de falha típicos:
• Impacto, vibração, pressão, fricção, tensão, falta de energia, umidade,
corrosão, erro de operação, superaquecimento, problemas com
eletromagnetismo, etc.
• Modos de Falha comuns, tem sido normamlemnte
manipulados com uso de Beta, MGL, Alpha e Modelos
BFR. O BlockSim utiliza, Blocos Espelho, uma abordagem
mais simples e mais efetiva
Tratando Causas de Falhas comuns
em Árvores de Falha
• O Evento A poderia causar uma falha “X”(se ela ocorrer junto

com o Evento B) e também em “Y” (se ela ocorrer junto com o
Evento C)
Sem o espelhamento, o
evento A seria
considerado com
independente e seria
contabilizado duas vezes
Exercício Prático

Exemplo Prático
Trem
• A National Cargo Corp. está trabalhando em um trem non-stop

de longa distância entre Los Angeles e Nova York.
• O trem é composto de 100 vagões e 2 conjuntos de 4
locomotivas (1 conjunto na frente e outro na parte de trás).
• Cada conjunto é composto por duas locomotivas que estão
operando e 2 que estão em cold stand-by
• Se mais de 2 locomotivas falharem, sistema falha. Se um ou
outro grupo falhar, o trem irá falhar.
• Por último, se qualquer um dos vagões falharem, o trem irá
falhar.
Exercício Prático
Trem
• A confiabilidade de cada locomotiva segue uma

distribuição Weibull de 2 parâmetros com Beta de 2,7 e
um Eta de 20.000 milhas.
• A confiabilidade de cada carro segue uma distribuição
Weibull 2 parâmetros com um Beta de 3 e um Eta de
250.000 milhas.
• Qual é a probabilidade do trem fazer a viagem de 2.800
milhas de Los Angeles para Nova York?
• Se a empresa quiser realizar uma parada para
manutenção quando a confiabilidade de uma viagem
estiver em 90%, quantas viagens o comboio pode fazer
sem paradas para manutenção?
Exemplo Prático
A Estudante de Graduação
• A estudante de graduação herdou um projeto de um aluno

antecessor.
• Um sistema de sensores para o projeto foi construído pelo
estudante anterior, que já utilizou este sistema por 20 vezes.
• Ela precisa executar 40 experimentos e registrar as leituras
destes sensores. Cada experimento leva 1 semana para ser
preparado e 1 dia para de execução. O sistema não envelhece
durante a preparação.
• Devido à natureza do experimento, o sensor do sistema não
pode ser reparado, e construir um novo pode demorar até 6
meses.
Exemplo Prático
A Estudante de Graduação
• O sistema tem 5 componentes

Unit Reliability Model
(hrs)
Sensor 32-Bit 2-P Weibull
Beta = 1.7, Eta = 2200
Sensor 64-Bit 2-P Weibull

Beta = 1.6, Eta = 2000
Conversor de dados 2-P Weibull

Beta = 1.5, Eta = 5000
Base de Dados 32-bit 2-P Weibull

Beta = 2, Eta = 4500
Base de Dados 64-bit 2-P Weibull

Beta = 2, Eta = 4000
Hands On Example
The Graduate Student (cont’d)
• O sistema irá falhar com os seguintes cenários:

• Ambos sensores falharem
• Ambos bancos de dados falharem
• Sensor 32-bit, conversor de dados e a base de dados 64-bit falharem
• Sensor 64-bit, conversor de dados e a base de dados 32-bit falharem
• Qual é a probabilidade da estudante gravar todos os dados que ela
precisa e estar apta a se formar no tempo adequado?
• Qual é a probabilidade de que a aluna atual e o próximo aluno
estejam capazes de usar o sistema em 40 experiências cada um?
• Qual é a diferença de probabilidades para o próximo aluno se a
nossa atual estudante já concluiu com sucesso os seus
experimentos?
Exercício Trem
• 1. R = 0,9999
• Se calculado a partir de t = 0, então a resposta será 6. No
entanto, se estiver usando confiabilidade condicional por
assumir que o trem fará as viagens anteriores, então a
resposta será 7 viagens.
The Estudante de Graduação
• 1. R = 0,817
• 2. R = 0,437
• 3. R = 0,535, portanto a diferença é de 9.8%
Importância da
Confiabilidade
TÍTULO
But the Deacon swore (as deacons do,

With an "I dew vum," or an "I tell yeou")
He would build one shay to beat the taown
'n' the keounty 'n' all the kentry raoun';
It should be so built that it couldn' break daown:
"Fer," said the Deacon, "'t's mighty plain
Thut the weakes' place mus' stan' the strain;
'n' the way t' fix it, uz I maintain, is only jest
T' make that place uz strong uz the rest."

Oportunidades de Melhoria
• A importância da Confiabilidade para cada

componente individual em um sistema irá
variar.
• Nós precisamos encontrar uma maneira de
identificar a importância relativa de cada
componente para o sistema.
Importância do Componente
• Antes de melhorar um componente de um sistema, seria útil

obter o valor da importância da Confiabilidade de cada
componente para o sistema.
• Esta análise irá determinar onde devemos concentrar nossos
esforços de melhoria.
• A importância da Confiabilidade de um componente é baseada
em sua distribuição de falha e sua correspondente posição no
sistema.
A importância de três componentes em série será diferente se

os mesmos três componentes estivessem em outra
configuração, ex. paralelo.
Quantificando a Importância da Confiabilidade
• Se podemos obter uma solução algébrica para a equação da

Confiabilidade do sistema, então:
• Pegando a derivada, em relação a um componente, desta
equação obteremos uma medida (taxa).
• Esta taxa seria uma taxa relativa que indica a taxa de mudança
da Confiabilidade do componente.
• Em outras palavras, a quantificação da importância de um
componente pode ser definida como um índice que
representará como o aumento da Confiabilidade de um
componente individual irá contribuir para o aumento da
Confiabilidade do sistema.
Quantificando a Importância da Confiabilidade
• A quantificação relativa “Importância da Confiabilidade” é

dada por:
∂RS
I Ri =
I Ri =
∂Rs
∂Ri
∂Ri
RS
Gráfico de Barra da
Importância Estática IR
∂RS (t = T )
I R i (t = T ) =
∂Ri (t = T )
Visão Tableau da
Importância Estática IR
Dependência do Tempo, IR(t)
TÍTULO
• A quantificação da Importância da Confiabilidade

pode ser obtida da equação do sistema.
• Ela apresenta a importância relativa da Confiabilidade
de cada componente sobre a Confiabilidade do
sistema todo.
• Ela apoia na priorização das ações sobre a
Confiabilidade dos componentes.
Alocações Otimizadas da
Confiabilidade
TÍTULO
So the Deacon inquired of the village folk

Where he could find the strongest oak,
That couldn't be split nor bent nor broke, --
That was for spokes and floor and sills;
He sent for lancewood to make the thills;
The crossbars were ash, from the the straightest trees
The panels of whitewood, that cuts like cheese,
But lasts like iron for things like these;

Alocação da Confiabilidade Tradicional
• Dado um simples sistema composto por três componentes em

série com a Confiabilidade meta de 95% para 100 horas, qual
deveria ser a Confiabilidade de cada subcomponente?
• Em outras palavras, resolva cada Ri(t=100) de tal maneira que RS
(t=100) seja 95%.
Rs (100) = R1 (100) ⋅ R2 (100) ⋅ R3 (100)

Problemas da Alocação da Confiabilidade
Tradicional
• Infelizmente, existem múltiplas soluções que satisfazem a

equação do sistema.
Rs (100) = R1 (100) ⋅ R2 (100) ⋅ R3 (100)
• Qual deveria ser a melhor solução?

...a mais econômica!!!
Escolhendo a Solução Otimizada
• Na escolha da melhor (ótima) solução, as seguintes considerações

deveriam ser analisadas:
• A Confiabilidade atual de cada componente, RCurrent.
• A Confiabilidade máxima possível para cada componente, RMax.
• O nível de dificuldade (ou custo) relativa ao aumento da Confiabilidade de
cada componente.
• Questões de Projeto.
• Questões de Fornecimento.
• Questões Tecnológicas.
• Questões de Time-to-market
• …
• O cenário para a alocação ótima deveria ser aquele que estivesse
de acordo com estas questões e minimizasse a dificuldade (ou
custo).
Quantificando o Problema
• De maneira a encontrar a melhor solução, nós devemos ser capazes

de quantificar o problema.
• Em outras palavras, quantificar o que nós queremos minimizar.
• Uma equação deve ser utilizada para expressar a quantificação de interesse.
Esta equação será função da Confiabilidade (já que a Confiabilidade é o que
queremos estar variando), ou
C = f (R)
• Nós podemos chamar esta quantificação de (C) nosso “fator penalização” ou
“fator custo,” e a equação nossa “função penalização” ou “função custo.”
O que nós vamos escolher para denominar este fator não é tão importante,
quanto os princípios por detrás desta formulação. Nos próximos slides nós
iremos utilizar o termo “função custo”, já que o fator de maior interesse em
qualquer empresa pode ser quantificado em termos de seus custos.
Definindo uma Função de Custo
• Para que a função custo esteja de acordo com o problema, as

seguintes condições devem ser adicionadas:
• A função deve estar de acordo com a mínima e a máxima
confiabilidade de cada componente (ex. a Confiabilidade deve
ser menor do que 1 e maior do que zero).
• A função não deveria ser linear, e sim poder quantificar a
dificuldade a cada incremento de Confiabilidade (ex. será
consideravelmente mais fácil aumentar a Confiabilidade de 90%
para 91% do que aumentar de 99,99% para 99,999%, mesmo
sendo o aumento muito maior na primeira situação).
• A função deveria ser assintótica para alcançar a máxima
Confiabilidade.
Uma Candidata à Função de Custo
• A seguinte função está de acordo com os requisitos

apresentados anteriormente, e está definida como a equação
default de custo no BlockSim.
𝑹𝑹𝒊𝒊 −𝑹𝑹𝒎𝒎𝒎𝒎𝒎𝒎,𝒊𝒊
(𝟏𝟏−𝒇𝒇)
𝑪𝑪𝒊𝒊 𝑹𝑹𝒊𝒊 = 𝒆𝒆 𝑹𝑹𝒎𝒎𝒎𝒎𝒎𝒎,𝒊𝒊 −𝑹𝑹𝒊𝒊
Onde:
𝐶𝐶𝑖𝑖(𝑅𝑅𝑅𝑅) é a função penalização (custo) em função da
Confiabilidade do componente.
𝑓𝑓 é a exequibilidade (feasibility).
𝑅𝑅𝑚𝑚𝑚𝑚𝑚𝑚, 𝑖𝑖 é a Confiabilidade atual.
𝑅𝑅𝑚𝑚𝑚𝑚𝑚𝑚, 𝑖𝑖 é a Confiabilidade máxima possível de ser
alcançada.
Funções alternativas podem ser definidas.

Gráfico da Função de Custo
Penalty Function vs Component Reliability

(for different feasibility values)
10
8
Penalty Function
7
6 0.1
0.5
5 0.9
4
Max Achievable
3 Reliability
1
0.7 0.75 0.8 0.85 0.9 0.95
0.99
Component Reliability
Otimização da Confiabilidade
• Alocar a Confiabilidade de tal maneira que a Confiabilidade do

sistema seja alcançada ao mesmo tempo em que a dificuldade
(custo) e os requisitos de Confiabilidade de cada componente
sejam mantidos.
• Satisfaça a igualdade:
Rs (t ) = R1 (t ) ⋅ R2 (t ) ⋅ R3 (t )
• Enquanto minimizando:
Cs ( Ri ) = C1 ( R1 ) + C2 ( R2 ) + C3 ( R3 )
Observe que este exemplo se aplica a três itens em série. Para resolvê-lo,
soluções numéricas por computador serão utilizadas.
Exemplo
• Considere o seguinte sistema:

• 0 - Weibull (β=1,5, η=2000)
• 1 - Weibull (β= 1,5, η= 1000)
• 2 - Weibull (β= 2, η= 2000)
• 3 - Weibull (β= 3, η= 3000)
• 4 - Weibull (β= 1, η= 1000)
Exemplo
• Considere o seguinte componentes

escolhidos para a otimização: R i − R min,i
• 0 f=0.5, Rmin=0.5, Rmax=1 (1− f )
R max,i − R i
• 1 f=0.6, Rmin=0.5, Rmax=1 C i (R i ) = e
• 4 f=0.3, Rmin=0.5, Rmax=1
Exemplo
• Confiabilidade Atual R(t=100)=0.8669

• Para alcançar R(t=100)=0,90 enquanto minizando a função de custo
Novo
R(100)
Number of
Meta
Equivalent
Parallel Units
Para alcançar o
mesmo resultado.
R
Atual(10
0)
Utilizando uma Definição Genérica de
Exequibilidade (Feasibility)
R i − R min,i
(1− f )
R max,i − R i
C i (R i ) = e
1-f
Rmin é a confiabilidade atual

Rmax é a confiabilidade máxima alcançada
Observação
Utilizando a Alocação Otimizada da Confiabilidade para Definir as
Especificações
• Após criar o projeto inicial:

• Utilize a quantificação da importância da Confiabilidade para
determinar quais itens devemos focar na melhoria da Confiabilidade.
• Utilize técnicas de alocação para se trabalhar na Confiabilidade dos
componentes de maneira a encontrar ou estabelecer a Confiabilidade
meta (especificação) do sistema.
Exemplo de Especificações
System Diagram
Assembly A
Assembly B
Assembly C
Assembly D
Component Life Distribution
Subsystem A Comp. 0 Weibull β= 2 η= 5,000 γ= 0
Comp. 1 : Weibull β= 2 η= 4,500 γ= 0
Comp. 3 : Weibull β= 2 η= 8,965 γ= 0
Comp. 4 : Weibull β= 1 η= 8,000 γ= 0
Comp. 5 : Lognormal µ= 10 σ= 1
Comp. 6 : Weibull β= 3 η= 10,000 γ= 0
Comp. 7 : Normal µ= 10,000 σ= 200
Comp. 8 : Normal µ= 8,000 σ= 100
Subsystem B Comp. 9 : Weibull β= 2 η= 7,000 γ= 0
Resumo
• Alocações otimizadas da Confiabilidade podem ser utilizadas

para alocar a Confiabilidade a todos os níveis.
• Este método pode também ser utilizado no estágio inicial de
um projeto par se definir as especificações de Confiabilidade
de um subsistemas/componentes.
Exercício Prático

Exercício Prático
Revisitando o Sistema de supressão de fogo
• Em uma nova política para combate a incêndio foi

determinado que todos os sistemas de supressão de fogo tem
que ter pelo menos 95% de confiabilidade depois de 10 anos
de operação.
• A análise deve ser conduzida para determinar a meta de
confiabilidade necessária após 10 anos de uso e também
atender esta nova política.
• Como alternativa, caso a nova confiabilidade não possa ser
alcançada, é necessário determinar o número de unidades
paralelas equivalentes de cada componente do sistema.
Hands On Example
Fire Suppression System Revisited (cont’d)
• A viabilidade de aumentar a confiabilidade do controlador é

considerada um “pouco” difícil (7), extremamente difícil (9)
para o sprinkler e relativamente fácil (3) para os sensores.
Respostas
• Com base nas definições de custo, o controlador já tem a

confiabilidade requerida, Ao passo que o aspersor e os
sensores precisam ser melhorados.
• Se a confiabilidade não puder ser aumentada para atender às
novas exigências, então 2 controladores de corrente e 10
sensores de corrente precisam serem utilizados.
Simulação e Análise de
Sistemas Reparáveis
Simulação
• Simulações podem ser utilizadas no lugar de uma

solução matemática analítica nos casos onde elas são
impraticáveis analiticamente.
• Considerações:
• Consumo de tempo.
• O resultado depende do número de simulações.
• Falta da repetibilidade.
Se uma solução”exata” pode ser obtida sem recorrer à simulações, então

a solução “exata” deverá ser preferida, já que a simulação tenta se
aproximar à solução exata!
Ilustrando a Simulação
• Nós podemos computar a probabilidade exata de se obter

um seis em um arremesso de dado (1/6 = 0,1667).
• Se nós não pudéssemos computar, então nós deveríamos
tentar a simulação (ex. simule o arremesso de dados e conte
os resultados).
• A mesma idéia pode ser expandida para a Confiabilidade.
Run Dice
Example
Gerando Valores de t Aleatórios para uma
Distribuição Weibull de 2 Parâmetros
• R(t) e t(R) para uma distribuição Weibull são:

β
 t 
−
η 

R (t ) = e  
1
t ( R ) = η [− ln (R )]β
• Para gerar valores aleatórios de tempo para uma distribuição

Weibull, dado um η e um β, primeiramente iremos obter um
número aleatório uniforme entre 0 e 1, UR[0,1], então substituí-lo
por por R, como mostrado a seguir:
1
t (U R [0,1]) = η [− ln (U R [0,1])]β
Random Number Generator (RNG) no BlockSim
• Internamente o BlockSim utiliza algoritmos baseados no gerador

aleatório de números L'Ecuyer's random number generator com
um post Bays-Durham shuffle.
• O período de RNG's será aproximadamente 1018, o qual é mais do
que suficiente já que este número é bem maior do que número
máximo de simulações permitida pelo BlockSim.
• O RNG é aprovado por todos os testes estatísticos, dentro dos
limites da precisão da maquina, e para um número de simulações
menor que 1018 .
• Se nenhuma “semente” de simulação é determinada, o algoritmo
usa o relógio da maquina para inicializar o RNG.
Simulação no BlockSim
Analítico
Simulação
Altere entre
Analítico e
Simulação
Introdução para Análise
de Sistemas Reparáveis
Introdução para Análise de
Sistemas Reparáveis:
Fundamentos de Mantenabilidade e Disponibilidade

Análise de Sistemas Reparáveis
• “Sistema Reparáveis” são sistemas que possuem componentes

que podem ser reparados/substituídos de maneira à restaurar
o sistema.
• No caso de sistemas reparáveis, outras análises, além da
Confiabilidade, serão necessárias.
• A Confiabilidade nos fornece a probabilidade de sucesso do sistema
inteiro para um dado ponto de interesse, sem levar em
consideração a questão: “O que acontece se o componente falha e
nós o consertamos?”
• Outras análises aplicadas à sistemas reparáveis:
• Mantenabilidade
• Disponibilidade
Olhando para Um Único Componente
Distribuição
de Falha
Distribuição
de Reparo
Teoria da Renovação
• Para sistemas reparáveis, o tempo de operação não é contínuo. Em outras

palavras, o ciclo de vida do sistema pode ser descrito por uma seqüência de
estados “up” e “down”.
• O sistema opera até a falha, então é reparado e retorna ao estágio original de
operação.
• O sistema irá falhar novamente após um determinado tempo de operação
aleatório, e será reparado novamente, e este processo de falha e reparo irá se
repetir.
• Isto é denominado como processo de renovação e é definido como uma seqüência
de variáveis aleatórias independentes e não negativas.
• Neste caso, as variáveis aleatórias são os tempos-até-falha e os tempos-de-reparo.
• Cada vez que um item falhar e for reparado, é definido que uma renovação do
mesmo ocorreu.
• Este processo de renovação é conhecido como processo de renovação alternado, já
que o componente alterna entre os estados de funcionamento e de reparo.
Teoria da Renovação
• Um processo de renovação de um
sistema é determinado pelo
processo de renovação de seus
componentes.
1
nt
• Por exemplo, considere um sistema com
ne
po
três componentes em série.
om
time
C
• Cada componente possui uma
distribuição de vida e uma distribuição de
2
reparo.
nt
ne
po
• Sendo que os componentes estão em
om
time
série, quando um componente falhar, o
C
sistema todo irá falhar.
t3
en
• O sistema estará então parado (down)
n
po
enquanto o componente estiver em
om
reparo. time
m
time
e
st
Sy
System Downtime
Definindo Mantenabilidade
• A probabilidade de realizar com sucesso uma ação de

reparo/restaurado em um dado tempo.
• Exemplo: Existe uma probabilidade de 90% de que o sistema seja
reparado/restaurado em 1 hora.
• Mantenabilidade é obtida através dos dados de tempo-de-reparo.
• Tempo-de-reparo pode incluir:
• Identificação da falha.
• Substituição do componente/subsistema.
• Atraso logístico.
• Outros.
As definições/matemática de mantenabilidade são similares as de
Confiabilidade, mas neste caso estamos analisando eventos de tempos-
de-reparo em vez de tempos-até-falha (variável aleatória).
Definindo Termos de Manutenção
• Manutenção Corretiva
• Componentes/subsistemas são reparados/substituídos quando falham.
• Manutenção Preventiva
• Componentes/subsistemas são reparados/substituídos antes que falhem.
• Preditiva: uma falha em potencial pode ser detectada, e então uma MP
pode ser realizada.
• Inspeção
• Componentes/subsistemas são inspecionados e serão
reparados/substituídos se uma falha for encontrada. Uma manutenção
parcial pode ser realizada mesmo que o componente/subsistema não
tenha falhado.
Distribuição de Indisponibilidade
• O tempo-de-reparo (substituição ou inspeção) é

tratada como uma variável aleatória.
• O tempo para realizar uma ação de manutenção (ex.
corretiva, preventiva ou inspeção) não é constante.
• Uma distribuição de reparo será encontrada através
dos dados de tempos-de-reparo (substituição ou
inspeção) de maneira similar a utilizada para dados de
tempos-até-falha.
Exemplo de Dados:
Dados de Tempo até Reparo: 4.5, 4.9, 4, 3.8 hrs.
Exemplo
Distribuição Exponencial de Reparo
• A equação da mantenabilidade é dada por:
− µ ⋅t
M (t ) = 1 − e
onde
µ = taxa de reparo.
e
1
= MTTR (tempo médio de reparo)
µ
Definindo Disponibilidade, A(t)
• Critério de Performance para sistemas reparáveis.

• É a probabilidade do sistema estar operando apropriadamente
quando requisitado para uso.
• É dependente tanto da Confiabilidade quanto da
Mantenabilidade do sistema.
• Existem diferentes classificações para o critério disponibilidade.
Exemplos Simples de Disponibilidade
• Exemplo 1
• Uma lâmpada possui uma disponibilidade de 99,9%.
• Isto significa que 1 entre 1.000 vezes que alguém ligar a lâmpada,
ela não irá funcionar.
• Observe que esta medida não fornece informações sobre o número de
vezes em que a lâmpada estava em reparo ou substituição.
• Exemplo 2
1000 900 50 40
4 5 1
• Tempo Disponível (Uptime) = 1990 h
• Tempo Indisponível (Downtime) = 10 h
• Disponibilidade (Availability) = 99,5%
Efeitos da Confiabilidade e Mantenabilidade na
Disponibilidade
Confiabilidade Mantenabilidade Disponibilidade

Constante Decresce Decresce
Constante Aumenta Aumenta
Aumenta Constante Aumenta
Decresce Constante Decresce
Um aumento da mantenabilidade implica em um decréscimo do

tempo para realizar uma ação de manutenção.
Classificações de Disponibilidade
• Disponibilidade Instantânea (ou Pontual)

• Disponibilidade Média
• Disponibilidade de Estado Constante
• Disponibilidade Inerente
• Disponibilidade Alcançada
• Disponibilidade Operacional
Existem diversas definições para mensurar a disponibilidade,

entretanto o mais importante é conhecer o método de cálculo que
está por trás da definição.
Instantânea (ou Pontual) Disponibilidade, A(T=t)
• A probabilidade de que o sistema (ou componente) esteja

operacional em um dado tempo, t.
• O sistema estará operacional no tempo t se:
• Não estiver em falha no tempo t.
• Se em falha, ações corretivas foram realizadas e completadas.
• Não tiver falhado desde a última ação corretiva realizada com sucesso.
• Matematicamente, isto poderia ser a soma da:
• Confiabilidade até o tempo (t).
• Probabilidade de que ações corretivas foram completadas e que não houve
falha desde então.
u
A(t ) = R(t ) + ∫ R(t − u )m(u )du
0
Para sistemas complexos, isto pode ser obtido utilizando métodos de

simulação.
Tempo Disponível Médio Disponibilidade
A(T )
• Proporção do tempo de uma missão, (0, T), em que o sistema
estava disponível para uso.
• A disponibilidade média do sistema será calculada sobre o
intervalo de tempo de zero até T.
1 T
A(T ) =
T ∫ 0
A(t ) dt
Pode também ser chamada de “Disponibilidade Média.”

Disponibilidade do Regime Permanente,
𝑨𝑨(∞)
• A disponibilidade do sistema quando o tempo tende ao

infinito.
𝑨𝑨 ∞ = lim 𝑨𝑨(𝒕𝒕)
𝒕𝒕→∞
𝑨𝑨(𝒕𝒕)
𝒕𝒕
Pela abordagem de infinito e após repetidas ações

de reparo, a disponibilidade do sistema irá se
aproximar a um valor único.
Disponibilidade Inerente, AI
• A disponibilidade inerente é obtida quando consideramos

somente os tempos de reparos corretivos no sistema.
MTTF
AI =
MTTF + MTTR
Onde:
MTTF é o tempo médio até a falha.
MTTR é o tempo médio de reparo.
Disponibilidade Alcançada, AA
• A disponibilidade alcançada é obtida quando consideramos as

ações corretivas e preventivas realizadas no sistema.
MTBM
AA =
MTBM + M
• Onde:
• MTBM é o tempo médio entre manutenções, tanto corretivas
quanto preventivas.
• M é a duração média das paradas, tanto para as manutenções
corretivas quanto para as preventivas.
Disponibilidade Operacional, Ao
• A disponibilidade operacional incluem todas as origens de

parada, tais como, administrativas, atrasos logísticos, etc.
• A disponibilidade operacional é a disponibilidade sentida pelo cliente.
• Em muitos casos não pode ser controlada pelo produtor.
Uptime
Ao =
Total Operating Cycle Time
1000 900 50 40 Total OCT = 2000 h

Uptime = 1990 h
4 5 1
Disponibilidade Operacional
(Ao) = 99,5%
Sistema de Falhas e Componentes
• Não opere através das falhas.

• Os componentes não “consomem” idade (e portanto não podem
falhar) quando o sistema estiver em falha.
• Isto requer um “relógio” de idade independente para os
componentes, já que as idades dos componentes serão
diferentes da idade do sistema.
• Opere através das falhas.
• Os componentes “consomem” idade (e podem falhar) sempre
que o sistema estiver em falha.
• Ambas as opções podem ser utilizadas para cada componente
do diagrama.
Exemplo de Análise
• A partir da introdução de algumas terminologias básicas para

sistemas reparáveis, iremos agora examinar o passos envolvidos
na análise de sistemas reparáveis através da simulação.
• Para entender melhor como as falhas dos componentes e seus
reparos afetam o sistema e visualizar os passos envolvidos na
análise, nós iremos começar com um simples exemplo
determinístico, composto por dois componentes, A e B em série.
• Componente A falha sempre à 100 h e o componente B falha sempre a
cada 120 horas.
• Ambos requerem 10 horas para serem reparados.
• Além disso, assuma que quando o sistema falha, os componentes
sobreviventes param de operar (ou seja não está envelhecendo).
Visão Geral do Sistema
• O comportamento do sistema durante o tempo de operação de 0 a 300 horas poderia ser

representado como:
140 280
B
130 270
110 230
A
100 220
System
0.000 60.000 120.000 180.000 240.000 300.00
Time, (t)
Discussão
• Especificamente o componente A irá falhar a 100 hs, causando falha do

sistema.
• Após 10 horas, o componente A irá ser restaurado e o sistema voltará a
operar. O próximo evento deverá ser a falha do componente B. Nós
sabemos que o componente B falha a cada 120 horas (ou após alcançar a
idade de 120 horas).
• Agora, e sendo que o componente não aumenta sua idade enquanto o
sistema está em falha, o componente B teria alcançado 120 horas quando o
relógio alcançasse 130 horas. Portanto, o componente B irá falhar com 130
horas e será reparo à 140 horas e assim por diante.
• Neste cenário, o sistema estará em falha por um tempo acumulado de 40
horas, este tempo indisponível foi devido a quatro eventos (dois de A e dois
de B).
Discussão
• A disponibilidade total do sistema (disponibilidade média)

será 260/300=0,86667.
• A disponibilidade pontual será a disponibilidade específica a
dado tempo específico t.
• Neste caso determinístico, a disponibilidade pontual será
sempre igual a 1 se o sistema estiver operando à aquele
dado tempo e igual a zero se o sistema estiver em falha à
aquele dado tempo.
Operando Através das Falhas
• O exemplo anterior utilizou a suposição de que os

componentes não acumulam idade quando sistema está em
falha.
• Esta suposição será aplicada a maioria dos sistemas.
Entretanto, sob determinada circunstâncias especiais um
item pode acumular idade quando o sistema está em falha.
Nestes casos, o perfil de operação será diferente do que o
apresentado no exemplo anterior.
• A próxima figura ilustra o caso quando os componentes
continuam operando independentemente do estado do
sistema.
TÍTULO
120 250
B
100 210
A
System
0.000 60.000 120.000 180.000 240.000 300.00
Time, (t)
Discussão
• Em uma situação probabilística, as falhas e reparos não

acontecem a intervalos fixos, mas ocorrem baseadas em
distribuições probabilísticas.
Block Up/Down
System
0.000 60.000 120.000 180.000 240.000 300.00
Time, (t)
Discussão
• A simulação de eventos discretos são baseados na observação dos eventos do sistema,

bastante similar a maneira que observamos os eventos no exemplo determinístico, com a
exceção que ao invés de utilizarmos tempos discretos, utilizamos tempos aleatórios
retirados da distribuição que está sendo utilizada.
B B
A A
System System
0.000 60.000 120.000 180.000 240.000 300.00 0.000 60.000 120.000 180.000 240.000 300.00
Time, (t) Time, (t)
• Se repetirmos este procedimento X vezes poderíamos alcançar o resultado de interesse

para o sistema e seus componentes.
Paralelo Simples (Determinístico)
• Considere o seguinte sistema:
• Onde A falha sempre a cada 100, B a cada 120, C a cada 140 e D a

cada 160 unidades de tempo. Cada um deles necessita de 10
unidades de tempo para ser restaurado.
• Além disso, assuma que os componentes não acumulam idade
quando o sistema estiver em falha.
• Um visão do sistema é apresentada no próximo slide.
TÍTULO
Block Up/Down
170
D
150
C
130 280
B
100 220
A
100 170 220

System
0.000 60.000 120.000 180.000 240.000 300.00
Time, (t)
Resumo dos Eventos
• Em 100 A falha e será reparado até 110. O sistema está

em falha.
• Em 130, B falha e será reparado até 140. O sistema
continua operando.
• Em 150 C falha e será reparado até 160. O sistema
continua operando.
• Em 170 D falha e será reparado até 180. O sistema está
em falha.
• Em 220 A falha e será reparado até 230. O sistema está
em falha.
• Em 280, B falha e será reparado até 290. O sistema
continua operando.
• Fim à 300.
Exemplo
A B C
Componente A
Distribuição de Falha: Weibull, β=1,5, η=1,000
Distribuição de Reparo: Weibull, β=1,5, η=100
Componente B
Distribuição de Falha: Exponencial, MTTF=10.000
Distribuição de Reparo: Exponencial, MTTR=10
Componente C
Distribuição de Falha: Weibull, β=2, η=5.000
Distribuição de Reparo: Normal, µ=8, σ=0,00001
Assuma o reparo imediato quando a falha ocorre.
Configuração no BlockSim
Simulação no BlockSim
Resultados da Simulação
Alguns Resultados Gerais
• Sistema Disponível
• O tempo médio em que o sistema estará em operação, pode ser obtido pela soma
dos tempos em operação de cada simulação e divido pelo número de simulações.
• Sistema Indisponível
• O tempo médio em que o sistema estará em falha, pode ser obtido pela soma dos
tempos em falha de cada simulação e divido pelo número de simulações.
• Disponibilidade Média
• O Tempo Disponível do Sistema dividido pelo total de simulações.
• Disponibilidade Pontual
• A probabilidade do sistema estar disponível a um dado tempo T. No exemplo, para
se obter o valor para T=300, durante a simulação um contador especial deverá ser
utilizado. Este contador será incrementado em 1 a cada vez que o sistema estiver
disponível a 300 horas. Portanto, a disponibilidade pontual à 300 será o número de
vezes que o sistema esteve disponível dividido pelo número de simulações.
Alguns Resultados Gerais
• Confiabilidade Pontual
• É a probabilidade de que o sistema não falhe no tempo T. Este cálculo
será similar ao da disponibilidade pontual exceto pelo fato de que o
sistema não deve possuir nenhuma falha.
• MTTFF
• Tempo Médio Até a Primeira Falha (Mean-time-to-first-failure), ou o
tempo médio para a primeira falha do sistema.
• Outros Resultados de Interesse
• Serão discutidos nas próximas sessões.
Resultados por Componentes
Indicadores Importantes
• RS FCI (Índice da ReliaSoft para mensurar a Criticidade da

Falha)
• RS DECI (Índice da ReliaSoft para mensurar a Criticidade dos

Eventos que provocam Indisponibilidade)
• RS DTCI (ReliaSoft’s Downtime Criticality Index)

Introduzindo o Fator de Restauração
• Nas discussões anteriores foi assumido que o reparo do

componente o deixou tão bom como novo. Isto eventualmente
ocorre quando trocamos o componente em falha por outro
novo. Nos casos onde queremos um modelo imperfeito de
reparo, o conceito do fator de restauração pode ser utilizado.
• O melhor caminho para indicar que o componente não é tão
bom como novo é dar ao componente alguma idade. Como
exemplo de pneus de carro que não são tão bons como novos
pois já existe um desgaste, ou seja, ele tem uma
quilometragem acumulada.
Introduzindo o Fator de Restauração
• Para descrever melhor a idade existente de um componente, o

fator de restauração será utilizado.
• O fator de restauração será utilizado para determinar a idade do
componente após um reparo ou qualquer outra ação de
manutenção (tal como as ações preventivas e de inspeção).
0 ≤ FR ≤ 1
• Deve ser salientado que ao lidar com taxas de falha constantes

(isto é, com uma distribuição tal como o exponencial), o Fator de
Restauração não possui qualquer efeito.
Fator de Restauração
• O FR poderá assumir valores

entre 0 e 1. RF=1
• Um fator de restauração de 1 (100%)
implica que o componente será tão
bom quanto novo após o reparo, cujo
efeito implicará que a idade inicial do
componente inicia-se em 0.
• Um fator de restauração de 0 implica 0<RF<1
que o componente será o mesmo que
antes do reparo, cujo efeito implicará
que a idade inicial do componente será
a mesma que ele possuía na falha.
• Um fator de restauração de 0,25 (25%)
implica que a idade inicial do RF=0
componente será igual a 75% da idade
que ele possuía na falha.
Tipos de Fator de Restauração: Tipo I
• O FR Tipo I baseia-se no modelo Kijima I e assume que os

reparos só podem corrigir desgastes e danos ocorridos durante
o último período de operação.
• Assim, o atual nth reparo só pode remover os danos ocorridos
durante o tempo entre a falha atual e a anterior (n-1)th.
vn = vn−1 + (1 − FR)xn
vn: tempo de vida do sistema no tempo tn

Exemplo de Fator de Restauração Tipo I
Um exemplo Determinístico:
• FR de 50%.
• Um motor de automóvel falha após 6 anos de operação.
• O motor é recondicionado. O recondicionamento tem o efeito de
rejuvenescer o motor que terá uma condição equivalente a 3 anos
de idade.
• O motor irá falhar novamente após 3 anos, mas o
recondicionamento só afetará a idade (de 3 anos) após o primeiro
recondicionamento. Assim, o motor terá uma idade de 4,5 anos após
o segundo recondicionamento (3+[(1 – 0,5)x3] = 4,5).
• Após o segundo recondicionamento o motor falhará novamente
após um período de 1,5 anos e o terceiro recondicionamento se fará
necessário.
• A idade do motor após o terceiro o recondicionamento será de 5
anos e 3 meses (4,5 + [(1 − 0,5)x1,5] = 5,25).
Tipos de Fator de Restauração: Tipo II
• O Fator de Restauração tipo II, baseia-se no modelo Kijima II,

assume que o reparo corrige todas as falhas e desgastes
acumulados até o tempo atual.
• Como resultado, o atual reparo nth não só elimina os danos
ocorridos durante o tempo entre a falha atual nth e anterior
(n-1)th, mas também pode fixar o desgaste acumulado
ocorrido durante o tempo da primeira falha e a falha
anterior atual (n-1)th.
vn = (1 − FR)(vn−1 + xn)
Exemplo de Fator de Restauração Tipo II
Um exemplo determinístico:
FR de 50%.
Um motor de automóvel falha após 6 anos de
operação.
Este motor é recondicionado. O recondicionamento
tem o efeito de rejuvenescimento para o motor que
terá uma condição equivalente a 3 anos de idade.
O motor falhará novamente após 3 anos (quando
atingir de novo uma idade de 6 anos) e um outro
recondicionamento será necessário. Este
recondicionamento rejuvenescerá o motor em 50%,
tornando-o desta forma o motor terá novamente 3
anos de idade.
Introdução aos
Princípios da
Manutenção Preventiva
Little of all we value here
Wakes on the morn of its hundredth year
Without both feeling and looking queer.
In fact, there's nothing that keeps its youth,
So far as I know, but a tree and truth.
(This is a moral that runs at large;
Take it. -- You're welcome. -- No extra charge.)

Quando a Manutenção Preventiva
Faz Sentido?
• Condição #1:
• O sistema possui uma taxa de falha crescente. Em outras palavras, a taxa de falha
do sistema cresce com o tempo, portanto as falhas ocorrem por desgaste / fadiga
(velhice na curva da banheira).
• Condição #2
• O custo para execução da manutenção preventiva é menor do que o custo da ação
corretiva.
• Ambas as condições precisam ser respeitadas!
Manutenções preventivas de componentes, onde a distribuição

exponencial for assumida (o que implica em uma taxa de falha
constante), não fazem sentido!
Da mesma maneira, tente obter o intervalo ótimo de MP para um

componente que conhecemos somente o MTTF !
The Fallacy of “Constant Failure Rate” and
“Preventive Replacement”
Assume a component with an 𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀 = 100 hours, or

λ = 0.01, and preventive replacement every 50 hours.
t
• The reliability of the component from 0 to 60 hours would be:
• With PM, the component was replaced at 50 hours so this is based on the reliability of the new
component for 10 hours, 𝑅𝑅(𝑡𝑡 = 10) = 90.48%, times the reliability of the previous component,
𝑅𝑅(𝑡𝑡 = 50) = 60.65%. The result is 54.88%.
• Without PM, the reliability would be the reliability of the same component operating to 60 hours,
𝑅𝑅(60) = 54.88%.
• The reliability of the component from 50 to 60 hours would be:
• With PM, the component was replaced at 50 hours so this is solely based on the reliability of the new
component, 𝑅𝑅(𝑡𝑡 = 10) = 90.48%.
• Without PM, the reliability would be the conditional reliability of the same component operating to
60 hours, having already survived to 50 hours, or 𝑅𝑅𝐶𝐶 (𝑇𝑇 = 60|50) = 𝑅𝑅(60)/𝑅𝑅(50) = 90.48%.
You get no benefit from the PM.

Quantificando o Tempo Ótimo para a Manutenção
Preventiva para um Único Componente
Cost per unit Time vs. Time
0.02
0.018
0.016
0.014
Cost per unit Time
0.012
0.01
0.008
Minimum Cost of
Replacement
0.006
Preventive
0.004 Replacement
Corrective
Costs
0.002 Replacement
Costs
0
0 100 200 300 400 500 600 700 800 900 1000
Time, t
Idade Ótima para a Troca
• Sob uma política de Troca Ótima, os itens são trocados se um evento

de falha ocorrer ou sob um determinado tempo t de operação, o que
ocorrer primeiro.
• Para determinar o tempo ótimo, uma função de custo poderá ser
utilizada ou:
Total Expected Replacement cost per Cycle
CPUT (t ) =
Expected cycle length
C p ⋅ R (t ) + CU ⋅ (1 − R (t ))
= t
0∫ R(s)ds
Onde:
R(t) = Confiabilidade a um dado tempo t.
CP = Custo de trocas planejadas.
CU = Custo de trocas não planejadas.
Ótimo t
• O intervalo de tempo, t, ótimo de troca será o tempo que

minimizará o custo por unidade de tempo (CPUT), o qual será
encontrado, pela resolução por t, de tal forma que:
∂[CPUT (t )]
= 0.
∂t
Reescrevendo a Função de Custo para uma
Função de Indisponibilidade
• Nós podemos utilizar o mesmo conceito e tentar minimizar o

tempo indisponível em vez do custo, ou:
Total Expected Replacement Downtime per Cycle

DPUT (t ) =
Expected cycle length
T p ⋅ R (t ) + TU ⋅ (1 − R (t ))
=
(t + T p ) R (t ) + ∫ R ( s )ds + TU  (1 − R (t ))
 t
 0 
Onde:
R(t) = Confiabilidade a um dado tempo t.
TP = Tempo para as trocas planejadas.
TU = Tempo para as trocas não planejadas.
Minimizando os custos e generalizando a função para minimizar o tempo

indisponível, já que o tempo indisponível pode ser expresso em termos de
custos.
Exemplo
• A distribuição de falha de
um componente é descrita
pela distribuição Weibull Optimum Replacement Policy
(b =2.5, h =1000)
com β=2,5 e η=1000 horas.
0.02
• O custo para uma troca 0.018 A idade ótima de

corretiva é de $5, enquanto 0.016 preventiva é
o custo para uma trova 0.014
493 horas.
Cost per Unit Time

preventiva é de $1. 0.012
• Estime o tempo ótimo de

0.01
0.008
troca de maneira a 0.006
minimizar os custos. 0.004
0.002
Minimum Cost
0
0 200 400 493 600 800 1000 1200
Replacement Time
Olhando para Cu/Cp
Replacement Interval vs. Cost Ratio

(Optimum Replacement, b=2.5, h=1000)
1000
900
Replacement Interval 800
700
600
500
400
300
200
100
0
0 2 4 6 8 10 12
Cost Ratio (Cu/Cp)
Exemplo
• Determinando a melhor quilometragem para a troca de óleo em

seu carro.
• Pela análise dos dados de vida obtidos de motores que operaram sem trocas de
óleo, resultou em uma distribuição Weibull com β = 6 e η = 19.300 km.
• Assumindo que o custo da troca de óleo é de $20 e que o custo da troca do
motor é de $3,000, a quilometragem ótima para se realizar a troca de óleo pode
ser determinada como:
A quilometragem ótima,
para este cenário será
de 4.000 quilômetros
(arredondando).
Exemplo 2
Diversos Blocos
• Não Somente Troca de Óleo:

Eta Troca
Item Distribuição Beta Corretiva
(milhas) Preventiva
Óleo e
Weibull 6 12,000 $20 $3,000
Filtro
Bomba de
Weibull 2 60,000 $800 $2,000
Água
Correia Weibull 2.5 75,000 $800 $3,000
Filtro de
Weibull 3 18,000 $15 $1,500
Agua
Velas Weibull 1.5 30,000 $80 $200
Filtro Comb Weibull 3 30,000 $250 $500
Example 2
Diversos Blocos
• Os tempos ótimos de substituição foram agrupados dentro de

3 periodicidades para minimizar
Opções de Simulação
Avançada: Utilizando
Potíticas, Estoques e
Recursos
Recursos - Equipes de Manutenção
• De maneira a tornar as análises mais realista (precisa), deveríamos considerar

outros tipos de atrasos, bem como estudar o efeito das limitações de recursos.
• Nos exemplos anteriores, nós utilizamos uma distribuição de reparo para identificar
quanto tempo é dispensado para restaurar um componente. Se neste tempo foram
incluídos tempos arbitrários, tais como, o tempo que a equipe de manutenção
levou para chegar ao local do reparo, se existia peça de reposição no estoque, etc.
Não poderemos identificar, de maneira individualizada, qual destes eventos
devemos atuar com ações de melhoria.
• Como exemplo, considere a situação onde dois componentes conectados em
paralelo falharam ao mesmo tempo, e somente um único homem da manutenção
está disponível para efetuar o reparo. Esta pessoa não poderá executar o reparo em
ambos os componentes simultaneamente, portanto uma demora adicional será
encontrada, a qual deverá ser incluída na modelagem. Uma maneira de analisar
esta situação é especificar que a equipe de manutenção pode realizar um único
evento de cada vez.
Recursos de Equipe (Crew Policy)
• As parametrizações de cada bloco incluem, para cada ação, a

definição das equipes de manutenção e suas respectivas
limitações.
Visão Geral da Política de Equipe de Manutenção
(Crew Policy)
• Para cada equipe de manutenção nomeada, uma política

necessita ser definida. Esta política irá determinar as
propriedades básicas para esta equipe, tais como:
• Atrasos logísticos. Quanto tempo a equipe demora para
chegar ao local de reparo?
• Quantas tarefas de reparo simultâneo a equipe pode
realizar?
• Quanto custa a equipe por hora de trabalho (reparo)?
• Existe algum outro custo adicional por incidente?
Especificando a Crew Policy
• O atraso logístico da equipe será adicionado para cada reparo.

• O atraso logístico estará sempre presente, não importando de onde
surgiu o chamado (de um mesmo equipamento ou de um outro).
• Para cada simulação realizada, cada tempo de atraso logístico será
constante (obtido da distribuição) através de uma simples
simulação, independente da ação (corretiva, preventiva, inspeção).
• Uma equipe pode executar infinitos reparos simultaneamente
ou um número limitado.
• Se um número limitado de tarefas for definido para a equipe, então
a equipe não poderá atender chamados adicionais a este até que
alguma tarefa termine.
Especificando a Crew Policy
• Se a equipe não estiver disponível para responder a um chamado

de manutenção o componente não será reparado até que a
equipe esteja disponível.
• A equipe mantém os chamados rejeitados em fila, após o termino
de um reparo irá atender o primeiro reparo rejeitado.
• Mais de uma equipe pode ser designada a atender um único
componente (bloco).
• Se nenhuma equipe for selecionada, será assumido que não
existem restrições e uma “equipe padrão” será utilizada.
• A “equipe padrão” pode realizar um número infinito de ações
simultâneas e não haverá atrasos ou custos envolvidos.
• Nenhuma informação será registrada para as “equipes padrões.”
Ilustrando o Uso da Equipe
• Para ilustrar o uso das equipes, assuma o seguinte

cenário:
• A - Falha: 100; Reparo: 10; Equipe A; Atraso=20, Uma Única Tarefa

• B - Falha: 120; Reparo: 20; Equipe A; Atraso=20, Uma Única Tarefa
• C - Falha: 140; Reparo: 20; Equipe A; Atraso=20, Uma Única Tarefa
• D - Falha: 160; Reparo: 10; Equipe A; Atraso=20, Uma Única Tarefa
TÍTULO
Block Up/Down
State
F:210 Operating Time

D
Waiting For
WO:20
Repair Opportuni
WC:20UR:10
Waiting For
Corrective Crew
Waiting For
Spare Parts
F:170
C Time Under Repa
WO:20
WC:20UR:20
F:150
B
WC:20UR:20
F:100
A
WC:20UR:10
System Pantelis Vassiliou

ReliaSoft
01/21/2003
02:55 PM
0.000 60.000 120.000 180.000 240.000 300.000
Time, (t)
Registro dos Eventos (Event Log)
• Em 100, A falha. A equipe demora 20 para chegar e 10 para reparar,

portanto A será reparado em 130. O sistema estará em falha durante este
tempo.
• Em150, B falha, já que ele acumulou uma idade de 120 durante este tempo.
E novamente é necessário esperar a equipe chegar e reparar em 190. O
sistema estará operando durante este tempo.
• Em 170, C falha. Neste momento, C requisita a equipe de reparo. Como só
existe uma equipe, e esta equipe só pode executar uma única tarefa ao
mesmo tempo, a equipe não poderá responder ao chamado de C, pois ela
está neste momento reparando B. Portanto C irá permanecer em falha até
que a equipe fique disponível. A equipe irá terminar o reparo em B em 190,
e então irá se encaminhar para C. Novamente o tempo referente a atraso
logístico será utilizado e então C será reparado em 230. O sistema continua
operando durante as falhas de B e C.
• Em 210, D falha. Novamente é necessário esperar a equipe chegar e
reparar, o que será em 260.
Múltiplas Equipes
• Um bloco pode utilizar diversas equipes. Neste caso, as

equipes serão selecionadas baseando-se na ordem em
que estão na lista de equipes, como mostrado na figura
abaixo.
Múltiplas Equipes
• Se a primeira equipe não estiver disponível, então a próxima

equipe será chamada, e assim por diante. Como exemplo,
considere o caso anterior, mas com as seguintes modificações:
• Equipe A e B são designadas para todos os blocos.
• Equipe A; Atraso=20, Uma Única Tarefa.
• Equipe B; Atraso=30, Uma Única Tarefa.
TÍTULO
Block Up/Down
Crew A
Crew B
Crew A
Crew A
System
0.000 60.000 120.000 180.000 240.000 300.00
Time, (t)
Múltiplas Equipes
• Neste caso para reparar C, a equipe B foi utilizada já que A

estava ocupada.
• Em todos os outros, A foi utilizada.
• É importante observar que uma vez designada uma equipe
para realizar um reparo, esta equipe irá completar a tarefa.
• Neste exemplo, se nós alterássemos o tempo de atraso da
equipe B para 100, o comportamento do sistema poderia
ficar como apresentado na próxima figura.
• Em outras palavras, sempre que a equipe A terminar seu reparo em
C mais rápido, ela estará disponível, entretanto a equipe B já foi
designada a executar o reparo porque a equipe A não estava
disponível no instante em que ela foi requisitada.
TÍTULO
Block Up/Down
Crew A
Crew B
Crew A
Crew A Crew A
System
0.000 60.000 120.000 180.000 240.000 300.00
Time, (t)
Resultados das Equipes
Spare Part Pools (Estoque)
• O BlockSim também permite que você especifique o estoque de peças de

reposição (spare part pools ou spare part depots).
• O spare part pools permite que você modele e gerencie o inventário do
estoque de peças de reposição.
• Cada componente pode ter um estoque de peça de reposição associado a
ele. Se nenhum spare part pool for definido, um “estoque padrão” de
peças infinitas será assumido.
• Para acelerar a simulação, nenhum detalhe será guardado durante a
simulação se o “estoque padrão” for utilizado.
• O spare part pool permite que você defina diversos aspectos do processo
de spare part, incluindo níveis de estoque, atrasos logísticos e opções de
reposição do estoque (restock options). Cada vez que um item falhar (ou
estiver sob uma ação de MP ou MC) um peça do estoque será utilizada.
• A requisição de uma peça do estoque será realizada

baseando-se no “first come, first served”.
• Cada vez que um bloco requisitar uma peça, o estoque irá
enviar a peça imediatamente, isso se existir uma peça em
estoque ou quando ela estiver disponível.
• Se existir um tempo logístico para o recebimento da peça, o
bloco que está requisitando-a irá obter após este tempo.
• Se um bloco falhar em 100, e seu reparo durar 10, e a requisição da
peça possuir um tempo logístico de 10, o bloco não estará
disponível até 120.
• Se uma peça não estiver disponível e uma peça de

emergência pode ser obtida, então o tempo total de espera
será a soma de ambos os tempos, o tempo logístico e o
tempo necessário para se obter a peça de emergência.
• Qualquer ação iniciada não pode ser cancelada.
• Se uma peça se torna disponível por uma outra ação de reposição, então
esta peça será utilizada. Entretanto, a ação de reposição original ainda será
realizada.
• Como exemplo, se um spare part pool iniciou uma reposição de
emergência que irá chegar em 100, e uma reposição programada
acontecer em 50, esta que se tornou disponível em 50 será utilizada.
Entretanto a ação de reposição de emergência não será cancelada e a
peça de emergência irá chegar e será adicionada ao estoque de reposição.
Chamados Simultâneos de Equipe e Peças
• Regras especiais são aplicadas quando um bloco possui os dois atrasos

logísticos, ou seja na aquisição da peça do estoque bem como para
aguardar a equipe de manutenção.
• O BlockSim despacha requisições de peças e equipes simultaneamente.
• O reparo não se inicia até que ambos, a equipe e a peça, cheguem,
como apresentado na figura a seguir.
Logistic Crew
Correcti ve
Logistic Part
• Se uma equipe chegar e necessitar esperar uma peça, então o tempo (e

o custo) será adicionado ao tempo de utilização da equipe.
Reposição de Estoque
Reposição de Estoque (Pool Restock)
• Reposições programadas são adicionadas instantaneamente ao

estoque no tempo programado.
• Reposições on-condition, são reposições que ocorrem quando
necessário.
• Por exemplo, se um estoque possui 3 itens, e 1 é despachado, no
instante em que a requisição de despacho for recebida (sem
considerar o tempo de atraso logístico), uma reposição on condition
será iniciada.
• A reposição de peças estará disponível após ter passado o tempo
requerido para chegada das mesmas.
Reposição de Emergência
(Emergency Restock)
• Ações de reposição de emergência são executadas

quando um item não está disponível.
Exemplo Utilizando Equipes e Estoque de
Reposição
• Considere o seguinte sistema determinístico:

Block Fail Rep. Duration Crew Pool
A
A 100 10 1
B
A
B 101 20 1
B
A
C 102 20 1
B
A
D 104 10 1
B
A
F 103 20 1
B
Crew Num. Sim. Tasks Delay Cost PI Cost PUT

A 1 10 10 1
B 1 15 20 2
Pool Init. Stock Restock On Condition On Condition Delay

1 1 1 every 150 When 0 Stock 1 60
TÍTULO
Block Up/Down
State
Operating Time
123 201 Time Under Repair
F
Waiting for Repair Opport
Crew A 180 Waiting for Spare Parts
Waiting for Crew
181
171 205
D
Crew B 195
182
122 180
C
Crew B 137 160
121 170
B
Crew A 131 150
100 120
A
Crew A 110
System
Reliasoft
3/29/2007
1:11:45 PM
0.000 60.000 120.000 180.000 240.000 300.000
Time, (t)
Registro de Evento (Event Log)
• A falha em 100 e a equipe A será despachada.

• Em 110, a equipe A chega e completa o reparo até 120.
• Este reparo utiliza a única peça que está em estoque e gera uma
reposição on-condition, porque o estoque esta em zero.
• B falha em 121.
• A equipe A está disponível e então é chamada.
• A equipe A chega em 131, mas não existem peças disponíveis para
executar o reparo.
• O estoque está esperando duas peças, a reposição programada está
definida para chegar em 150 e a reposição on-condition foi solicitada
por A em 100. Isto provoca a chegada para 160 (devido ao atraso).
• Em 150, a primeira peça chega e será utilizada por B. O reparo de B
será completado após 20 unidades de tempo, em 170.
• C falha em 122.
• A equipe A está trabalhando em B, portanto a equipe B e que será
enviada.
• A equipe B chega em 137 e fica aguardando peça.
• A primeira peça chega em 150, mas B foi o primeiro a solicita-la e
recebe-la, portanto C irá ter que esperar pela reposição on-condition
da peça que está definida para chegar em 160.
Em 160, a peça chega e C será reparado até 180.
• O estoque em 150 não tinha nenhuma peça e uma outra reposição on-
condition foi solicitada.
• A reposição on-condition foi solicitada em 150 e novamente em 160,
portanto as próximas reposições on-condition serão programadas para
chegar em 210 e 220.
• Observe que a próxima reposição programada será em 300.
• F falha em 123.
• Nenhuma equipe estará disponível até 170 quando a equipe
A se tornar disponível.
• A equipe A chega em 180 e tem que aguardar pela peça até
210.
• Em 230, o reparo será completado.
• D falha em 171 com nenhuma equipe disponível.
• A equipe B torna-se disponível em 180 e chega em 195.
• A próxima peça torna-se disponível em 220 e o reparo será
completado em 230.
Ações Corretivas
• Quando você deve executar uma ação corretiva?
Política de MC
Política Corretiva
• Upon Failure (na falha)

• A manutenção corretiva será requisitada no imediato momento em
que a falha ocorrer (upon failure).
• Upon Inspection (na inspeção)
• Utilizado quando você não sabe se um item está em falha
(normalmente aplicado quando uma redundância está presente).
• Definida na sessão Inspeção.
• A manutenção corretiva será iniciada na próxima inspeção
programada.
Manutenção Corretiva na Inspeção
• Se um bloco for encontrado em falha em uma inspeção, as

ações de inspeção e manutenção corretiva serão iniciadas
simultaneamente.
• Se a inspeção deixar um bloco indisponível, então o tempo em que
o item estará indisponível será tão longo quanto forem as durações
da inspeção e da manutenção corretiva.
• Se a inspeção não deixar o bloco indisponível, então o tempo em
que o bloco estará indisponível, devido a manutenção, será igual à
duração da manutenção corretiva.
• Se a manutenção preventiva ocorrer antes da próxima
inspeção:
• A manutenção preventiva (e não a manutenção corretiva) será
realizada para restaurar o bloco e o tempo indisponível, etc. irá
depender das propriedades da manutenção preventiva.
Tarefas de Manutenção Preventiva
• Quando você deve realizar uma ação de MP ?
Política de MP
Política de Preventiva
• Em um intervalo de tempo fixo

• A idade do item indica que a
manutenção preventiva será realizada a
um dado intervalo fixo de tempo
baseando-se na idade do item.
• A idade do sistema indica que a

manutenção preventiva será realizada a
um dado intervalo fixo de tempo
baseando-se na idade do sistema.
• Quando o Sistema Estiver Parado
• A manutenção preventiva será
realizada cada vez que o sistema
estiver em falha por qualquer
razão.
• Intervalos Dinâmicos podem ser escolhidos em vez dos

intervalos fixos para todas as manutenções agendadas
• Isso pode ser usado, por exemplo, para agendar manutenções
a serem executadas com maior frequência conforme o
envelhecimento do item
• Devido a uma Manutenção de um outro grupo de itens

(troca/reparo oportuna)
• A manutenção preventiva será realizada para um item quando a
manutenção de um outro item do mesmo grupo for realizada.
Grupos de Manutenção
Política Preventiva
• A parada do item faz o Sistema

parar. Deseja executar a tarefa
mesmo assim?
• Se Sim: A manutenção preventiva será
executada nos blocos associados com a
política independentemente da ação
fazer o sistema parar de operar.
• Se Não: A manutenção preventiva não
será realizada em blocos associados à
política, se a ação levar o sistema a
parar de operar.
Tarefas de Inspeção
• Quando você deve realizar inspeções?
Política de Inspeção
Inspeções podem conflitar com ações de MC!

Política de Inspeção
• Em certos Intervalos
• Baseado na idade do item.
• Baseado no calendário.
• Após certos eventos
• Sempre na parada do sistema.
• Baseado nos eventos de um grupo de
manutenção.
• No inicio da fase de manutenção.
Tarefas Baseadas na Condição
• A manutenção baseada na condição depende da capacidade

de detectar as falhas antes que elas aconteçam, para que uma
manutenção preventiva possa ser iniciada.
• As tarefas baseadas na condição consistem em:
• Tarefas de Inspeção que podem detectar a aproximação de uma
falha baseada no:
• Limiar de detecção da falha.
• Intervalo P-F.
• Tarefa preventiva, quando uma falha iminente é detectada.
Limiar de Detecção de Falha
• O limiar de detecção de falha é um número entre 0 e 1

que indica o percentual de vida de um item que deve
decorrer antes da detecção de uma falha.
Exemplo:
• Se o valor do Limiar de Detecção de Falha é de 0,8,
então a falha de uma componente pode ser detectada
apenas durante os últimos 20% de sua vida.
• Se uma inspeção ocorrer durante este período de
tempo, uma falha próxima será detectada e irá disparar
uma tarefa de manutenção preventiva.
Intervalo P-F
• O Intervalo P-F é a quantidade de tempo antes da falha de um

componente.
• O Intervalo P-F representa o período de alerta a partir de P
(quando uma falha potencial pode ser detectada) até F(quando a
falha ocorre).
• Exemplo:
Se o intervalo P-F é de 200hrs, então a aproximação da falha de
um componente pode somente ser detectada 200hrs antes da
falha de um componente.
Portanto, se um componente possui uma vida fixa de 1.000hrs,
então se uma inspeção ocorrer em, ou próximo a 800hrs, a
aproximação da falha é detectada e uma ação de manutenção
preventiva é disparada.
Propriedades das tarefas
“Sob Condição”(On Condition)
Exemplo
Pneus de Motocicleta
• O intervalo de uma inspeção adequada da profundidade do

sulco do pneu é essencial na prevenção de falhas dos pneus
durante a sua operação
• No entanto, é melhor inspecionar em intervalos periódicos ao
longo da vida do pneu, ou é melhor aumentar a frequência
conforme o pneu acumula desgaste?
• Vamos usar um par de pneus em instalados em uma
motocicleta para analisar esta questão.
Exemplo
• A confiabilidade é modelada com uma distribuição Weibull 2p

com Beta 3 e eta 60.000 milhas
• A ação corretiva do pneu segue uma distribuição Normal com
média de 60 milhas e desvio padrão de 20 milhas. O custo de
manutenção Corretiva é de $500.
• Obs. Durações estão configuradas em milhas, significa a quantidade de
milhas equivalentes que poderiam ser utilizadas durante a duração
Exemplo
• A tarefa preventiva (agendada) para um pneu consiste em

inspecionar o pneu em um determinado intervalo, ao qual
permite verificar se a altura do sulco tem menos de 10%
do que o mínimo necessário (vida útil) nesse período, a
troca é feita preventivamente
• A inspeção possui a duração representada por uma
distribuição normal com média de 2,5 milhas e desvio
padrão de 0,5 milhas. O custo da inspeção é de $ 5
• A Substituição planejada possui uma duração regida por
uma distribuição com média de 30 milhas e desvio padrão
de 6 milhas. O custo para troca planejada é de $150
Exemplo
• O intervalo fixo para a inspeção seria de 15.000 milhas.

• Uma inspeção com intervalos dinâmicos seria 30.000 e então
15.000, 10.000, 10.000, 10.000, 7.500, 7.500, 5.000, 5.000,
5.000, 5.000, 5.000, 5.000 milhas.
Exemplo Pneus de Motocicleta
Resultados
• Resultados da
comparação de
Intervalos Fixos vs
Dinâmicos
• Redução de 13% das
falhas não planejadas
• 24% de redução nos
custos de inspeções
• 30% de acrécimo de
substituição planejada
• 9% de redução nos
custos totais
• Obs. Aumento em “On
condition’ ~= diminui
em MCs
Exercício Prático

Exemplo Prático
Barco
• John um experiente instrutor de mergulho, irá comprar um novo

barco para usar em suas aulas diárias
• Ele não quer ficar a deriva e também não afundar no meio do mar
Abaixo estão os
componentes mais
importantes deste
barco aos quais
precisam de
manutenção
O casco
O montante do Motor
O Motor
A Hélice
Exemplo Prático
Barco
• Quando o barco esta na agua, o dia inteiro, o motor e a hélice estão sob
estresse quanto estão em funcionamento, em torno de 4,8 horas por dia
Bloco Confiabilidade Ação Corretiva Manutenção Preventiva
Casco 2P-Weibull: No momento da falha Anual

Beta = 3 Duração = 1 semana Duração= 2 dias
Eta = 30 (anos) Restaura na mesma condição do Restaura 80% desde o ultimo reparo
momento da falha
Montante 2P-Weibull: No momento da falha Baseada na Corretiva do motor
do Motor Beta = 2.5 Duração = 1 dia Duração = 1 hr
Eta = 20 (anos) Restaura tão bom quanto novo Restaura 95% desde o ultimo reparo
Motor 2P-Weibull: No momento da falha 4 vezes por ano
Beta = 2 Duração = 3 dias Duração = imediata
Eta = 20 (anos) Restauração tão bom quanto novo Restaura 90% desde o ultimo reparo
Hélice 1P-Exponential: No momento da falha N/A
MTTF = 6 (meses) Duração = 4 hr
Restaura tão bom quanto novo
Exemplo Prático
Barco
• Qual é a probabilidade de que o Instrutor John ficar à deriva em seu

barco, ou de um princípio de vazamento, caso ele planeje operar
este barco por 30 anos?
• Quantas vezes ele irá consertar a Hélice e o motor durante o uso do
barco no periodo?
Exemplo Barco (Respostas)
• 0,56%
• 13 e 2, respectivamente
Gatilhos de Mudança de
Estado
State Change Triggers
Gatilhos de Mudança de Estado
State Change Triggers
• Gatilhos de mudança de stado permite o usuário especificar o

início de um estado e também o reparo do bloco, Ao longo de
eventos específicos que permite ativar e desativar o bloco
durante a simulação
• Isto permite a modelagem de uma configuração cold standby
sem o uso de um container, isto pode ser útil em modelagens
de sistemas paralelos e complexos
• Estado Inicial
• Ligado. Quando a simulação inicia, o bloco estará ativo
• Desligado. Quando a simulação inicia, o bloco permanecerá inativo até
ser ativado por um gatilho de mudança de estado
• Estados no reparo
• Sempre Ligado. Após o reparo do bloco ele sempre estará ativo
• Always OFF. Após o reparo do bloco ele sempre estará inativo
• Default ON ao menos que o SCT substitua . Depois do reparo do bloco
ele se tornará ativo, ao menos que uma rquisição de um outro gatilho
seja para desativar o bloco estiver parado para reparo
• Default OFF ao menos que o SCT substitua. Depois do reparo do bloco
ele permanecerá inativo, ao menos que uma rquisição de um outro
gatilho seja para ativar o bloco estiver parado para reparo
• Gatilhos mudança de estado podem perfeitamente imitar um

container cold standby em que o item em espera só opera
enquanto a unidade principal estiver em falha.
• Tal como acontece com um container standby, o bloco de Backup só é

ativado quando o bloco principal vem a falhar, ele fica ativo apenas
enquanto o bloco principal permanece em falha.
Analisando e
Melhorando a
Disponibilidade do
Sistema
Índices de Criticidade ReliaSoft
• RS FCI (Failure Criticality Index)

• Este índice é uma medida relativa referente ao número de falhas do
sistema causada pelo componente em análise.
• Porcentagem de vezes em que a falha do componente causou falha no
sistema.
Número de Falhas do Sistema (Componente)

RS FCI =
Número de Falhas do Sistema
• Somente inclui eventos de falha (portanto não inclui eventos de MP

e inspeção).
TÍTULO
Índices de Criticidade ReliaSoft
• RS DECI (Downing Event Criticality Index)

• Este índice é uma medida relativa referente ao número de
eventos de parada do sistema causados pelo componente
em análise.
• Porcentagem de vezes em que qualquer evento de parada do componente

causou parada do sistema.
Número de Eventos de Parada do Sistema (Componente)

RS DECI =
Número de Eventos de Parada do Sistema
• Este índice inclui todos os eventos de parada.

Outros Indicadores
• MTBDE
• Mean time Between Downing Events
Uptime do Componente
MTBDE =
Número de Eventos de Paradado Componente
• MTBF
• Mean Time Between Failures
Tempo Final − Tempo Parado por MC
MTBF =
Número de Falhas do Componente
• Observe que isto não é o mesmo que MTTF (mean time to failure),
normalmente (e erradamente) chamado de MTBF.
Relatório FRED
Exemplo
• Considere uma máquina composta por um subsistema

Mecânicos, um Elétrico e um Pneumático
• Melhore a disponibilidade do Sistema
Electrical
Mechanical
Controls Switch Lighting Other Tray Cam Common Detail Door

Unit Parts Parts
Pneumatics Track Part Light Lift Hammer

Jam Fixture
Blocked Tube Other Valve

Air
Transfer Turnbuckle Other
TÍTULO
Passo 1: Identifique o subsistema de menor disponibilidade (em 1 ano).

Componentes Isolados
Determinando a Causa da Baixa Disponibilidade
de Componentes
• A Disponibilidade de um componente é tanto função da

Confiabilidade quanto da Mantenabilidade.
• Examine as características de Confiabilidade e de
Mantenabilidade dos componentes.
• Podemos utilizar também gráficos e relatórios conforme apresentado
nos slides a seguir.
TÍTULO
TÍTULO
Relatórios do BlockSim
Conclusões-Decisões
• Lift
• Alta Confiabilidade, Baixa Mantenabilidade
Ação: Melhorar a Manutenibilidade
• Common Parts
• Baixa Confiabilidade, Baixa Mantenabilidade
Ação: Melhorar ambas (Confiabilidade e Mantenabilidade)
• Detail Parts
• Baixa Confiabilidade, Alta Manutenibilidade
Ação: Melhorar a Confiabilidade
• Cam Unit
• Alta Confiabilidade, Baixa Mantenabilidade
Ação: Melhorar a Manutenibilidade
Resumo
• Diversos resultados e gráficos podem ser criados para melhor

entender o comportamento do sistema e assim otimizar e
priorizar as melhorias.
Throughput
(Produção)
Análise Throughput
• Nas sessões anteriores, nós nos concentramos nas

falhas e nas ações de reparo do sistema.
• Dessa maneira, nós visualizamos o sistema pela
perspectiva de “up/down” do sistema/componentes.
• Podemos também inserir um novo passo e considerar
o “system throughput” em nossa análise.
• Para definir throughput, assuma que cada
componente do sistema processe (ou produza)
alguma coisa enquanto operando.
Em Análises de Produção é preferível a utilização
de RBDs do que FTAs
Análise Throughput
• Com exemplo, considere o caso apresentado a seguir composto por dois

componentes em série, onde cada um processa/produz 10 e 20 itens por
unidade de tempo (ipu) respectivamente.
• Neste caso, a configuração do sistema não é somente uma configuração,

mas também uma sequência de processamento/produção.
• Em outras palavras, o primeiro componente processa/produz 10 ipu e o segundo
componente pode processar/produzir até 20 ipu.
• Neste caso entretanto, o segundo componente pode somente processar/produzir
os itens recebidos do bloco anterior a ele, ou seja, só irá receber 10 itens do bloco
anterior a ele.
• Se nós assumirmos que nenhum dos componentes pode falhar, então o número
máximo de itens que serão processados por esta configuração será de 10 ipu.
• Se o sistema for operar por 100 unidades de tempo, então o throughput deste
sistema será de 1000 itens, ou 100 x 10.
Terminologia & Cálculos Throughput
• Sistema Throughput - System Throughput

• Número total de itens processados/produzidos pelo sistema durante o
tempo total definido.
• Componente Throughput - Component Throughput
• Número total de itens processados/produzidos por cada componente
(bloco).
• Capacidade Máxima do Componente - Component Maximum
Capacity
• O número máximo de itens que os componentes (blocos) podem
processar/produzir se estes estiverem operando durante o tempo total da
simulação.
• Capacidade Disponível do Componente - Component Uptime
Capacity
• O número máximo de itens que os componentes puderam
processar/produzir enquanto estavam em operação.
Terminologia & Cálculos Throughput
• Componente Excede sua Capacidade - Component Excess Capacity

• A quantidade adicional que um componente podia ter
processado/produzido enquanto operando.
• Utilização Atual do Componente - Component Actual Utilization
• A proporção entre o throughput de um componente e sua capacidade
máxima.
• Utilização do Componente Disponível - Component Uptime
Utilization
• A proporção entre o throughput de um componente e sua capacidade
disponível.
Reserva (Backlog)
• Itens que o componente não poderia processar são mantidos em

reserva.
• Reserva do Componente - Component Backlog
• O número total de itens em reserva para o componente ao final da
simulação.
• Reservas Processadas pelo Componente - Component Processed
Backlog
• O número total de reservas processadas pelo componente.
• Excesso de Reservas - Excess Backlog
• A partir de definições das propriedades no BlockSim, os componentes
podem aceitar reservas limitada. Nestes casos, as reservas serão rejeitadas
e estocadas na categoria “Excess Backlog”.
Configurações do Throughput (Bloco)
• Um bloco pode ignorar ou processar reserva.

Itens que não podem ser processados são
armazenados e são processados quando
necessário. Além disso, pode-se definir o
número máximo de itens que podem ser
armazenados em um bloco.
• Quando você optar por ignorar a reserva, o
BlockSim ainda irá relatar os itens que não
podem ser processados na coluna “Reserva”.
No entanto, vai deixar acumular, mas não irá
processar a reserva.
• No caso de reserva limitada, o BlockSim não
vai acumular mais itens do que o máximo
permitido, e irá descartar todos os itens
enviados para o bloco que excedam a sua
capacidade de acumulação.
Parametrização do Throughput (Simulação)
Throughputi
Pi = N
∑ Throughput
j =1
j
Se esta opção não estiver selecionada, as

alocações só serão realizadas dentre os blocos
que ainda estão operando. Caso contrário, se
selecionada, os itens serão alocados aos blocos
em falha e eles se tornarão parte da reserva
(backlog) deste bloco.
Cenário 1
• Através do bloco A se processam um número de itens por

unidade de tempo como identificado próximo a cada letra (ex. A:
100 implica em 100 unidades por unidade de tempo para A).
• As conexões RDB apresentam o caminho físico dos itens através
do processo (ou linha de produção).
• Além disso, e para simplificar, também assumimos que os blocos
nunca irão falhar, e que os itens são distribuídos uniformemente
pelos caminhos.
Cenário 1
• Este cenário implica (em um única unidade de tempo), que:

• Bloco A produz 100 itens e distribui 33,33 para B, 33,33 para C e
33,33 para D.
• Bloco B, C e D distribuem seus 33,33 para E, F, G e H (8,33 para cada
caminho).
• E, F, G, H direcionam 25 cada para I.
• I processa todos os 100.
• O sistema produz 100 itens.
Cenário 1
• Assim, após 1 unidade de tempo, a tabela a seguir representa a

capacidade de throughput e de excesso de cada bloco.
Block Throughput Summary

Block Name (Diagram) Throughput Excess Cap
A: 100 100 0
B: 50 33.3333 16.6667
C: 50 33.3333 16.6667
D: 50 33.3333 16.6667
E: 40 25 15
F: 40 25 15
G: 40 25 15
H: 40 25 15
I: 200 100 100
Cenário 2
• Agora assuma que o bloco E falhou.
• Então:
33,33 para D.
• Bloco B, C e D distribuem seus 33,33 para F, G e H (11,11 para cada
caminho que possui um bloco operacional até o final).
• F, G, H distribuem 33,33 cada para I.
Cenário 2
Block Throughput Summary

Block Name (Diagram) Throughput Excess Cap
A: 100 100 0
B: 50 33.3333 16.6667
C: 50 33.3333 16.6667
D: 50 33.3333 16.6667
E: 40 0 0
F: 40 33.3333 6.6667
G: 40 33.3333 6.6667
H: 40 33.3333 6.6667
I: 200 100 100
Cenário 3
• Se ambos E e H falharem:
Cenário 3 - Registro de Evento

33,33 para D.
• Blocos B, C e D distribuem seus 33,33 para F e G (16,66 para cada
caminho que possui um bloco operacional até o final).
• F e G recebem 50 itens cada.
• F e G processam e distribuem 40 cada (suas capacidades máxima
de processamento) para I. Ambos possuem uma reserva de 10, já
que eles não podem processar todos os 50 itens recebidos.
Cenário 3 - Resultados
• Podemos observar que o sistema possui um “gargalo”

nos blocos F e G.
Block Throughput Summary Actual Utilization

Block Name (Diagram) Throughput Excess Cap Backlog Block Name (Diagram) Actual Utilization
A: 100 100 0 0 A: 100 100%
B: 50 33.3333 16.6667 0 B: 50 67%
C: 50 33.3333 16.6667 0 C: 50 67%
D: 50 33.3333 16.6667 0 D: 50 67%
E: 40 0 0 0 E: 40 0%
F: 40 40 0 10 F: 40 100%
G: 40 40 0 10 G: 40 100%
H: 40 0 0 0 H: 40 0%
I: 200 80 120 0 I: 200 40%
Exemplo Determinístico
(com Falha/Reparo)
TÍTULO
Block Up/Down
E: 70
D: 30
Block Fail Time Repaired By

A: 60 65 69
C: 20 B: 10 50 54
C: 20 55 59
D: 30 60 54
B: 10 E: 70 70 74
A:60
System
0.000 20.000 40.000 60.000 80.000 100.000
Time, (t)
Registros (Logs)
Event 1: B Fails at 50
A B C D E
Start Time End Time 60 10 20 30 70
0 50 3000 500 1000 1500 3000 Processed
Current
0 0 0 0 500 Excess Capacity
0 0 0 0 0 Backlog
0 0 0 0 0 Backlog Processed
3000 500 1000 1500 3000 Processed
Cumulative
0 0 0 0 0 Backlog
Event 2: B is Down 50 to 54
A B C D E
50 54 240 0 80 120 200 Processed
Current
0 0 16 24 0 Backlog
3240 500 1080 1620 3200 Processed
Cumulative
0 0 16 24 0 Backlog
Registros (Logs)
Event 3: All Up - 54 to 55
A B C D E
54 55 60 10 20 30 60 Processed
Current
0 0 0 0 0 Backlog
3300 510 1100 1650 3260 Processed
Cumulative
0 0 16 24 0 Backlog
Event 4: C Down - 55 to 59
A B C D E
55 59 240 40 0 120 160 Processed
Current
0 20 0 60 0 Backlog
3540 550 1100 1770 3420 Processed
Cumulative
0 20 16 84 0 Backlog
Registros (Logs)
A B C D E
59 60 60 10 20 30 60 Processed
Current
0 0 0 0 0 Backlog
3600 560 1120 1800 3480 Processed
Cumulative
0 20 16 84 0 Backlog
Event 6: D Down - 60 to 64
A B C D E
60 64 240 40 80 0 120 Processed
Current
0 40 80 0 0 Backlog
3840 600 1200 1800 3600 Processed
Cumulative
0 60 96 84 0 Backlog
Registros (Logs)
A B C D E
64 65 60 10 20 30 60 Processed
Current
0 0 0 0 0 Backlog
3900 610 1220 1830 3660 Processed
Cumulative
0 60 96 84 0 Backlog
Event 8: A Down - 65 to 69
A B C D E
65 69 0 40 80 84 204 Processed
Current
0 -40 -80 -84 0 Backlog
3900 650 1300 1914 3864 Processed
Cumulative
0 20 16 0 0 Backlog
Registros (Logs)
A B C D E
69 70 60 10 20 30 60 Processed
Current
0 0 0 0 0 Backlog
3960 660 1320 1944 3924 Processed
Cumulative
0 20 16 0 0 Backlog
Event 10: E Down - 70 to 74

A B C D E
70 74 240 0 0 0 0 Processed
Current
0 40 80 120 0 Backlog
4200 660 1320 1944 3924 Processed
Cumulative
0 60 96 120 0 Backlog
Registros (Logs)

A B C D E
74 100 1560 260 520 780 1560 Processed
Current
0 0 0 0 0 Backlog
5760 920 1840 2724 5484 Processed
Cumulative
0 60 96 120 0 Backlog
Resumo
• Throughput acrescenta uma dimensão a mais à suas análises.

• Apesar do exemplo apresentado aqui ser bastante simples, ele
apresenta a base da análise de throughput. Estes princípios
serão os mesmos não importa quão complexo se torne o
sistema.
Incluindo Custos na
Introdução das Análises
para o Custo do Ciclo de
Vida
Life Cycle Costs - LCC
• A análise de Life Cycle Cost introduz os custos do

sistema durante toda a extensão de sua vida.
• Normalmente os custos podem incluir:
• Custos de aquisição (ou Custos de Projeto e Desenvolvimento)
• Custos Operacionais
• Custo das Falhas
• Custo de Reparo
• Custo de Itens Sobressalentes (Peças de Reposição)
• Custo do Tempo Parado (Downtime)
• Lucro Cessante
• Custo da Disposição
Life Cycle Costs - Custos Probabilísticos
• O assunto Life Cycle Costs inclui muitos aspectos de

contabilidade/financeiro que estão além do escopo deste curso
(tais como taxas de desconto, taxas de juros, depreciação, valor
presente, etc.).
• Alguns destes itens requeridos pela análise de LCC são
determinísticos (ex. custo de aquisição, custo da disposição, etc).
A inclusão de custos determinísticos é trivial.
• O aspecto mais complicado na análise de LCC são os custos
associados aos custos de operação do sistema.
• Nesta sessão, nós iremos tratar os custos probabilísticos.
Exemplo com Custos
• Considere a seguinte linha de produção:

Propriedades dos Blocos
Blocks A Blocks B Blocks C

Failure Failure Failure
β η β η β η
Weibull Weibull Weibull
2 20,000 2 10,000 3 8,000
OTSF Yes OTSF Yes OTSF Yes
Repair Repair Repair
µ µ µ
Exponential Exponential Exponential
100 50 70
Crews Pool & Policies Crews Pool & Policies Crews Pool & Policies
Crew 1 Crew 1 Crew 1
Repair Crews Repair Crews Repair Crews
Crew 2 Crew 2 Crew 2
Policy Upon Failure Policy Upon Failure Policy Upon Failure
Spare Pool A Pool Spare Pool B Pool Spare Pool C Pool
Throughput Throughput Throughput
Parts/hour 4 Parts/hour 1 Parts/hour 1
Process Backlog Yes Process Backlog Yes Process Backlog Yes
Limited Backlog No Limited Backlog No Limited Backlog No
Other Costs Other Costs Other Costs
Operating Cost /hour $10.00 Operating Cost /hour $2.00 Operating Cost /hour $2.00
Recursos
Pool A Pool B Pool C

Cost Per Item $5,000.00 Cost Per Item $3,000.00 Cost Per Item $2,000.00
Indirect Cost Per Item 1 Indirect Cost Per Item 1 Indirect Cost Per Item 1
Initial Stock 1 Initial Stock 1 Initial Stock 1
Logistic Time to Dispense Logistic Time to Dispense Logistic Time to Dispense
µ µ µ
20 20 20
On-Condition Restock On-Condition Restock On-Condition Restock
Restock at 0 Restock at 0 Restock at 0
Restock items 1 Restock items 1 Restock items 1
Time for Stock Arrival Time for Stock Arrival Time for Stock Arrival
µ µ µ
30 30 30
Emergency Emergency Emergency
Can Obtain Yes Can Obtain Yes Can Obtain Yes
Cost Per Item $10,000.00 Cost Per Item $6,000.00 Cost Per Item $4,000.00
Time for Emergency Arrival Time for Emergency Arrival Time for Emergency Arrival
µ µ µ
70 70 70
Crew 1 Crew 2
Direct Cost per hour 100 Direct Cost per hour 100
Cost per incident 0 Cost per incident 500
Num. Sim. Tasks 1 Num. Sim. Tasks 1
Logistic Delay Logistic Delay
µ µ
Exponential Exponential
30 50
Exemplo de Resultados
• Disponibilidade Média: 99.41%

Simulation Summary
End Time: 8760
Run Options: Standard Simulations
• Tempo Disponível: 8708.63 h Number of Simulations:
Seed Value:
10000
10
• Downtime: 51.36 h General

System Overview
Mean Availability (All Events): 0.994136

Std Deviation (Mean Availability): 0.000315
Mean Availability (w/o PM, OC & Inspection): 0.994136
Point Availability (All Events) at 8760: 0.9872
Reliability(8760): 0.6819
Expected Number of Failures: 0.3785
Std Deviation (Number of Failures): 0.020547
MTTFF (Hr): 24409.88843
System Uptime/Downtime
Uptime (Hr): 8708.632889
CM Downtime (Hr): 51.367111
Inspection Downtime (Hr): 0
PM Downtime (Hr): 0
OC Downtime (Hr): 0
Total Downtime (Hr): 51.367111
System Downing Events
Number of Failures: 0.3785
Number of CMs: 0.3785
Number of Inspections: 0
Number of PMs: 0
Number of OCs: 0
Number of OFF Events by Trigger: 0
Total Events: 0.3785
Custos
• Direto do BlockSim (Os Custos

System Cost Summary
Misc. Corrective Costs: 0
Costs for Parts (CM): 21559.1
do Sistema). Costs for Crews (CM):
Total CM Costs:
84779.5657
106338.666
• Observe que o custo adiciona Misc. Preventive Costs:

Costs for Parts (PM):
0
0
foi definido por item por hora Costs for Crews (PM):
Total PM Costs:
0
0
de operação (o qual não é Misc. On Condition Costs:

Costs for Parts (OC):
0
0
incluso no resumo). Costs for Crews (OC):

Total OC Costs:
0
0
• Além disso, assuma uma Misc. Inspection Costs:

Costs for Crews (IN):
0
0
receita de $100 por item

Total Inspection Costs: 0
Downtime Costs: 0
produzido. Indirect Pool Costs: 16323.9639
Total Costs: 122662.63

Exemplo de Análise Financeira
Mais Resultados
Exercício Prático

Exemplo Prático
Barragem
• Uma nova barragem está

sendo contruida sobre o “Rio
Branco”, e a Disponibilidade,
rentabilidade e lucratividade
das novas unidades geradoras
de energia desta barragem
devem ser validadas
• O sistema é composto pelo rio,
lago e 3 unidades geradoras e
uma Rede Elétrica
• As 3 unidades geradoras estão
em paralelo e são identicas
Exemplo prático
Barragem
• Todos os blocos serão considerados como “operam mesmo se o sistema

falhar”
Bloco Confiabilidade Manutenção Corretiva Manutenção Preventiva
Rio N/A N/A N/A

Lago N/A N/A N/A
Unidade 2P-Weibull: Normal: Normal:
Geradora Beta = 1.15 Mean = 14, Std. = 1 (dia) Média = 7, sigma. = 1 (dia)
de Energia Eta = 1e5 (hr)
Equipe de Reparo: Equipe de Manutenção:
Delay, Normal: Sem atrasos
Mean = 7, Std. = 1 (dia)
Fator de restauração Tipo 1
Sobressalentes 15% - executada todo ano
Somente emergência baseado na idade
Atraso, Normal: calendário
Mean = 60, Std. = 14 (dia)
Rede 1P-Exponential: Normal: N/A

Elétrica MTTF = 17,520 (hr) Média= 8, Sigma. = 2 (hr)
Exemplo Prático
Barragem
• Receita do Sistema
• Receita por unidade Produzida:1
• Custos do Sistema:
• Custo por falha do sistema: 5,000
• Taxa de Lucro cessante: 100/ hr
• Desconsidere custos relacionados ao Rio, lago, e a Rede Elétrica
• Custos da Unidade Geradora:
• Custos pela consequência da Falha: 25.000
• Equipe de Corretiva:
• Custo Direto (HH): 250/ hr (incluso atraso logístico)
• Custo por incidente: 5.000
• Sobressalentes: 1.000.000 por unidade solicitada
• Custo por MP: 15.000
• Equipe de Manutenção
• Custo HH: 200/ hr
• Custo por Incidente: 5.000
Exemplo Prático
Barragem
• Toda alocação de Produção é feita com base em “Alocar igualmente

em todos os caminhos”
• A taxa média de vazão do rio foi considerada pra ser de 600 unidades
de água por hora
• Cada unidade Geradora é capaz de transformar 300 unidades de
água por hora em 300 unidades de eletricidade/hora.
• O lago pode processar reserva, e tem capacidade máxima de saída
igual a soma das 3 unidades geradoras (900 unidades de água/hora)
• A rede elétrica é capaz de lidar com toda a energia gerada pelas 3
unidades geradoras em plena capacidade(900 unidades elétricas por
hora)
• A simulação deve rodar até 175.200 horas (20 anos) e, configurada
para 5000 simulações
Respostas
Barragem
• A disponibilidade do sitema não é um parâmetro útil com

informação desse estudo de caso.
• Os fatores importantes são os custos e a receita
• A receita esperada supera os $105 M, ao passo que os custos totais

do sistema é inferior à $9M.
Planilhas das Simulações
Planilhas de Simulação
• Planilhas de simulação podem ser usadas para alterar certos

valores dentro do RBD para facilitar a comparação das
diferenças de resultados devido à alterações nas especificações
• Útil para comparações de projetos, fornecedores ou
simplesmente com tentativa de otimização do sistema
• As alterações são feitas pela variação dos valores de entradas

das variáveis, usadas na simulação
• O RDB então é simulado novamente com as variáveis alteradas,
gerando novos resultados aos quais podem ser comparados
com os resultados originais, possibilitando o encontro dos
valores ótimos desejados, para as propriedades representadas
pela as variáveis em questão
• DOE++ pode ser usado para otimizações
Propriedades como variáveis
• As seguintes propriedades podem variar dentro de uma planilha de

simulação, utilizando a seguintes variáveis:
• Modelo dinâmico (qualquer modelo baseado em propriedades)
• Produção(bloco)
• Intervalos Fixos(Tarefas Agendadas)
• Limite de atividades Simultâneas (por equipe)
• Estoque Inicial(Estoque)
• Capacidade Máxima(Estoque)
• Reposição a cada (Reposição programada do estoque)
• Números adicionados por reposição (Reposição programada do
estoque)
• Repor quando o estoque cair a(Reposição quando necessária -
Sobressalentes)
• Quantidade adicionada na reposição(Reposição quando necessária -
Sobressalentes
• Quantidade Adicionada em Emergência(Sobressalentes)
Planilha de Simulação
• Um sistema de bombas 2-de-3 precisa ser analisado afim de

definir uma política de sobressalentes
• Sem o sistema de bombas operando, a planta inteira para
• O sistema tem que gerar uma disponibilidade média de 99%
• As bombas são extremamente caras e difíceis de adquirir devido
a sua complexidade e devem ser encomendadas com
antecedência
• Elas são difíceis de serem estocadas na planta
• As bombas possuem confiabilidade descrita por uma distribuição
Weibull 2p com Beta=2,5 e Eta de 1800 horas
• O tempo para substituir uma bomba segue uma distribuição
Normal com média de 96 horas e Desvio Padrão de 8 horas
• Restrições da Política de sobressalentes

• A gerência ordenou que somente 1 ou 2 bombas sobressalentes
devem estar estocadas inicialmente
• Além disso, somente 1 ou 2 bombas devem ser encomendadas
em qualquer período.
• A empresa que fabrica as bombas possui uma estrutura de
preços diferente para o intervalo de tempo entre as
encomendas, com estas opções o intervalo será a cada 2
semanas
Configuração do sistema
• No BlockSim, o RBD e as propriedades da bomba devem

parecer como as imagens a seguir
Configuração do sistema
• As tarefas corretivas e a política de sobressalentes devem seguir as

seguintes características:
• A Planilha de simulação deve ser preenchida com as diversas

combinações possíveis das variaveis de entrada
• O topo das colunas podem ser alteradas para ajudar com a
organização
• Selecione o Diagrama que contenha o sistema bomba e os

inputs/outputs da planilha, similar às figuras abaixo
Simulation Worksheet Results
• Os Resultados indicam que duas opções com os custos mais baixos,

possuem reposição a cada 1.008 horas (seis semanas) e a reposição com
compra de duas bombas. O estoque atual ainda está mais elevado do que o
desejado após 10 anos, mas o custo é o mais baixo dentre as opções
disponíveis.
Initial Stock Restock Rate Restock Mean Current Stock Total Cost
Amount Availability Level
1 336 1 0.991007 54.598 2621037
1 336 2 0.991007 184.598 4290971
2 336 1 0.991007 55.598 2646037
2 336 2 0.991007 185.598 4315971
1 672 1 0.989902 1.294 3027117
1 672 2 0.990998 54.615 2607472
2 672 1 0.989837 1.333 2934819
2 672 2 0.991007 55.598 2630351
1 1008 1 0.985327 0.491 4975976
1 1008 2 0.991091 11.175 2106097
2 1008 1 0.985882 0.464 4885142
2 1008 2 0.990969 11.757 2090422
1 1344 1 0.982188 0.188 5967480
1 1344 2 0.989445 0.976 3095550
2 1344 1 0.982339 0.21 5873373
2 1344 2 0.989729 1.042 3005344
Diagrama de Fases de
Confiabilidade (RPD)
Diagrama de Fases de Confiabilidade (RPD)
Introdução
• O diagrama de fases pode ser usado para representar/analisar um

sistema, cuja confiabilidade e configuração ou outras propriedades,
podem mudar ao decorrer do tempo.
• Durante uma missão, o sistema pode sofrer alterações em sua
configuração de confiabilidade (RBD), nos recursos disponíveis, falha,
manutenção e/ou rendimento de seus componentes individuais.
• Cada etapa durante uma missão pode ser representada por uma fase
e ser representada por um RBD correspondente a sua configuração
de confiabilidade, juntamente com quaisquer recursos associados do
sistema durante a esse período.
• O diagrama de fases é uma série de fases conectadas em uma
seqüência significando uma ordem cronológica.
Exemplos
1. Sistemas cujos componentes apresentam diferentes distribuições

de falhas em função das mudanças no estresse sobre o sistema.
2. Os sistemas ou processos que exigem diferentes equipamentos
para funcionar ao longo de um ciclo, tais como o start-up,
produção normal, shut-down, manutenção programada, etc
3. Sistemas onde a a configuração altera em diferentes tempos, tal
como o RBD de uma aeronave com quatro turbinas, nas fases de
taxiamento, decolagem, cruzeiro e pouso.
4. Sistemas com diferentes tipos de máquinas operando durante o
turno da manhã e da noite e com diferentes produções em cada
um destes turnos.
Exemplo de uma Aeronave
Taxiing Take-Off Cruising Landing Taxiing

Taxiamento
Engine
Landing
Gear
Engine
Navigation 1-out-of-4 Landing 3-out-of-3

System Gear
Engine
Landing
Engine Gear

Take-Off
Engine
Landing
Gear
Engine

System Gear
Engine
Landing
Engine Gear

Cruzeiro
Engine
Engine
Navigation 3-out-of-4
System
Engine
Engine

Pouso
Engine
Landing
Gear
Engine

System Gear
Engine
Landing
Engine Gear

Tipos de Fases
• Fase Operacional
• Fase de Manutenção
Tipos de Fases:
1 - Fase Operacional
• Uma fase operacional é utilizada para representar

qualquer fase da missão do sistema que não é
exclusivamente dedicado a tarefas de manutenção.
• Fases Operacionais são sempre definidas por um RBD.
Cada um possui uma fase operacional fixa, com período de
tempo pré-determinado.
Tipos e Fases:
2 - Fase de Manutenção
• Representa uma porção da missão do sistema onde o mesmo está

indisponível e ações de manutenção são realizadas em alguns ou
todos os seus componentes.
• É representada por um modelo que lista os componentes (blocos)
que estão designados a serem submetidos a ações de inspeção,
reparo ou substituição durante as fases de manutenção, juntamente
com sua prioridade de manutenção.
• Dependendo dos recursos disponíveis, as ações serão priorizadas tal
como os recursos permitirem.
• Dado que todos os aspectos da manutenção podem ser definidos
probabilisticamente, a duração da fase de manutenção, ao contrário
da fase operacional, não é fixa e pode durar o tempo que for
necessário para completar todas as ações especificadas.
Execução dos Ciclos e Diagramas de Fases
• A execução do diagrama de fases iniciando no primeiro diagrama (de fases)

e finalizando no último diagrama (de fases) é dito como um ciclo.
• Se o tempo final da simulação exceder a duração total de um ciclo do
diagrama de fases, a simulação continua e o diagrama de fases é executado
diversas vezes até que o tempo final da simulação seja alcançado.
• A execução do diagrama de fases diversas vezes durante a simulação é
denominado de ciclagem.
• Durante a ciclagem, a idade do componente acumulada na última fase do
ciclo anterior é transportada para a primeira fase do próximo ciclo. O
princípio de danos acumulado é utilizado para transportar a idade através
das fases para cada componente (bloco).
Cycle
Cycling
Propriedades da Fase Operacional
• Diagrama: Associa um RBD a uma fase operacional.

• Componentes Comuns: Um componente que possua
exatamente o mesmo nome em dois RBDs é assumido como
sendo o mesmo componente trabalhando em duas fases
diferentes.
• Duração da Fase: A duração de uma fase operacional é fixa e

necessita ser especificada.
• Ciclo de Operação da Fase: Permite que se especifique um
valor comum para o ciclo de operação para todos os
componentes da fase operacional. Isto é adicional ao valor do
ciclo de operação que pode ser especificado ao nível do bloco
(ciclo de operação geral = ciclo de operação do componente ×
ciclo de operação da fase).
• Nas Falhas no Sistema:

Esta propriedade é utilizada para configurar uma ação específica
quando uma falha no sistema ocorre na fase. Existem três opções:
• Continuar a simulação.
• Iniciar nova simulação.
• Ir para a fase de manutenção.
Opções na Falha do Sistema:
Continuar a Simulação
• Quando uma falha no sistema ocorre, reparos se iniciam tal como a

política de reparo selecionada e o tempo para restaurar o sistema é
parte do tempo da fase operacional.
• Os reparos continuam na fase operacional até que o sistema volte a
operar. Se o reparo não for finalizado antes do final da fase, o reparo
continua até a próxima fase.
• A duração da fase operacional não é afetada pela falha do sistema.
Exemplo:
Uma linha de produção opera em dois turnos (fases), diurno e noturno.
Uma falha ocorre no turno diurno. Reparos se iniciam e continuam além
do turno diurno. A linha de produção é restaurada após a meia noite.
Neste caso, o reparo utiliza todo o tempo do turno diurno e se estende
também por parte do turno noturno.
Iniciar uma Nova Simulação
• Esta opção retém a simulação, a que efetivamente significa que

ocorrerá o fim da missão se o sistema falhar.
• A execução da atual fase operacional e todas as fases que seguem
ela será retida, e a missão será abortada.
• Esta opção pode também ser utilizada para modelar um sistema
no qual a falha não pode ser reparada e a missão tem que ser
abortada se uma falha ocorrer.
Exemplo:
Para uma aeronave, um falha catastrófica durante o vôo poderia
finalizar a missão.
Ir para a Fase de Manutenção
• Esta opção leva o sistema direto para sua fase de manutenção se

uma falha no sistema ocorrer.
• Se outras fases existirem entre a atual fase operacional e a sua fase
de manutenção, então estas fases serão puladas e a execução
continuará após a fase de manutenção ter sido finalizada.
• Na fase de manutenção, tarefas são efetuadas em todos os
componentes incluídos no modelo de manutenção conectado.
Exemplo:
Uma aeronave que teve uma falha durante a fase de taxiamento. Se
a fase de manutenção especificada para esta fase é a última fase do
RPD, então a falha durante o taxiamento levaria para a fase de
manutenção em daí então finalizar o ciclo.
Transferir Idade Através das Fases
• O princípio de transferir idade é crucial para entender o

conceito de fases.
• Os componentes acumulam idade (desgaste - velhice) assim que
eles caminham de fase em fase, e suas idades acumuladas estão
diretamente relacionadas a sua probabilidade de falhar durante
a próxima fase.
• Qualquer dano que o componente possa ter acumulado nas
fases anteriores devem ser carregados para a próxima fase (a
menos que o componente seja reparado).
• É importante observar que um componente (um bloco) pode
possuir uma distribuição de falha diferente em diferentes fases,
e pode ter acumulado diferentes níveis de dano em cada fase.
• Para transferir corretamente a idade de tal bloco através das
fases, os princípios de danos acumulados será utilizado.
Transferir Idade Através das Fases
• Um bloco vai operar através de duas fases.

• Se o bloco sobreviver à primeira fase, então a confiabilidade do bloco no
início da fase 2 é a mesma que a confiabilidade no final da fase 1, uma vez
que esses dois eventos ocorrem no mesmo tempo:
𝑹𝑹𝑷𝑷𝑷𝑷𝑷𝑷𝑷𝑷𝑷𝑷𝑷𝑷 𝑻𝑻𝑬𝑬𝑬𝑬𝑬𝑬𝑬𝑬 = 𝑹𝑹𝑷𝑷𝑷𝑷𝑷𝑷𝑷𝑷𝑷𝑷𝟏𝟏 𝑻𝑻𝟏𝟏

→ Solve for TEqv1
onde:
𝑇𝑇1 : Duração da Fase 1
𝑇𝑇𝐸𝐸𝐸𝐸𝐸𝐸𝐸 : Duração equivalente a 𝑇𝑇1 se o bloco estivesse operando na Fase
2 desde o início.
• Assim, na Fase 2, o bloco começa com 𝑇𝑇𝐸𝐸𝑞𝑞𝑣𝑣1 e idade acumulada. Usando
a probabilidade condicional, então calculamos um tempo até a falha
para esta fase, condicionada à idade acumulada do bloco.
Fase de Produção (Throughput):

Permite especificar a capacidade produtiva (throughput) para o sistema na
fase operacional. A capacidade produtiva pode ser:
• Constante.
• Variável: Um modelo pode ser especificado junto com uma
capacidade de produção máxima na fase.
Propriedades da Fase de Manutenção
Modelo de Manutenção:
Especifica o modelo que
contém a lista de blocos que
sofrerão manutenção se a
fase de manutenção for
acionada.
• Idade Limite do Sistema :

Adiciona flexibilidade para a programação das ações de manutenção
preventiva e/ou executar inspeções através delas, quando o sistema estiver
indisponível (não operante) na fase de manutenção.
É utilizado para especificar um intervalo de tempo para a execução de uma
ação de manutenção preventiva ou inspeção durante a fase de
manutenção.
Exemplo:
Uma ação de manutenção preventiva está programada para um carro a
cada 60.000 milhas, mas uma falha de um componente fez com que o
sistema parasse com 55.000 milhas. Se a idade limite do sistema é 0,9, a
manutenção preventiva será realizada já que a falha ocorreu após o sistema
ter acumulado 91,67% do tempo programado para a manutenção.
Ordem de Priorização da Manutenção :

Permite que você especifique a ordem na qual as ações de manutenção
são realizadas nos blocos.
Quando uma fase de manutenção começa em um diagrama de fases, as
ações de manutenção irão iniciar no primeiro bloco e continuar seguindo
a ordem da lista.
Resultados da Simulação do RPD
TÍTULO
End of the wonderful one-hoss shay.

Logic is logic. That's all I say.
Oliver Wendell Holmes, “The Deacon’s Masterpiece,” 1858, Last Paragraph

© 1998-2022 Compass (Reliasoft Brasil Ltda.) Todos Os Direitos Reservados

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

© 1998-2022 Compass (Reliasoft Brasil Ltda.) Todos Os Direitos Reservados

Enviado por

Direitos autorais:

Formatos disponíveis

© 1998-2022 Compass (ReliaSoft Brasil Ltda.

“Este material é de propriedade exclusiva da Compass e a sua utilização é somente

Estas notas são destinadas a

A maioria das derivações

A cobertura do “Livro Texto"

Sistema de Confiabilidade e Princípios de Análises de Princípios de Análises de

Essas referências são publicadas na web em http://www.ReliaWiki.org.

• O conhecimento da teoria e princípios

8:30 9:40 10:50 Lunch 13:00 14:10 15:20

Estudos de Caso em Grupo Estudos de Caso em Grupo

*Podem ser utilizadas dependendo do país / localização e horários de início

Have you heard of the wonderful one-hoss shay,

Oliver Wendell Holmes, “The Deacon’s Masterpiece,” 1858, Paragraph 1

• Neste curso, nós iremos definir um sistema como sendo uma

Teoricamente, a definição de um sistema poderia chegar até o último nível possível.

• Realizar testes em sistemas para levantar a sua confiabilidade

• Teste de vida é geralmente realizado pelos fornecedores dos

• A Confiabilidade de um componente é quantificada utilizando

• Cada componente pode ser descrito por diferentes modelos.

Nós podemos também entender um componente

• Utilize os modelos dos componentes para criar o modelo do

• Os tipos de componentes, suas quantidades, suas qualidades e

• Utilizando a Abordagem de Diagrama de Blocos de Confiabilidade

• Um Diagrama de Blocos de Confiabilidade é uma

• Linhas conectam os blocos.

• Um bloco pode representar:

• Cada Bloco representa um componente, montagem, sistema

• No mínimo um bloco de Confiabilidade pode incluir

• Os blocos de Confiabilidade possuem propriedades.

Probability Density Function

• Uma vez determinada as características de Confiabilidade, elas

• Um diagrama de árvore de falhas segue uma estrutura top-

• Os caminhos de conexão dos eventos e as condições de uso

• Probabilidades numéricas de ocorrência podem ser inseridas e

EVENTO TOPO: • A falha de maior nível em que está

PORTA: • Símbolos lógicos que interligam os

EVENTO: •Contribuidores / indicadores (por

• Determinar um Evento Topo

• Definir o Escopo da Análise

• Identificar Eventos Contribuintes

• Relacionar os Acontecimentos / Efeitos com Portas Lógicas

• Portas Lógicas não devem alimentar outras portas sem um

• Ser consistente ao nomear os mesmos eventos em toda a

• As falhas em qualquer nível de análise devem ser

(*) As Árvores de Falhas no

• Os diferentes eventos em uma árvore de falhas não são

Evento Básico(Evento - Falha):

Evento Casa (Gatilho):

Evento não Desenvolvido

• Blocos são conectados em modo série.

• Um sistema pode possuir itens conectados em série quando a

Se itens estão conectados em série, então todos necessitam estar funcionando

Now in building of chaises, I tell you what,

Oliver Wendell Holmes, “The Deacon’s Masterpiece,” 1858, Paragraph 3

• Todos os itens em série necessitam ter sucesso para que a

𝑅𝑅𝑆𝑆 = 𝑅𝑅1 × 𝑅𝑅2 × ⋯ × 𝑅𝑅𝑛𝑛

• Três subsistemas estão conectados em série compondo um

Sub 1 Sub 2 Sub 3

• Já que os subsistemas estão especificados para 100 h, a

𝑅𝑅𝑠𝑠 = 𝑅𝑅1 × 𝑅𝑅2 × 𝑅𝑅3

Observe que neste caso a Confiabilidade do sistema é sempre

• A equivalência da configuração série é uma porta “OU”

• Um sistema pode também possuir itens conectados em