Escritos técnicos públicos sobre análisis de fallos, riesgo y aprendizaje organizativo — pensados para ser útiles tanto si instaláis algo nuestro como si no.
Los ingenieros descuentan las afirmaciones de marketing, y hacen bien; preferimos no hacer ninguna. Así que todo lo que se publica aquí lleva lo mismo:
Los dos últimos son lo importante. Un caso de estudio sin límites dentro es un anuncio, y haríais bien en descontarlo.
Un argumento en ocho movimientos sobre qué garantiza realmente la norma: la paradoja de una simulación que no simula, el factor dos, objetivos de seguridad que ya eran el requisito, y métricas que dependen de aquello que deberían medir. Publicado solo en inglés.
Tres flujos ejecutados como pruebas y no como demostraciones. Cada uno produjo una base de datos, y cada informe dice qué falló.
¿Llega una lección aprendida un lunes a un proyecto que empezó el año pasado? Una acción preventiva promovida al tipo apareció como fila abierta de checklist en una instancia tipada antes de que la lección existiera, sin escribir nada en esa instancia.
Un análisis de peligros de dirección asistida eléctrica: diez de diez vectores de referencia S/E/C→ASIL reproducidos sin cambios de código, y un HARA y un AMFE de componente convencional en una base de datos con matrices distintas.
65 requisitos con veredicto. El hallazgo que merecía contarse no fue un hueco sembrado: 16 requisitos tenían evidencia presente y ningún enlace a ella. Y la respuesta honesta a si una auditoría puede hacerse solo con datos estructurados — en parte.
Correspondencias entre las normas y un único modelo subyacente, cada una terminada en una tabla de cumplimiento con los huecos marcados como huecos.
AIAG/VDA y sus siete pasos, SAE J1739, IEC 60812, ISO 26262 e ISO 9001 — incluidas las filas que dicen no soportado.
Dónde deja la hoja de cálculo de ser la herramienta correcta, y dónde no. Incluye en qué sigue siendo mejor Excel y el caso en que estructurar un análisis no devuelve nada.
La pregunta del auditor sobre las lecciones aprendidas, por qué un procedimiento es una respuesta floja, y qué puede enseñar en su lugar un registro derivado — con lo que sigue sin demostrar.
Esta biblioteca es nueva y es corta. Crecerá en la dirección del trabajo — DRBFM y DRBTR en la práctica, árboles de fallos a partir de datos reales, métodos de lecciones aprendidas que no sean solo un registro, y los patrones de análisis de fallos que se repiten entre sectores.
Si hay algo que no paráis de explicar a vuestros colegas y no encontráis bien escrito en ninguna parte, decídnoslo. Es mejor guía sobre qué escribir a continuación que nuestras propias suposiciones.