RBI según API RP 581: ¡no es una buena idea!
No tiendo a repetir mis publicaciones anteriores a menos que exista una buena causa para
revisarlas. En 2012 publiqué “Cinco fallas fatales en API RP 581”. Ha sido ampliamente leído, pero
a pesar del mensaje de que API RP 581 es un método ineficiente y engañoso, la práctica
recomendada se ha convertido en una plantilla bien establecida para realizar RBI en la industria
transformadora.
Su método y estructura se han incorporado en sistemas de gestión de integridad administrados,
entre muchas otras, por corporaciones acreditadas como DNV.
1. El concepto de frecuencia genérica de fallas: probabilidad de falla como propiedad
intrínseca de todos los equipos, independientemente de su causa y evitabilidad.
frecuencia de falla genérica GFF
Un POF desarrollado para tipos de componentes específicos basado en una gran población de
datos de componentes que no incluir los efectos de mecanismos de daño específicos. La población
de datos de componentes puede incluir datos de todas las plantas dentro de una empresa o de
varias plantas dentro de una industria, de fuentes bibliográficas, del pasado, informes y bases de
datos comerciales.
2. El concepto de un factor de daño que multiplica la frecuencia genérica de fallas,
dependiendo de la configuración y las condiciones, independientemente de la cuestión de
si la inspección puede mitigarlo.
factor de daño DF
Un factor de ajuste aplicado a la frecuencia de falla genérica (GFF) de un componente para tener
en cuenta los mecanismos de daño que están activos en un componente.
3. El concepto de aplicar las estadísticas de fallas como herramienta de predicción de fallas.
4. La premisa de que la inspección por sí sola puede generar integridad.
5. La premisa de que un programa de inspección más amplio mejora la evaluación de riesgos.
Abordaré los defectos nrs. 1. y 2. Los otros defectos siguen ahí, pero mis argumentos en contra de
ellos siguen siendo válidos.
El propósito de la inspección, y de eso se trata el RBI, es reducir el riesgo. No se inspecciona
porque exista un riesgo de falla, sino porque la inspección reduce ese riesgo en un grado
significativo. La piedra angular de API 581 es la "frecuencia de fallas genéricas" (gff), que es
aproximadamente la cantidad de elementos de equipos fallidos dividido por la cantidad total de
esos equipos en el mundo.
Una consecuencia inquietante del concepto de gff es que el riesgo nunca es cero. Incluso los
equipos libres de cualquier amenaza identificable que pueda mitigarse mediante una inspección
aún requerirían inspección.
Desafortunadamente, este tipo de equipos no son excepcionales, sino que, de hecho, son la
mayoría de los equipos.
Como resultado, API 581 prescribe grandes cantidades de trabajo de inspección que son ineficaces
o sin sentido, o ambas cosas. Dejando a un lado los aspectos de costo y capacidad, esta mala
orientación es potencialmente un gran problema porque causa tontería; Los sistemas sin sentido,
especialmente los sistemas basados en software, eliminan la experiencia y la vigilancia. Esto me
lleva al defecto fatal n°. 2: El factor de daño.
Para compensar la irracionalidad del ggf, el riesgo se ajusta mediante “factores de daño”. Un
factor de daño es algo monocausal: considera la presencia o ausencia de un elemento que
aumenta o mitiga el riesgo en el sistema y que aumenta o reduce el riesgo proporcionalmente.
Suena razonable, ¿eh? Sí, pero no lo es por dos razones. En primer lugar, todavía ignora el criterio
de reducción de riesgos para una inspección significativa; en segundo lugar, presupone amenazas
de causa única, que rara vez ocurren, por lo que contribuye al embrutecimiento del sistema.
En la gestión de la integridad, las amenazas son digitales. Existen o no existen. Media amenaza no
significa nada. A veces se requiere una verificación para establecer la presencia o ausencia de una
amenaza, a veces dos verificaciones. Un flujo incesante de datos de inspección aleatorios ignora
ciegamente que las amenazas a la integridad tienen una causa y una ubicación, que son conocidas
y, a menudo, controlables o mensurables.
A pesar de sus revisiones, API RP 581 sigue siendo un método tonto, que produce programas de
inspección ineficaces y mal orientados.