Un Análisis de Peligros y Evaluación de Riesgos (HARA, por sus siglas en inglés), tal como se define en la norma ISO 26262, es estructuralmente idéntico a un FMEA: se identifican los posibles fallos, se evalúa el riesgo y se define qué debe hacerse al respecto. En KF, ambos se modelan con los mismos elementos — ítems, eventos y acciones. No se necesita ningún modo especial ni un flujo de trabajo separado para el HARA.
| Concepto ISO 26262 | Elemento KF |
|---|---|
| Ítem (sistema en análisis) | `Item` |
| Evento peligroso | `Event` sobre el ítem, con nivel ASIL |
| Requisito de seguridad | `Action` sobre el evento peligroso |
| Estado seguro | `Action` hijo del requisito de seguridad |
| Requisito de seguridad funcional | `Action` hijo del requisito de seguridad o del estado seguro |
El nivel ASIL (A–D, o QM) es un atributo del `Event`, que es donde corresponde: el ASIL se determina por la severidad del peligro, la exposición y la controlabilidad — propiedades de la situación peligrosa, no de la respuesta.
Crear un `Item` que represente el sistema o subsistema que se analiza — por ejemplo, Unidad de dirección asistida eléctrica.
Para cada evento peligroso identificado en el HARA, crear un `Event` sobre el ítem. Establecer el nivel ASIL como atributo del evento.
Ejemplo:
KF calcula el nivel ASIL correspondiente cuando se usan los valores de severidad, exposición y controlabilidad de la norma ISO 26262 en los campos de riesgo del evento:
La matriz de riesgo utilizada para ese evento es entonces la tabla ASIL de la norma ISO 26262.
Crear una `Action` sobre el evento peligroso. Este es el requisito de seguridad — la respuesta requerida de alto nivel ante el peligro.
Ejemplo:
Un requisito de seguridad se satisface alcanzando un estado seguro. Añadir `Actions` hijo al requisito de seguridad que representen el estado o los estados seguros.
Ejemplo:
Si hay varios estados seguros candidatos, usar el marcador alternative (véase más adelante).
Cada acción de estado seguro puede tener sus propias acciones hijo que representen requisitos de seguridad funcional, medidas de diagnóstico o pasos de verificación. El árbol crece exactamente igual que en un FMEA.
En KF estándar, una acción padre se completa cuando todas sus acciones hijo están completas (semántica AND). Esto es suficiente para los estados seguros y los pasos de verificación que deben alcanzarse todos.
Para los requisitos y las decisiones de diseño, existe un segundo modo de composición: el marcador alternative.
Cuando la conexión desde una acción padre a una acción hijo lleva el atributo `alternate`, el padre se completa cuando cualquiera de los hijos alternativos está completo. Esto modela un espacio de soluciones: existen varios candidatos de implementación y uno debe ser elegido y realizado.
Cuando se toma una decisión, se marca el hijo elegido con `accepted` y las alternativas rechazadas con `rejected`. Las alternativas rechazadas se conservan — no se eliminan — para que la justificación del diseño permanezca trazable.
Requisito de seguridad: Garantizar la reducción controlada de la asistencia de dirección ante un fallo
Acciones hijo alternativas (role=alternate):
El requisito de seguridad se satisface cuando la implementación seleccionada está completa y verificada.
En KF, un requisito se modela como una `Action` — opcionalmente etiquetada como requisito — en lugar de como un tipo de elemento separado. Esta es una decisión de diseño deliberada, no una simplificación.
El razonamiento es el siguiente.
Un requisito que no puede expresarse como algo que un agente debe hacer o garantizar está insuficientemente especificado. «El sistema no deberá provocar una aceleración no deseada» solo tiene valor de ingeniería cuando se traduce en algo diseñable, implementable y verificable. El requisito es la obligación de actuar; el SHALL es el marcador de conformidad.
Modelar los requisitos como acciones tiene una consecuencia directa: el cumplimiento es simplemente la compleción de la tarea. Un requisito se cumple cuando su acción — o una de sus acciones hijo alternativas — está completa y marcada. No se necesita ningún mecanismo separado de seguimiento de conformidad. La misma marca OK que cierra una acción correctiva en un FMEA cierra un requisito en un HARA.
La conexión alternativa es lo que hace que esto sea formalmente correcto. Sin ella, un requisito-como-acción implica una única implementación predeterminada, lo que confunde el requisito (lo que debe ser verdad) con la solución (lo que se hace para que sea verdad). Con conexiones alternativas, la acción de requisito mantiene el espacio de soluciones abierto hasta que se toma una decisión de diseño — momento en el que se selecciona una alternativa, el resto se conserva como candidatos rechazados y el requisito se cierra con la implementación elegida.
Este modelo cubre el ciclo de vida completo: requisito enunciado → alternativas exploradas → decisión tomada y registrada → implementación verificada → requisito cerrado.