Mejora de la matriz de riesgo estándar: parte 11

Prof. Nancy Leveson

Departamento de Aeronáutica y Astronáutica
MIT
leveson@mit.edu

Resumen: La Parte 1 de este Libro Blanco describe la matriz de riesgo estándar y sus limitaciones. Luego sugiere algunos
cambios en la matriz de riesgos y su uso para mejorar la precisión de los resultados. La Parte 2 sugiere cambios más
importantes en términos de la definición básica y la evaluación del riesgo que pueden mejorar aún más nuestra capacidad
para evaluar el riesgo, pero también desafían nuestra voluntad de cambiar.

¿Qué es la matriz de riesgos y cómo se utiliza?

Una matriz de riesgos se usa comúnmente para la evaluación de riesgos para definir el nivel de riesgo para un sistema
o eventos específicos y para determinar si el riesgo está suficientemente controlado o no. La matriz casi siempre tiene dos
categorías para la evaluación: severidad y probabilidad (o probabilidad). La figura 1 muestra un ejemplo. Hay muchas
variantes, pero la mayoría son similares al ejemplo que se muestra en la Figura 1.

Figura 1: Una matriz de riesgo estándar de MIL-STD-882E.

La figura 1 se deriva del hecho de que la definición estándar de riesgo es la gravedad combinada con la
probabilidad: riesgo = f (gravedad, probabilidad).2 En muchos sentidos, definir el riesgo en términos de cómo se
cuantifica es lamentable. Ha obstaculizado el progreso al limitar el riesgo a una definición muy estrecha y al rechazar
alternativas y posibles mejoras por definición. Este libro blanco sugiere algunas definiciones alternativas y formas de
evaluar el riesgo. Un ejemplo simple de una alternativa es que el riesgo es la falta de

1© Nancy G. Leveson, febrero de 2019

2A veces, el riesgo se describe como la gravedad "multiplicada" por la probabilidad, pero, por supuesto, multiplicar dos tipos

diferentes de medidas tiene poco sentido matemáticamente.

1
certeza sobre un resultado, a menudo el resultado de tomar una decisión en particular o tomar una acción en particular. Más
sobre esto más adelante.

La matriz de riesgo clásica utiliza dos escalas de calificación ordinales: gravedad y probabilidad. Los problemas surgen al
definir la gravedad y la probabilidad. Si bien el riesgo a menudo se considera una cualidad cuantitativa, en la práctica
generalmente se define cualitativamente, es decir, en términos de escalas de calificación ordinales para la gravedad y la
probabilidad. El uso de escalas cualitativas solo puede dar una puntuación cualitativa que indique una categoría o casilla en la
que se encuentra el evento. Esta concepción no permite cálculos sofisticados ni diferencias sutiles.

Gravedad
Gravedad generalmente se define como un conjunto de categorías como:

Catastrófico: múltiples muertes

Crítico: una muerte o múltiples lesiones graves
Marginal: una lesión grave o múltiples lesiones menores
Despreciable: una herida menor

Por supuesto, estas categorías son subjetivas y las partes interesadas podrían definirlas de diferentes maneras. Por
ejemplo, ¿por qué una muerte no es catastrófica? ¿Qué es una "lesión grave"? Alternativamente, o además, las
pérdidas monetarias pueden estar asociadas con las categorías de gravedad, aunque eso plantea el dilema moral y
práctico de determinar el valor monetario de una vida humana.
La severidad es relativamente fácil de definir, aunque sigue existiendo el problema de si se considera el
peor de los casos, solo los resultados “creíbles”, el resultado más probable o solo los eventos comunes
predefinidos.
Utilizar el peor de los casos es el enfoque más inclusivo, pero pueden surgir preocupaciones de que es demasiado
pesimista y, en cambio, el peor creíble se debe utilizar el resultado. Esto último plantea el problema de cómo definir
"creíble" y puede llevar a difuminar la distinción entre gravedad y probabilidad, haciendo que estos dos factores no sean
verdaderamente independientes en la evaluación del riesgo.

Un tercer enfoque es utilizar el resultado más probable, que nuevamente mezcla gravedad y probabilidad y reduce su
independencia. En muchos casos, es posible que las personas no se den cuenta de que están haciendo esto y simplemente
asignen la gravedad de forma predeterminada de acuerdo con lo que pensaron que eran los resultados más probables. En
la certificación de aeronaves, SAE ARP 4761 tiene un ejemplo de una falla de freno de rueda al aterrizar a la que se le asigna
"ningún efecto de seguridad" si la falla de freno se anuncia a la tripulación de vuelo. Se asume que si los pilotos conocen la
falla, podrán detener la aeronave de manera segura, quizás, saliendo de la pista o calle de rodaje hacia el césped. Si bien
este es el resultado más probable, es fácil pensar en situaciones específicas en las que los pilotos no podrán prevenir un
accidente incluso si saben que los frenos han fallado.

Una última posibilidad, considerando solo fallas o eventos predeterminados específicos (llamado en la industria nuclear un evento de
base de diseño, como una rotura de tubería o, más generalmente, una pérdida de refrigerante) puede resultar en que la evaluación de
riesgos sea muy optimista y, a menudo, poco realista debido a que es demasiado limitada en lo que se considera.

Aún más problemática es la práctica común de evaluar el riesgo utilizando fallas en lugar de peligros. Es posible que la
gravedad de un solo fallo o incluso de varios no se pueda determinar fácilmente en un sistema complejo. ¿Cuál es la
gravedad de una "pérdida de información de encabezado" o la gravedad de un "error humano"? Depende de cómo se
utilice la información del rumbo y de las condiciones de otras partes del sistema y del medio ambiente en ese momento o
de los detalles específicos del error humano y las condiciones en las que se produjo. Utilizando la gravedad del peor de los
casos, se puede argumentar que casi todas las fallas son potencialmente catastróficas, aunque lo contrario (subestimar la
gravedad de las fallas) parece ser mucho más común.

2
 Otro problema importante es que la "falla del software" tiene poco sentido técnico. El software es una abstracción pura
sin ser físico. ¿Cómo falla una abstracción? Incluso definiendo la falla del software como el caso en el que el software no
satisface sus requisitos, generalmente hay una enorme cantidad de formas en que el software puede no satisfacer sus
requisitos y, por lo tanto, la gravedad de una "falla del software" es imposible de determinar o podría argumentarse
razonablemente. potencialmente siempre conduce a un resultado catastrófico en el peor de los casos. La evaluación del
riesgo en términos de peligros (discutidos más adelante) en lugar de fallas supera algunos de estos problemas, ya que los
peligros están, por definición, vinculados a tipos específicos de accidentes o pérdidas, que las partes interesadas pueden
identificar y priorizar.

Probabilidad
Surgen más problemas al definir probabilidad. Cuando se utiliza la matriz de riesgo para la predicción, el objetivo es
estimar la frecuencia con la que podría ocurrir un evento en el futuro. Esa información es difícil o imposible de determinar.
Si bien la probabilidad puede definirse utilizando eventos históricos, la mayoría de los sistemas actuales difieren
significativamente de los mismos sistemas en el pasado, por ejemplo, por un uso mucho más extenso de software o el uso
de nuevas tecnologías y diseños. De hecho, la razón habitual para crear un nuevo sistema es que los sistemas existentes ya
no son aceptables. Los datos históricos solo nos hablan del pasado, pero la matriz de riesgo se suele utilizar para predecir el
futuro. El hecho de que algo no haya ocurrido todavía no proporciona una predicción precisa sobre el futuro, especialmente
cuando el sistema o su entorno difieren del pasado. Y la mayoría de la gente no cree que la probabilidad de un "fallo" del
software (definido de alguna manera) pueda determinarse antes de un uso prolongado del software. Dada la experiencia
que hemos tenido con el software y otras consideraciones prácticas, algunos sugerirían sarcásticamente que la
probabilidad de un "fallo" del software es siempre "1". Y el software está en todo estos días.

Incluso si el diseño en sí no cambia en el futuro, la forma en que se usa el sistema o el entorno en el que se
usa casi siempre cambiará con el tiempo. El concepto de “migración hacia un mayor riesgo a lo largo del
tiempo” [Rasmussen 1997] se opone a la aplicabilidad del pasado como determinante para el futuro. Y estimar
los cambios futuros junto con sus impactos es esencialmente imposible.
La matriz de riesgo de ejemplo en la Figura 1 clasifica la probabilidad en términos de frecuentes, probables,
ocasionales, remotos, improbables y eliminados (o imposibles). Por lo general, estas categorías deben definirse con mayor
precisión, como un enfoque común en los sistemas militares:

Frecuente: probable que ocurra con frecuencia

Probable: Ocurrirá varias veces en la vida del sistema.

Ocasional: Es probable que ocurra en algún momento de la vida del sistema.

Remoto: Es poco probable que ocurra en la vida del sistema, pero es posible

Improbable: Extremadamente improbable que ocurra

Imposible: Igual a una probabilidad de cero

Como el lector puede ver fácilmente, estas definiciones no son muy útiles y simplemente reafirman el problema de una
forma diferente pero igualmente vaga. Esta misma crítica es válida para la mayoría de los intentos de definir categorías de
verosimilitud cualitativa.

A veces, las categorías cualitativas están asociadas con probabilidades. Un ejemplo podría ser el uso de
categorías.1.0E-9 y superior, entre 1.0E-6 a 1.0E-8 y 1.0E-5 y menor. Esta asignación probabilística, sin
embargo, no elimina la cuestión de si las probabilidades se pueden determinar de antemano (es decir,
antes de un uso operativo prolongado del sistema).

3
Uso de la matriz de riesgos
Una vez que se determinan las categorías, utilizar la matriz de riesgo implica asignar varios tipos de eventos a las
casillas apropiadas y así “evaluar” su riesgo. Los eventos generalmente involucran fallas, aunque también se pueden usar
condiciones o estados peligrosos.

Si el sistema aún no ha sido diseñado o está en proceso de desarrollo y prueba, la categoría de la matriz de
riesgo para los diferentes eventos puede usarse para determinar la cantidad y el tipo de esfuerzo a aplicar para
evitar que esos eventos ocurran. También se puede utilizar para evaluar el esfuerzo requerido con respecto a los
procesos de diseño estándar exigidos por el cliente (por ejemplo, nivel de rigor en el desarrollo). Por supuesto,
existen serias dudas sobre si el nivel general de rigor realmente da como resultado diferencias mensurables en el
riesgo. Esta conclusión comúnmente aceptada nunca ha sido probada y, al menos para el software, es casi seguro
que es incorrecta.
Al final del desarrollo, la evaluación de riesgos puede usarse para tomar decisiones sobre si el riesgo está
suficientemente controlado y para tomar decisiones sobre la certificación, implementación y uso operativo del
sistema.

¿Qué tan precisa es la matriz de riesgo estándar?

Mientras que el Análisis Probabilístico de Riesgos (PRA) estándar ha sido sometido a evaluación científica varias
veces, con resultados muy pobres cada vez [Lauridsen et.al. 2002, Leveson 1995], no tenemos conocimiento de ninguna
evaluación científica de la precisión, confiabilidad y capacidad predictiva de la propia matriz de riesgos. La evidencia de
precisión puede obtenerse del uso práctico de la matriz de riesgos o de las limitaciones técnicas generales identificadas
por los expertos. Cada uno de estos se analiza en esta sección.

Limitaciones prácticas en el uso de matrices de riesgo

Tenemos algunas pruebas anecdóticas de que nos hemos reunido en proyectos reales de defensa [Abrecht et.al. 2016,
Abrecht 2016] y en otras experiencias que tenemos en el uso de matrices de riesgo en la industria. El objetivo no es criticar
a los ingenieros en particular involucrados, simplemente estaban siguiendo las prácticas estándar de hoy. En cambio, el
objetivo es señalar las limitaciones prácticas de las matrices de riesgo tal como se definen y utilizan en la actualidad. La
autora ha encontrado las mismas fallas en los cientos de matrices de riesgo que ha visto durante su larga carrera en este
campo.

Un problema común es que a menudo los eventos evaluados son solo fallas de componentes, por ejemplo, pérdida de
comunicación externa o rotura de tuercas de pistón, y no los peligros más generales del sistema, como la inestabilidad de
la aeronave o la separación inadecuada del terreno. En la evaluación de riesgos para el helicóptero Black Hawk, por
ejemplo, una falla analizada fue "pérdida de información de estado de vuelo mostrada" [Sikorsky 2012] en lugar de los
peligros que esta pérdida podría generar, como acciones de control inseguras proporcionadas por la tripulación de vuelo o
pérdida de control. ¿Y qué ocurre con las fallas en las que los componentes del sistema satisfacen sus requisitos pero los
peligros surgen de las interacciones entre los componentes del sistema?

Otro problema al considerar solo las fallas en lugar de los peligros es que individual Por lo general, se consideran las fallas, pero
no las combinaciones de fallas de bajo rango. Por ejemplo, considere la situación en la que se produce un entorno visual degradado,
así como una pérdida de información de altitud, indicación de rumbo, indicación de velocidad aérea, información de salud de la
aeronave o comunicación interna. Individualmente, cada una de estas pérdidas puede no resultar en un accidente, particularmente
si se asume (como suele ser el caso) que los pilotos reaccionarán de manera apropiada. Sin embargo, cuando ocurren múltiples
pérdidas simultáneamente, la probabilidad de un accidente puede ser significativa. Examinar cada pérdida por separado en la
matriz de riesgos puede conducir a una evaluación de riesgo del sistema baja debido a una baja probabilidad de ocurrencia y un
bajo nivel de gravedad de cada una de las fallas individuales (de un solo punto). También existe, por supuesto, por lo general una
suposición de independencia del

4
fallas y, a menudo, una falta de consideración de los modos de falla comunes. No es sorprendente que tales fallas
de combinación no se consideren dada la gran cantidad de fallas posibles en cualquier sistema realista; evaluar
todas las combinaciones se vuelve prohibitivamente costoso y generalmente inviable. Sin embargo, no
considerar combinaciones de fallas afecta la precisión de los resultados.
Hay otros problemas prácticos serios más allá de los descritos hasta ahora que ocurren en la estimación de la severidad y
probabilidad de fallas. Una complicación común es que se puede suponer que la tripulación de vuelo no solo reconocerá la falla (o
peligro) sino que también responderá de manera apropiada. Irónicamente, los accidentes a menudo se atribuyen al
comportamiento inadecuado de la tripulación de vuelo o del operador y, al mismo tiempo, se supone que se comportarán
correctamente en la evaluación de riesgos. Claramente, hay muchos casos en los que esta suposición no se mantendrá. El modelo
mental del operador del sistema (un componente general deconciencia de la situación) juega un papel importante en los
accidentes. En las aeronaves, por ejemplo, la tripulación de vuelo debe recibir, procesar y actuar sobre numerosas fuentes de
retroalimentación sobre el estado de la aeronave para interactuar de manera correcta y segura con los diversos vehículos y
sistemas de misión. El tiempo para realizar esta toma de decisiones puede ser muy limitado. La interacción de las pantallas del
modo de control, el pedal y otras posiciones de control, los ajustes de referencia para varios modos de funcionamiento y otra
retroalimentación visual y propioceptiva pueden provocar confusión en el modo de vuelo de la tripulación y un accidente,
particularmente cuando la retroalimentación visual externa se degrada. Omitir estas interacciones y asumir que la tripulación
siempre hará (y puede) hacer lo correcto puede conducir a evaluaciones de riesgo muy inexactas.

Pero los problemas no están solo en suposiciones poco realistas sobre el comportamiento humano. A menudo existen
suposiciones poco realistas similares para el hardware y el software. A modo de ejemplo, en la evaluación oficial de riesgos del Black
Hawk, la falla “pérdida de la información del estado de vuelo mostrada” se identificó como catastrófica en severidad pero
improbable en probabilidad. Las únicas mitigaciones consideradas fueron la redundancia de hardware y el alto nivel de rigor en el
desarrollo de software. Sin embargo, tenga en cuenta que la redundancia no evita errores de diseño de hardware, solo fallas de
"desgaste" aleatorias. Además, el software es un diseño puro y, por lo tanto, no se desgasta, por lo que la redundancia no es útil
para el software.

¿Qué pasa con el "rigor de desarrollo"? Casi todos los accidentes relacionados con el software se deben a requisitos
defectuosos, que a menudo implican omisiones, y no a una implementación de software o prácticas de garantía
defectuosas. El nivel de rigor en el desarrollo del software no tendrá ningún impacto en la integridad y precisión de los
requisitos del software; estas son responsabilidades de ingeniería del sistema. Una de las razones por las que la mayoría
de los accidentes relacionados con el software surgen de requisitos defectuosos es que el desarrollo de requisitos de
software es un proceso tan difícil y potencialmente defectuoso. El rigor del desarrollo de software no ayudará aquí.

La evaluación oficial de riesgos de Black Hawk utilizó estas suposiciones para identificar como probabilidad relativamente baja
una pérdida de información de actitud, pérdida de indicación de rumbo, pérdida de información de salud de la aeronave, pérdida de
comunicaciones externas y pérdida de comunicaciones internas. Sin embargo, tenga en cuenta que algunas de estas pérdidas han
estado implicadas en accidentes de Black Hawk. Como ejemplo, el accidente de fuego amigo de 1994 involucró una pérdida de
comunicación entre la tripulación del Black Hawk, los controladores de AWACS y los pilotos del F15 involucrados. Este conjunto de
condiciones no se incluyó en la matriz de riesgo oficial de Black Hawk, pero se incluyó en el análisis de peligros de STPA porque el
análisis de STPA examinó escenarios de no falla y no asumió un comportamiento perfecto por parte de las tripulaciones de vuelo.

Parece que los eventos sólo pueden parecer improbables si no se consideran algunos de los posibles factores
involucrados, como fallas en los requisitos de software y aspectos del comportamiento humano. El análisis de Black Hawk
STPA encontró muchos escenarios sin falla (además del ejemplo anterior) que pueden conducir a un estado peligroso del
sistema, pero no se consideraron en absoluto en la evaluación oficial de riesgos. También identificó escenarios realistas en
los que la tripulación de vuelo no se comportaría adecuadamente y sugirió controles adicionales para evitar el
comportamiento inseguro, así como requisitos de seguridad importantes para el software. Finalmente, y quizás lo más
perturbador, STPA identificó escenarios realistas y relativamente probables que conducen a todos

5
las fallas específicas descartadas como improbables en la evaluación oficial de riesgos. La omisión de este tipo de
escenarios conducirá a una evaluación de riesgos muy inexacta.

Se identificaron limitaciones similares en la evaluación oficial de riesgos en el sistema de

posicionamiento intensivo en software para un nuevo buque de guerra [Abrecht 2016]. Sin embargo,
existían limitaciones de evaluación de riesgos adicionales en este sistema. Por ejemplo, la probabilidad
de una pérdida puede diferir significativamente según el entorno externo en el que se produce una falla.
Pero ese factor generalmente no se considera en la matriz de riesgo. Además, la probabilidad y la
severidad pueden estar tan entrelazadas (por ejemplo, a través del entorno externo) que nuevamente
no pueden evaluarse en dimensiones separadas e independientes. Utilizando los resultados de la
evaluación oficial de riesgos e ignorando el análisis de la STPA, se puso en funcionamiento este buque
de guerra. En dos meses, chocó con un submarino nuclear, produciendo grandes daños.

Limitaciones técnicas:
La precisión bastante deprimente en el uso de la matriz de riesgo actual se debe a limitaciones técnicas. El objetivo de
este documento técnico no es entrar en detalles sobre las limitaciones matemáticas y de otro tipo, pero se pueden resumir
de la siguiente manera:

• La falta de granularidad en la matriz de riesgos hace que solo sea adecuada para clasificar eventos en lugar de
proporcionar la información necesaria para tomar decisiones sobre el control del riesgo de eventos específicos.

• Las dos escalas ordinales hacen imposible realizar cálculos sofisticados con las entradas. La matriz
de riesgo solo puede indicar en qué categoría falla un evento.
• ¿Qué sucede con los eventos que son potencialmente catastróficos pero tienen una frecuencia estimada muy baja?
Tienden a salirse de la escala y a recibir menos atención de la que merecen, especialmente dada la inexactitud de la
mayoría de las estimaciones de probabilidad.
• Como se mencionó, el pasado es una estimación pobre del futuro, particularmente porque la forma en que se utilizan los
sistemas y el entorno en el que se utilizan cambiará con el tiempo. Por lo tanto, no es posible realizar una predicción
precisa sobre el comportamiento operativo utilizando una matriz de riesgos.
• La mala resolución resulta de categorías cualitativas que están mal definidas y subjetivas y pueden llevar a
asignar calificaciones idénticas a lo que son eventos cuantitativamente muy diferentes.
• Para los riesgos con frecuencias y severidades correlacionadas negativamente, las matrices de riesgo pueden ser "peores que
inútiles", lo que lleva a decisiones peores que las aleatorias [Cox 2008].

• Las categorizaciones de gravedad no se pueden hacer objetivamente para consecuencias inciertas. En estos casos, un
análisis del peor de los casos conduce a una alta gravedad para cada evento. Al mismo tiempo, la evaluación de casos
esperada puede ser muy optimista.
• Las interpretaciones subjetivas de las categorizaciones de severidad y probabilidad (particularmente probabilidad)
pueden llevar a categorizaciones muy diferentes de los eventos por diferentes usuarios.
• Los críticos han demostrado que las matrices de riesgo producen clasificaciones de riesgo arbitrarias porque
dependen del diseño de la matriz en sí, como el tamaño de los contenedores y si se usa una escala creciente o
decreciente. Cambiar la escala puede cambiar la respuesta. Los errores en las predicciones de los expertos se
ven agravados por los errores adicionales introducidos por las escalas y matrices.
• La probabilidad puede, y a menudo lo hace, ignorar o descartar ciertos tipos de factores causales, como errores del
operador, decisiones de administración y, a veces, el comportamiento del software. Las fallas aleatorias de hardware
generalmente se enfatizan demasiado.

Algunas de las limitaciones más interesantes provienen de lo que Kahneman y Tversky llaman sesgos
heurísticos [Kahneman y Tversky 1973; Kahnemann, Slovic y Tversky 1982.]. Kahneman y Tversky son

6
psicólogos que estudiaron cómo la gente realiza realmente la evaluación de riesgos. Resulta que los seres humanos son
realmente terribles para estimar el riesgo, en particular la probabilidad. Estos son algunos de los sesgos heurísticos relevantes
que se han descrito:

• Sesgo de confirmación: Las personas tienden a prestar más atención a la información que respalda sus puntos de vista que a la
evidencia que entra en conflicto con ellos. El resultado es que las personas tienden a negar la incertidumbre y la vulnerabilidad y
sobrevaloran las estimaciones que se ajustan a sus experiencias o puntos de vista anteriores.

• Disponibilidad heurística: Las personas tienden a basar los juicios de probabilidad de un evento en la facilidad con
la que se pueden recordar casos o eventos similares. Si bien esta heurística a menudo puede ser razonable de
usar, también puede conducir a un sesgo sistemático. Por ejemplo, los psicólogos han descubierto que los juicios
de riesgo de diversos peligros o eventos tenderán a estar correlacionados con la frecuencia con la que se
mencionan en los medios de comunicación.
• Facilidad de generación de escenarios: Las personas a menudo construirán sus propios escenarios causales
simples de cómo podría ocurrir el evento, utilizando la dificultad de producir razones para la ocurrencia de un
evento como un indicador de la probabilidad del evento. Si no se le ocurre fácilmente una causa o escenario
plausible, se puede suponer que el evento es imposible o altamente improbable.
• Dificultad para predecir causas acumulativas: Las personas tienden a identificar eventos simples y dramáticos en lugar de
causas que son crónicas o acumulativas. Los cambios dramáticos reciben una probabilidad o probabilidad relativamente
alta, mientras que un cambio resultante de un cambio lento en las actitudes sociales, por ejemplo, es más difícil de
imaginar y, por lo tanto, tiene una probabilidad menor.
• Falacia de conjunción: Un resultado emparejado con una causa probable a menudo se considera más
probable que el resultado solo, aunque esta conclusión viola las leyes de la probabilidad.
• Búsqueda incompleta de posibles causas: A menudo, una búsqueda se detiene una vez que se ha
identificado una posible causa o explicación de un evento. Si esa primera causa posible no es muy
convincente, detener la búsqueda en ese punto conduce a la no identificación o subestimación del riesgo
de otras causas más plausibles y convincentes.
• Evitación defensiva: Rechazo o degradación de las categorizaciones de riesgo que entran en conflicto con otros objetivos
urgentes. El autor se ha sentado en reuniones y ha observado a los gerentes reorganizar sistemáticamente los riesgos en
categorías inferiores debido a presiones presupuestarias y de programación que tienen poco que ver con el riesgo real
que se está evaluando. El deseo de una categorización más baja del riesgo puede superar y suprimir la objetividad.

Una forma de superar estos sesgos es proporcionar a los responsables de la creación de la matriz mejor
información sobre los escenarios que pueden conducir al evento de pérdida, quizás a través de un proceso
estructurado como STPA para generar los escenarios. Otra es cambiar la propia matriz de riesgos para reflejar una
definición de riesgo más general y práctica. Ambos posibles caminos a seguir se analizan en la siguiente sección.

Posibles alternativas a la matriz de riesgo estándar

Como se sugirió, hay dos formas posibles de mejorar la matriz de riesgo estándar: (1) usar peligros en lugar de
fallas y mejor información sobre posibles escenarios causales para mejorar las estimaciones de severidad y
probabilidad, y (2) cambiar la definición básica de riesgo y por lo tanto su evaluación. El segundo tema se trata en la
Parte 2 de este documento técnico.

La primera alternativa requiere la menor cantidad de cambios a lo que se hace hoy, es decir, usar la matriz de riesgo básica tal
como existe pero cambiar la forma en que se derivan las entradas.

7
Utilice peligros en lugar de fallas
Parte de la inexactitud en las evaluaciones de gravedad de la matriz de riesgos se debe al hecho de que la relación entre fallas
individuales y accidentes (pérdidas) puede no ser obvia y puede requerir mucho trabajo para determinarla. Asignar gravedad y
probabilidad a los peligros en lugar de a las fallas proporciona un camino más directo hacia el objetivo final de la matriz de riesgos,
que es evaluar el riesgo de pérdidas, no la falta de confiabilidad de los componentes o incluso del sistema. La confiabilidad de los
componentes o del sistema no es equivalente a la seguridad del sistema, aunque existen superposiciones. De hecho, en muchos
casos, la confiabilidad del sistema puede entrar en conflicto con la seguridad del sistema, es decir, aumentar una puede disminuir
la otra.

Tradicionalmente, en la ingeniería de seguridad de sistemas, la seguridad se define en términos de peligros, no

fallas. La priorización de la gravedad del peligro comienza con la gravedad evaluada de la pérdida (accidente) por
parte de las partes interesadas y luego los peligros se asocian con las pérdidas priorizadas. Este proceso es más
fácil y sencillo que comenzar intentando priorizar la gravedad de las fallas del sistema o de los componentes
rastreando hasta los accidentes: por lo general, hay una enorme cantidad de fallas potenciales en un sistema
complejo y las consecuencias no siempre son claras. Y, por supuesto, se omitirán de consideración los peligros que
resulten de errores de diseño u otros aspectos del sistema que no involucren fallas.
Como ejemplo de lo último, considere la función de descongelación de helicópteros. El SAR final (Informe de evaluación de
seguridad) [Sikorsky 2012] sobre una actualización de Black Hawk incluyó una falla en la APU de la aeronave como resultado de un
roce de la APU. Esta falla es importante porque la APU se usa cuando se produce la pérdida de un generador durante las
operaciones de descongelación de las palas. Mientras APU se burlalata evitar que la función de descongelamiento funcione, hay
otro escenario encontrado al usar STPA que podría prevenir la función de descongelamiento de la cuchilla cuando la APU ha no ha
fallado. Considere la siguiente acción de control insegura:

UCA: La tripulación de vuelo no enciende la energía del generador APU (Unidad de energía auxiliar) cuando GEN1 o GEN23 no
están suministrando energía al helicóptero y se requiere el sistema de descongelación de las palas para evitar la formación de
hielo.

Hay varios escenarios y factores causales que podrían conducir a este control inseguro más allá de la fricción de la APU o incluso la
falla de un componente [Abrecht et. Alabama. 2016]. Estos no están incluidos en el SAR oficial de Blackhawk, pero deben tenerse en
cuenta en cualquier evaluación de riesgos y usarse para desarrollar requisitos operativos, de prueba y de diseño. Los nuevos
escenarios para el UCA anteriores podrían llevar a requerir que los diseñadores de software y hardware asignen una mayor
criticidad al hardware y software que se utiliza para generar y mostrar advertencias específicas a la tripulación y para mejorar el
diseño del papel que desempeña la tripulación de vuelo durante las operaciones. . Considerar solo las fallas como la causa de los
peligros y accidentes distorsiona severamente la evaluación de riesgos y es probable que los resultados sean muy inexactos para los
sistemas cada vez más complejos de la actualidad.

El cambio que se sugiere aquí, entonces, es comenzar a partir de una lista priorizada de accidentes o pérdidas del
sistema identificados por las partes interesadas. Luego, se identifican los peligros del sistema de alto nivel (condiciones o
estados) que pueden conducir a estos accidentes. Este proceso es consistente con MIL-STD-882 (en todas sus
encarnaciones) y muchos otros estándares de seguridad. Luego se evalúa la gravedad y probabilidad de los peligros. Solo se
deben considerar las fallas que pueden conducir a peligros (que pueden ser identificadas por STPA), no todas las fallas.
Además, los peligros que resultan de escenarios causales que incluyen no fallas (por ejemplo, errores de diseño) deben
incluirse en la evaluación. Estos escenarios más generales pueden derivarse de STPA u otros métodos de análisis con
resultados similares.

Definir la probabilidad como la fuerza de los controles potenciales

Partir de los peligros hace que la evaluación de la gravedad sea sencilla, ya que los peligros se pueden vincular directamente a
la lista priorizada de accidentes o pérdidas de las partes interesadas. Eso deja la evaluación de probabilidad como

3 Generadores de APU redundantes

8
el obstáculo restante para una evaluación de riesgos más precisa utilizando la matriz de riesgos estándar. Los sesgos heurísticos
descritos anteriormente explican por qué las personas suelen hacer un mal trabajo en la evaluación del riesgo. Los sesgos surgen
porque los procesos informales, es decir, la heurística, se utilizan para estimar el riesgo, en particular la probabilidad. Una forma de
superar tales sesgos es exigir seguir un proceso detallado para identificar los escenarios y no permitir detenerse antes de
considerarlos por completo en la evaluación de riesgos. Por supuesto, no se puede asegurar la integridad en ningún proceso no
matemático, pero seguir un proceso riguroso dará como resultado la reducción de atajos y sesgos y una consideración más
completa de los posibles escenarios causales.

Un problema al evaluar la probabilidad es que hay poca información real disponible sobre el futuro, especialmente al comienzo del proceso de

desarrollo, cuando se toman decisiones sobre dónde concentrar los esfuerzos. Sin tener el diseño final detallado del sistema, no es posible determinar la

probabilidad de que ocurra un accidente. Incluso más tarde, hay problemas para evaluar la probabilidad de software o comportamiento humano

inseguro. Una razón por la que las fallas de los componentes pueden ser el foco de las actividades actuales de evaluación de riesgos es que

generalmente existe información histórica sobre las fallas de los componentes estándar, aunque eso no garantiza que los nuevos diseños tengan las

mismas probabilidades de fallas. Resolver el problema equivocado porque sabemos que la solución es como el viejo chiste sobre un hombre que se

encuentra con un borracho que se arrastra por una acera debajo de una farola en busca de su billetera perdida. El hombre se ofrece a ayudar y pregunta

dónde perdió la billetera el borracho. El borracho señala al otro lado de la calle. Cuando el hombre le pregunta por qué está mirando en un lugar

diferente de donde dejó caer la billetera, el borracho explica que la luz es mejor aquí. Necesitamos obtener mejores evaluaciones de riesgos

centrándonos en el problema real en lugar de en uno diferente que sepamos resolver. el borracho explica que la luz es mejor aquí. Necesitamos obtener

mejores evaluaciones de riesgos centrándonos en el problema real en lugar de en uno diferente que sepamos resolver. el borracho explica que la luz es

mejor aquí. Necesitamos obtener mejores evaluaciones de riesgos centrándonos en el problema real en lugar de en uno diferente que sepamos resolver.

Los escenarios generados por STPA pueden potencialmente proporcionar mejor información sobre la cual
evaluar la probabilidad de que ocurran peligros. ¿Qué tipo de información se creará? Considere el siguiente ejemplo
del análisis STPA de Black Hawk nuevamente. Una acción de control insegura (UCA) es que:
UCA: La tripulación de vuelo no desvía los pedales lo suficiente para contrarrestar el par del rotor principal, lo
que hace que la tripulación de vuelo pierda el control de la aeronave y entre en contacto con un obstáculo en
el entorno o el terreno.
Uno de los escenarios causales que podría conducir a esta acción de control insegura podría ser:

Escenario 1: La tripulación de vuelo no sabe que los pedales no se han desviado lo suficiente para contrarrestar el par
del rotor principal. La tripulación de vuelo podría tener este modelo de proceso defectuoso porque:
a) Los instrumentos de vuelo funcionan mal y proporcionan información incorrecta o insuficiente a la tripulación
sobre el estado de la aeronave durante condiciones visuales degradadas.
b) Los instrumentos de vuelo funcionan según lo previsto, pero no brindan información suficiente a la tripulación para
aplicar las entradas de pedal adecuadas para controlar el rumbo de la aeronave y evitar obstáculos durante condiciones
visuales degradadas.

c) La Tripulación de Vuelo tiene un modelo mental incorrecto de cómo el FCS ejecutará sus entradas de
control para controlar la aeronave y cómo responderá el motor a las condiciones ambientales.
d) La tripulación de vuelo está confundida acerca del modo actual de automatización de la aeronave y, por lo
tanto, desconoce las leyes de control reales que rigen la aeronave en este momento.
e) Hay retroalimentación de control incorrecta o insuficiente.

Cada uno de estos factores causales se puede utilizar para crear requisitos y características de diseño para reducir su
probabilidad y, por lo tanto, la probabilidad del UCA y el peligro. El impacto clave en la evaluación de riesgos es que la
probabilidad puede basarse en la solidez de los controles potenciales. El factor (a) anterior podría controlarse mediante
redundancia y diseño tolerante a fallas. Factor (b) por diseño de interfaz (evaluado por un experto en factores humanos). El
factor (c) también se verá afectado por el diseño de la interfaz y también por la capacitación. Factores
(d) y (e) pueden controlarse mediante el diseño del sistema, tanto el hardware como el software y sus interacciones,

9
ya través del diseño de retroalimentación. Todavía necesitamos una forma de vincular estos factores con la probabilidad. A continuación se

sugieren algunos.

El ejemplo mostrado hasta ahora se centra en la interacción de la tripulación de vuelo y los controles de la aeronave. El diseño
del software y hardware, por supuesto, también debe incluirse en la evaluación de riesgos. Los enfoques actuales para el manejo de
software, como la asignación de niveles de rigor al desarrollo de software, no tienen una base técnica o científica como se
mencionó anteriormente. Asumir simplemente que el riesgo relacionado con el software se reduce o elimina adecuadamente
mediante un desarrollo riguroso no es realista y no refleja ningún resultado de investigación ni experiencia real en ingeniería.
Utilizando el enfoque de la evaluación de riesgos que se describe aquí, la evaluación de riesgos relacionada con el software se
puede manejar de la misma manera que el hardware y las personas.

Considere el siguiente ejemplo de un UCA identificado por STPA para Black Hawk:
UCA: Una o más de las FCC (computadoras de control de vuelo) ordenan la entrada colectiva a los servos hidráulicos por
demasiado tiempo, lo que resulta en una condición de RPM del rotor no deseada y potencialmente conduce al peligro
de violar la separación mínima del terreno o al peligro de perder el control de la aeronave.
Hay al menos cinco escenarios causales que podrían conducir a esta acción de control insegura:

Escenario 1: Las FCC desconocen que se ha alcanzado el estado deseado y continúan suministrando información
colectiva. Las FCC podrían tener este modelo de proceso defectuoso porque:

a) Los FCC no están recibiendo información de posición precisa de los servos del rotor principal.

b) Las FCC no están recibiendo información de las UCI para dejar de suministrar la entrada del plato cíclico.

Escenario 2: Las FCC no envían la respuesta adecuada a la aeronave para entradas de control particulares.
Esto podría suceder si:
a) La lógica de control no sigue las pautas intuitivas que se han implementado en aeronaves
anteriores, quizás porque los requisitos para hacerlo no se incluyeron en la especificación de
requisitos del software.
b) El hardware en el que se implementan las FCC ha fallado o está funcionando en un estado
degradado.
Escenario 3: Las FCC no brindan retroalimentación a los pilotos para que dejen de ordenar el aumento colectivo cuando sea
necesario porque el FADEC (controlador del motor) está proporcionando señales incorrectas a las FCC con respecto a las
condiciones del motor.

Escenario 4: Las FCC no brindan retroalimentación a los pilotos para que dejen de ordenar el aumento colectivo cuando
sea necesario porque las FCC están recibiendo información inexacta del sensor NR (rpm del rotor) del rotor principal.

Escenario 5: Las FCC proporcionan indicaciones táctiles incorrectas a las UCI (unidades de control de inceptor) para colocar
correctamente el colectivo para evitar condiciones de RPM bajas del rotor.

Si bien estos escenarios generados por STPA generalmente se usarían para identificar los requisitos apropiados de la FCC y las
restricciones de diseño, la información también podría incorporarse a una evaluación de riesgos. Por ejemplo, se podrían identificar
tres requisitos de seguridad relacionados con el escenario 1:

1. Las FCC deben realizar pruebas medias para determinar si la retroalimentación recibida de los servos del rotor
principal es inexacta.
2. La advertencia PR SVO FAULT debe presentarse a la tripulación de vuelo si los FCC pierden la comunicación con
un servo del rotor principal.
3. El EICAS debe alertar a la tripulación de vuelo si las FCC no reciben información de la UCI cada x segundos.
El riesgo del peligro relacionado con la UCA se reducirá mediante la implementación de estos requisitos y aumentará si
estos u otros controles para reducir la ocurrencia de la UCA no se incluyen en el diseño. No es posible simplemente
asignar una probabilidad a "falla de la FCC" o incluso a un "comportamiento peligroso de la FCC". Utilizando

10
la fuerza de los controles potenciales ayudaría. En el nivel más simple, esta evaluación podría implicar diferenciar entre
controles que eliminan el peligro o solo tratar de detectarlo y mitigarlo. Tenga en cuenta que STPA se puede realizar al
principio del desarrollo y que la información se puede utilizar para tener un impacto en el proceso de desarrollo. Por
ejemplo, las limitaciones de seguridad identificadas podrían estar sujetas a actividades de garantía más amplias.

Traducir la fuerza de los controles en probabilidad

El problema sigue siendo asociar la probabilidad con la fuerza de los controles potenciales. En el desarrollo del concepto
de sistema y en las decisiones tempranas sobre el proceso de desarrollo (por ejemplo, dónde invertir recursos), se utilizaría
una estimación de la fuerza potencial de los controles diseñados para los escenarios generados por STPA para evaluar la
probabilidad. A medida que se toman las decisiones de diseño básicas, se realizan las pruebas y se refina el análisis STPA, se
pueden mejorar las evaluaciones de probabilidad. Al final, el riesgo asociado con el sistema durante las operaciones será
posible evaluar con mucha mayor precisión de lo que es posible actualmente.

Se pueden utilizar varias estrategias para clasificar la fuerza de los controles potenciales. Una clasificación posible
(donde 1 es la más alta) es:

1: El factor causal puede ser eliminadoa través del diseño y alta seguridad.
2: La aparición del factor causal se puede reducir o controlar mediante el diseño del sistema.
3: El factor causal puede detectarse y mitigarse si ocurre a través del diseño del sistema o
a través de procedimientos operativos

4: Los únicos controles potenciales involucran capacitación y procedimientos.

Este ejemplo de sistema de clasificación es quizás demasiado simple. Un procedimiento un poco más sofisticado podría
involucrar estimaciones de qué tan bien se ha manejado el factor causal dentro de cada una de las cuatro categorías, por
ejemplo, qué tan a fondo se podría mitigar el factor causal. Este procedimiento puede mejorar los resultados sobre la
simple asignación de un único número potencial (por ejemplo, 1-4) para cada categoría. Para las fallas de hardware críticas
identificadas, el impacto potencial de la redundancia u otras técnicas de reducción o manejo de fallas en la probabilidad se
puede calcular matemáticamente. Pero estos son un subconjunto de todos los factores causales que STPA puede
identificar. Es posible que otros tipos de técnicas de mejora de la seguridad no se evalúen tan fácilmente y requieran
"juicio técnico".

Además, las combinaciones de estos cuatro tipos de control (enumerados anteriormente) podrían usarse en estimaciones de
probabilidad, por ejemplo, se incluyen características de diseño para reducir o controlar el factor, así como capacitación y procedimientos
del operador como respaldo en caso de que el peligro aún ocurra. Una combinación de controles podría conducir a una reducción de la
probabilidad evaluada. También son posibles otras estrategias de clasificación o asignaciones a niveles de riesgo.

Aquí se asume, por supuesto, que estas estrategias de control afectarán la probabilidad de que ocurra el peligro
o el UCA. Pero esta suposición es mejor que la habitual de que las tasas históricas de fallas de hardware se
aplicarán en el futuro (sin importar los cambios en el sistema en sí o en el entorno durante las operaciones)
combinado con (1) omitir todos los factores que no involucran al hardware fallas de componentes o (2) hacer que
las probabilidades de estos factores surjan de la nada.
Se pueden desarrollar procesos de evaluación de riesgos especializados que sean apropiados para tipos específicos de
sistemas. El capítulo 10 de Diseñar un mundo más seguro (páginas 321 a 327) describe dos de estos enfoques especiales que
hemos ideado para proyectos anteriores. El primero fue para un contrato de la NASA para crear y analizar compensaciones
arquitectónicas para futuras misiones de exploración espacial tripuladas. Los ingenieros del sistema querían incluir una
evaluación de seguridad de las posibles arquitecturas junto con los factores habituales, como la masa, que se utilizan para evaluar
las arquitecturas candidatas. Había poca información disponible en esta etapa temprana de la ingeniería de sistemas y, por
supuesto, la información histórica sobre los esfuerzos de exploración espacial pasados no estaba disponible.

11
útil porque todas las arquitecturas potenciales involucraban nueva tecnología y nuevas emisiones, que invalidaron la
experiencia pasada e incluso crearon nuevos peligros, como el uso de energía nuclear para impulsar las naves espaciales
y los rovers de superficie.

El proceso ideado para evaluar el riesgo de este estudio de comercio de arquitectura fue el siguiente. Se identificaron
peligros que eran específicos de cada fase de la misión (por ejemplo, lanzamiento o aterrizaje) junto con algunos peligros
generales, como incendio, explosión o pérdida del soporte vital que abarcaban todas o la mayoría de las etapas de la
misión. Una vez que se identificaron los peligros, se evaluó el impacto de la pérdida del peor de los casos asociada con el
peligro en tres categorías: Humanos, Misión y Equipo. El medio ambiente (incluido el daño a la Tierra y a la superficie del
planeta) se incluyó originalmente, pero luego se eliminó cuando los gerentes de proyecto decidieron que todas las
misiones deben cumplir con los estándares de protección planetaria de la NASA y no pueden ser parte de un análisis de
compensación. Otros proyectos pueden querer incluir el impacto ambiental en el análisis de riesgos.

Se creó una escala de gravedad para cada una de las tres categorías. Sin embargo, como de costumbre, la gravedad fue
más fácil de manejar que la probabilidad. En este caso, las arquitecturas y misiones involucrarían cosas que nunca se
habían intentado antes y los datos históricos no eran relevantes. En cambio, el potencial de mitigación sustituyó a la
probabilidad como en el ejemplo anterior, pero de una manera más sofisticada. La mitigabilidad fue evaluada por expertos
en el dominio bajo la guía de expertos en seguridad. Se evaluó tanto el costo / dificultad de la estrategia de mitigación
potencial (en términos cualitativos de bajo, medio, alto) como su efectividad potencial (en una escala comparativa de 1 a 4).
Debido a que los ingenieros de sistemas generaron cientos de arquitecturas factibles, el proceso de evaluación se
automatizó y se utilizaron promedios ponderados para combinar factores de mitigación y factores de gravedad para llegar
a una métrica final de riesgo de seguridad residual global. Esta métrica se utilizó luego en la evaluación y clasificación de
las posibles arquitecturas de exploración espacial tripuladas. Puede encontrar un ejemplo detallado enDiseñando un
mundo de seguridad.
Un segundo ejemplo es un esquema que se nos ocurrió para evaluar el riesgo en un proyecto de la NASA de uso intensivo de
humanos que involucra mejoras en el Control de tráfico aéreo (ATC). Este caso fue casi exactamente lo opuesto al del diseño de la
misión espacial tripulada en el sentido de que el problema de la ingeniería del sistema no es crear un sistema nuevo o más seguro,
sino mantener el ya alto nivel de seguridad integrado en el sistema actual. Básicamente, el objetivo es no degradar la seguridad del
sistema actual cuando se le realizan cambios. Luego, el análisis de riesgos tiene como objetivo evaluar el riesgo de que la seguridad
se vea afectada.degradado por los cambios propuestos y nuevas herramientas automatizadas. En este caso, creamos un conjunto
de criterios para clasificar varias características de diseño arquitectónico de alto nivel del conjunto propuesto de nuevas
herramientas ATC en una variedad de factores relacionados con el riesgo del sistema. Una vez más, la clasificación fue cualitativa y la
mayoría de los criterios se clasificaron como de impacto alto, medio o bajo en el potencial de degradación de la seguridad desde el
nivel muy alto actual.

Muchos de los criterios elegidos involucraban la interacción humano-automatización debido a la naturaleza de la aplicación y al
hecho de que las nuevas características que se proponían involucraban principalmente una nueva automatización para ayudar a los
controladores de tránsito aéreo. Los criterios de ejemplo incluyen:

• Márgenes de seguridad: ¿Tiene la nueva característica el potencial de (1) un cambio insignificante o nulo en los
márgenes de seguridad existentes, (2) un cambio menor o (3) un cambio significativo.
• Conciencia de la situación: ¿Cuál es el potencial para reducir la conciencia de la situación?
• Habilidades que se utilizan actualmente y las necesarias para respaldar y monitorear las nuevas herramientas de apoyo a la toma de decisiones:

¿Hay un cambio insignificante o nulo en las habilidades del controlador, un cambio menor o un cambio significativo?

• Introducción de nuevos modos de falla y causas de peligro: ¿Tienen las nuevas herramientas la misma función y
modos de falla que los componentes del sistema que están reemplazando? ¿Se introducen nuevos modos de
falla y peligros, pero se pueden diseñar medidas de mitigación efectivas y bien entendidas? o son los nuevos
modos de falla y las causas de peligro difíciles de controlar.

12
 • Efecto de las nuevas funciones del software en las medidas de mitigación de peligros del sistema actual: ¿Pueden las nuevas
características hacer que las medidas de seguridad actuales sean ineficaces o no están relacionadas con las características de
seguridad actuales?
• Necesidad de nuevas medidas de mitigación de peligros en el sistema: ¿Los cambios propuestos requerirán nuevas
medidas de mitigación de peligros?

Estos y otros criterios se convirtieron en un esquema numérico para que pudieran combinarse y usarse en
una evaluación de riesgo temprana de los cambios contemplados y su probabilidad potencial de introducir
nuevos riesgos significativos en el sistema. Los criterios se ponderaron para reflejar su importancia relativa en el
análisis de riesgos.
Tanto para estos ejemplos especializados como para otros que podrían idearse, el uso de STPA para identificar
escenarios causales ayudará a proporcionar mejores valores para los criterios. El punto es que pensar en lo que significa el
riesgo en su proyecto particular puede ayudar a identificar mejores formas de evaluarlo, particularmente el componente de
probabilidad.

Hasta ahora en este documento y, a menudo, en la práctica, la atención se centra principalmente en el riesgo que implica el diseño del sistema de ingeniería en la

implementación del sistema. El riesgo se verá afectado por muchos otros factores durante la fabricación y las operaciones, como los controles de fabricación, la mantenibilidad del

diseño y la aparición de errores de mantenimiento, los programas de formación, los cambios a lo largo del tiempo en el entorno en el que se utiliza el sistema, la coherencia y el

rigor de la gestión y la supervisión. por aquellos encargados de supervisar el funcionamiento del sistema, etc. El riesgo de los sistemas desplegados se basa en suposiciones sobre el

entorno operativo por parte de los diseñadores del sistema. Cuán realistas y precisas sean esas suposiciones, cuán bien se comuniquen esas suposiciones a los usuarios y cuán

rigurosamente se apliquen las suposiciones operativas tendrá un gran impacto en el riesgo del sistema. Incluir el impacto potencial de estos factores adicionales resultará en

mejores evaluaciones de riesgo iniciales. Además, el seguimiento de estos factores puede proporcionar evaluaciones de riesgos mejoradas a lo largo del tiempo si no es posible

predecirlos perfectamente durante el desarrollo del sistema. El proceso de evaluación de riesgos no necesita detenerse cuando se implementan los sistemas. Se requieren

decisiones basadas en riesgos durante todo el ciclo de vida del sistema. Castilho [Castilho 2019] ha ideado lo que él llama Active STPA, que se puede utilizar durante las operaciones

para identificar los principales indicadores de cambios que aumentan el riesgo. El proceso de evaluación de riesgos no necesita detenerse cuando se implementan los sistemas. Se

requieren decisiones basadas en riesgos durante todo el ciclo de vida del sistema. Castilho [Castilho 2019] ha diseñado lo que él llama Active STPA, que se puede utilizar durante las

operaciones para identificar los principales indicadores de cambios que aumentan el riesgo. El proceso de evaluación de riesgos no necesita detenerse cuando se implementan los

sistemas. Se requieren decisiones basadas en riesgos durante todo el ciclo de vida del sistema. Castilho [Castilho 2019] ha diseñado lo que él llama Active STPA, que se puede utilizar

durante las operaciones para identificar los principales indicadores de cambios que aumentan el riesgo.

Si bien el uso de escenarios causales rigurosamente desarrollados utilizando STPA no evita todos los problemas con
las matrices de riesgo estándar, al menos proporciona una base más racional para las categorizaciones. Aquí se pueden
usar árboles de fallas y otras técnicas de análisis de peligros, pero generalmente no pueden comenzar hasta que se
disponga de un diseño detallado del sistema, que es un proceso tardío en el proceso de desarrollo cuando el uso de la
matriz de riesgos para determinar cómo asignar el esfuerzo de desarrollo no es muy útil . Además, agregar esfuerzos de
reducción de riesgos al final del desarrollo es costoso, extremadamente perjudicial para los cronogramas del proyecto y,
por lo general, menos efectivo que si los controles se diseñan en el sistema desde el principio. El STPA se puede hacer
antes, en el punto en el desarrollo del concepto cuando la matriz de riesgo se crea y se utiliza inicialmente.

Una limitación más importante es que los árboles de fallas y otras técnicas de análisis de peligros que asumen que los
accidentes son causados por fallas de componentes dejan fuera muchas (¿la mayoría?) De las causas de pérdidas en los
complejos sistemas actuales. Cuanto más completos sean los escenarios causales que se utilizan para evaluar la probabilidad,
mejores serán las estimaciones.

Las mejoras en la evaluación de riesgos descritas hasta ahora han implicado mantener la misma definición estándar
de riesgo, realizar cambios pero esencialmente mantener la misma forma para la matriz de riesgos y utilizar STPA para
ayudar en la evaluación de gravedad y probabilidad. Una alternativa es realizar cambios significativos en la propia
definición de riesgo y por tanto en su evaluación con el objetivo de mejorar notablemente los resultados. La exploración
de este tema es el tema de la Parte 2 de este documento técnico.

13
Referencias
Abrecht, B., Arterburn, D., Horney, D., Schneider, J., Abel, B. y Leveson, N. (2016), A New Approach to
Hazard Analysis for Rotorcraft, AHS Technical Specialists 'Meeting on the Desarrollo, asequibilidad y
calificación de sistemas complejos, Huntsville AL, 9 al 10 de febrero.

Abrecht, Blake (2016), Análisis de procesos teóricos de sistemas aplicado a un sistema de posicionamiento dinámico de buques de
suministro en alta mar, Tesis SM, Departamento de Aeronáutica y Astronáutica, MIT

Castilho, Diogo Silva (2019), Un modelo basado en sistemas y procesos para sistemas integrados de gestión de seguridad
(I-SMS), Ph.D. Disertación (en proceso), Departamento de Aeronáutica y Astronáutica del MIT, prevista para agosto.

Cox, Anthony (2008), What's Wrong with Risk Matrices, Análisis de riesgo 28 (2): 497–512. Kahneman D,

Tversky A. (1973) Sobre la psicología de la predicción.Revisión psicológica 80 (4): 237–51.

Kahneman, D., Slovic P. y Tversky A. (1982) Juicio bajo incertidumbre: heurística y sesgos, Nueva York:
Cambridge University Press.

Lauridsen, K., Kozine, I., Markert, F., Amendola, A., Christou, M. y Fiori, M., (2002), Evaluación de
Incertidumbres en el riesgo, 2002, Evaluación de incertidumbres en el análisis de riesgos de establecimientos químicos,
Laboratorio Nacional de Risø, Roskilde, Dinamarca, Risø-R-1344 (EN).

Leveson, Nancy (1995), Safeware: seguridad del sistema y computadoras, Nueva York: Addison-Wesley

Leveson, Nancy (2012) Engineering a Safer World, Cambridge, MA: MIT Press.

Rasmussen, Jens (1997), Gestión de riesgos en una sociedad dinámica: un problema de modelado, Ciencias de la seguridad 27 (2/3):
183–213.

Sikorsky Aircraft Corporation (2012), Informe de evaluación de seguridad para la aeronave de actualización UH-60M,
número de documento SER-703655, 3 de enero.

14