Perfil EGAF Industrial para IEC 61508 y ferrocarril
El perfil Industrial es L3. Extiende Core para sistemas relacionados con la seguridad eléctricos / electrónicos / electrónicos programables y la variante del sector ferroviario. El SIL proviene del propio análisis de peligros y riesgos del adoptante.
Sistema en prelanzamiento, operado por su fundador; las etiquetas de capacidad actuales describen el límite de la evidencia.
Cómo funciona el Evidence-Gated Assurance Framework
El Evidence-Gated Assurance Framework (EGAF) es un estándar de garantía orientado a la especificación. Está En curso. Un proyecto declara conformidad con EGAF L1, L2 o L3 en un commit dado, con evidencia adjunta. No es una certificación, una acreditación ni una autorización. La evaluación independiente de cualquier organización sigue siendo una cuestión aparte.
Una ejecución consta de tres partes:
- Un catálogo de controles. Cada control es un
checkde máquina (un artefacto producido por una herramienta independiente) o unevidence: attestation(una declaración firmada por un principal identificado). Una comprobación declarada sin un artefacto que la respalde es DRIFT, nunca PROVEN. Un archivo vacío pero analizable no es un veredicto. - Un evaluador determinista. Las mismas entradas producen un informe de conformidad idéntico byte a byte. El evaluador no ejecuta pruebas ni escáneres. Lee artefactos que otras herramientas ya produjeron y registra sus digests. Un agente no puede fabricar un PROVEN sin producir el artefacto que la comprobación nombra.
- Un perfil versionado.
.egaf/profile.yamlen el repositorio consumidor es lo que evalúa CI. Si ese archivo no está presente, el evaluador usa el perfilcoreincluido, por lo que los controles obligatorios de L1 siempre aplican. Los perfiles solo pueden endurecer un umbral; una anulación que lo relaje se rechaza en el momento de la validación.
Tres niveles. L1 Core es obligatorio para declarar cualquier conformidad con EGAF: trazabilidad, límites de complejidad y duplicación, cobertura de sentencias y de ramas de toda la base de código, mutación en los archivos modificados, integridad del verificador, evidencia firmada, higiene de la cadena de suministro. Una EXCEPTION nunca satisface un control L1. L2 Regulated añade controles de perfil de industria (paquetes de evidencia, retención, registros de riesgo de modelo). L3 Safety-critical añade independencia, cobertura estructural, entradas para la calificación de herramientas y vinculación con peligros. Si falla un control L1 aplicable, la primera línea del informe es L0.
El estado de un control condensa los siete resultados de comprobación que ya se usan en los paquetes de evidencia de Koinessa:
| Resultado de la comprobación | Estado del control |
|---|---|
| PASS | PROVEN |
| FAIL | FAILED |
| SKIPPED-NOT-APPLICABLE con una razón registrada | NOT-APPLICABLE |
| INFRASTRUCTURE-ERROR, TOOL-MISSING, EVIDENCE-INVALID o ABSTAIN | DRIFT |
| Evidencia ausente | DRIFT |
Un nivel se alcanza únicamente cuando todos los controles aplicables en ese nivel y en los niveles inferiores están PROVEN o NOT-APPLICABLE (L2/L3 también pueden contar con una EXCEPTION vigente con un aprobador independiente). El informe siempre muestra dos listas de honestidad: No probado (FAILED y DRIFT) y Aceptado sin prueba (NOT-APPLICABLE y EXCEPTION). Una insignia limpia sobre un bloque de honestidad vacío es el fallo que el marco existe para evitar.
Los marcos son orientación. Los controles son comportamiento. La evidencia demuestra que el comportamiento ocurrió. Las cargas organizativas — formación, seguridad física, BAA, una evaluación C3PAO, la calificación de herramientas DO-330, un encargo SOC 2 Type II — siguen recayendo en la organización. El catálogo cita identificadores de cláusulas y paráfrasis; no reproduce texto normativo.
El catálogo que describe esta serie es una instantánea con estado Medido: 109 controles, incorporados a Koinessa en el pin 0.0.0-dev+98d08ef el 2026-08-30. El repositorio público de la especificación está Planeado; hasta que el operador cree su grupo de GitLab, trata EGAF como un borrador pre-1.0 etiquetado y pendiente de publicación. El primer informe de conformidad del propio Koinessa en la rama principal está Planeado.
Consulta el libro blanco de Koinessa para la tesis más amplia de Evidence-Gated Agentic Development, y el informe de entrega verificada para lo que este sistema ya publica sobre sí mismo.
El perfil Industrial (id industrial, L3)
En curso. Fuente: vendor/egaf/catalog/profiles/industrial.yaml. Extiende core.
Marcos añadidos:
- IEC 61508-3 (requisitos de software para sistemas relacionados con la seguridad E/E/PE)
- EN 50128 (variante para el sector ferroviario)
Todos los controles SAF (de SAF-01 a SAF-11) ya están en el conjunto activo en cuanto este perfil declara level: L3.
safety_classes enumera de SIL-1 a SIL-4 como el vocabulario reconocido para SAF-01. Cada adoptante nombra el SIL o los SIL reales de su propio componente en su propio .egaf/profile.yaml, derivados de su propio análisis de peligros y riesgos.
Aplicabilidad: agentic y firmware. Releases y deploys declarados.
La retención es de duración del programa (months: null). La establece el propio sistema de gestión de la seguridad funcional de la organización operadora conforme a la cláusula 6 de IEC 61508-1, o la norma de registros de la autoridad de seguridad ferroviaria aplicable conforme a EN 50128, y no EGAF. La investigación del catálogo no encontró una cifra de retención universal única que citar para un programa industrial o ferroviario.
Las excepciones L3 necesitan un aprobador independiente y una declaración firmada. Los controles L1 heredados de Core siguen sin poder exceptuarse.
Lo que la organización todavía debe hacer: el ciclo de vida de seguridad según IEC 61508-1, la asignación del SIL y cualquier evaluación de un organismo notificado o de la autoridad ferroviaria. EGAF puede exigir que se haya declarado un SIL y que existan artefactos de herramientas independientes para las medidas de software. No puede certificar una función de seguridad.
Las capas L3 hermanas son Aerospace (DAL) y Automotive (ASIL).
Lo que esta página no afirma
La conformidad con EGAF es una declaración por commit que un proyecto hace sobre sí mismo, con evidencia adjunta. No otorga una certificación, un nivel SLSA ni una autorización para operar. Citar un marco en un perfil es una correspondencia, no un estado que el adoptante haya alcanzado. Los elementos planeados no llevan fechas.
Este artículo es uno de diez en una serie. Cada página mantiene la misma mecánica y cambia el perfil.
- Core (L1)
- OSS Maintainer (L1)
- Financial (L2)
- Health (L2)
- Defense (L2)
- Public Sector (L2)
- AI-Regulated (L2)
- Aerospace (L3)
- Automotive (L3)
- Industrial (L3)
El resto del blog de ingeniería cubre el bucle de verificación sobre el que se apoya EGAF. La página principal de Koinessa expone la posición del producto.