Cómo calcular la longitud del código de seguridad de la EN 50159 (Anexo C.4)

El Anexo C.4 de la EN 50159 ofrece un pequeño conjunto de fórmulas para determinar la longitud que debe tener el código de seguridad en sistemas de transmisión cerrados (Categoría 1). Son solo tres ecuaciones, pero cada parámetro conlleva suposiciones fáciles de malinterpretar, y el propio texto es breve en algunos puntos. Este artículo repasa el modelo parámetro a parámetro. También recopila las preguntas y errores que surgen con más frecuencia en proyectos reales.

El modelo en un párrafo

Todo mensaje de seguridad está protegido por dos capas. El código de transmisión (un CRC de CAN, un FCS de Ethernet, etc.) pertenece al sistema de transmisión no confiable. El código de seguridad se genera y se comprueba de extremo a extremo mediante el equipo relacionado con la seguridad. El anexo identifica tres formas en las que un mensaje corrompido puede provocar un peligro:

Un fallo de hardware en el sistema de transmisión corrompe mensajes.
Las interferencias electromagnéticas (EMI) provocan errores de bit que ninguno de los dos códigos detecta.
El verificador del código de transmisión falla de forma silenciosa y deja de filtrar los mensajes corrompidos.

Cada vía tiene su propia ecuación, y la suma debe mantenerse dentro del objetivo:

(1)  R_HW × p_US × k1      = R_H1      con k1 ≥ n × m,  m ≥ 5
(2)  p_UT × p_US × f_W     = R_H2
(3)  k2 × p_US × (1/T)     = R_H3

R_H1 + R_H2 + R_H3 ≤ R_H

p_UT ≈ 2^-b   (b = bits de redundancia de un CRC de transmisión adecuado)
p_US ≈ 2^-c   (c = bits del código de seguridad)

La clave para interpretar las tres es que comparten una misma estructura:

tasa de peligro = (intentos por hora) × (probabilidad de que un intento supere el código de seguridad)

Un “intento” es un mensaje corrompido que llega a una verificación de código: la verificación del código de seguridad en las ecuaciones 1 y 3, y tanto la verificación del código de transmisión como la del código de seguridad en la ecuación 2. Una vez que se ve cada ecuación de esta manera, la mayor parte de la confusión desaparece. Mantenga las unidades coherentes: tasas y frecuencias en 1/h, probabilidades y factores k adimensionales, y T en horas.

Los parámetros

Parámetro	Significado	Unidad
R_H	Tasa de fallo peligroso objetivo del sistema de transmisión completo	1/h
R_H1	Tasa de fallo peligroso debida a fallos de hardware sin fallo del verificador del código de transmisión	1/h
R_H2	Tasa de fallo peligroso debida a EMI	1/h
R_H3	Tasa de fallo peligroso debida a fallos del verificador del código de transmisión	1/h
R_HW	Tasa de fallo de hardware del sistema de transmisión no confiable	1/h
p_UT	Probabilidad de que el código de transmisión no detecte un error	–
p_US	Probabilidad de que el código de seguridad no detecte un error	–
f_M	Frecuencia máxima de mensajes por receptor	1/h
f_W	Frecuencia de mensajes corrompidos	1/h
n	Mensajes corrompidos consecutivos antes de pasar al estado seguro	–
m	Factor de seguridad incluido en k1 (m ≥ 5)	–
k1	Factor para fallos de hardware que incluye el margen de seguridad (k1 ≥ n × m)	–
k2	Porcentaje de fallos de hardware que provocan una inhabilitación no detectada de la decodificación de transmisión	–
T	Intervalo de tiempo en el que más de un número definido de mensajes corrompidos provoca el paso al estado seguro. La ecuación 3 da el intervalo mínimo en el que solo se permite un error detectado	h

Ecuación 1: fallos de hardware

Los intentos. Un fallo de hardware produce una serie de mensajes corrompidos. El sistema recibe hasta n de ellos antes de entrar en el estado seguro, y cada uno tiene una probabilidad p_US de pasar desapercibido. La probabilidad de que al menos uno pase es aproximadamente n × p_US. Esta es la lectura habitual del factor k1 ≥ n × m.

Por qué el margen m. Los fallos de hardware no son aleatorios, por lo que los n intentos no son extracciones independientes con probabilidad 2^-c. Dos ejemplos realistas muestran por qué:

Un fallo intermitente burla un contador de mensajes consecutivos. Un conector flojo corrompe aproximadamente uno de cada diez mensajes. Los mensajes correctos siguen reiniciando el contador de “n errores consecutivos”, de modo que el código de seguridad se enfrenta a miles de intentos en lugar de a n.
Un fallo en una línea de direcciones entrega el mensaje equivocado. Una pasarela (gateway) lee el búfer contiguo y reenvía un mensaje distinto, perfectamente válido. Un CRC por sí solo no puede detectar esto. Los identificadores de origen y los números de secuencia dentro de los datos protegidos sí pueden.

El anexo explica el margen brevemente: como no puede asumirse que los fallos de hardware sean aleatorios, se incorpora un margen de seguridad m ≥ 5 en k1 = n × m. En la práctica, un margen no sustituye a las medidas de diseño, así que hay que asegurarse de que los mecanismos que sustentan el modelo existen realmente: contadores de error que no se reinician con cada mensaje correcto, e identificadores de origen y números de secuencia dentro de la cobertura del código de seguridad.

Por qué no aparece p_UT. La ecuación 1 no incluye el factor p_UT, y el anexo no explica el motivo. La lectura habitual es que los fallos de hardware pueden corromper datos fuera del tramo que protege el código de transmisión: antes de la codificación, después de la decodificación, o dentro de pasarelas y conmutadores que decodifican y vuelven a codificar las tramas, generando un CRC nuevo y válido. En la práctica, no se concede ningún crédito al código de transmisión en esta vía.

De dónde sale R_HW. El anexo define R_HW únicamente como la tasa de fallo de hardware del sistema de transmisión no confiable. Lo que sigue es orientación práctica, no texto del anexo. En la práctica, R_HW es la suma de las tasas de fallo de todos los elementos situados entre el punto donde se genera el código de seguridad y el punto donde se verifica: pasarelas, conmutadores, repetidores, transceptores, módulos de comunicación, cableado y conectores. Utilice datos de FIT o MTBF del fabricante (1 FIT = 10⁻⁹/h, λ ≈ 1/MTBF), o manuales de fiabilidad como SN 29500, IEC 61709 o MIL-HDBK-217F. Hay tres puntos que merecen atención:

El equipo de seguridad de los extremos queda excluido. Pertenece al propio análisis SIL del equipo de seguridad.
Las vías redundantes no reducen R_HW, al menos no en una arquitectura de conmutación por error (failover) simple en la que el mensaje de cualquiera de las dos vías se acepta por sí solo: un fallo en cualquiera de ellas puede seguir entregando un mensaje corrompido, así que, a efectos de integridad, ambas tasas se suman. Un diseño que exige que ambas vías coincidan, y que pasa al estado seguro si no coinciden, es un caso distinto, que se trata más adelante en este artículo.
Sin datos disponibles, 10⁻⁴/h es un punto de partida defendible. Corresponde a un MTBF de unas 10.000 horas, una cifra pesimista más que típica para el hardware de transmisión.

Ecuación 2: EMI

Por qué no hay una tasa de fallo. Aquí nada falla. La EMI es una condición ambiental que actúa sobre un sistema sano. f_W es simplemente la tasa de intentos: cada mensaje corrompido pone a prueba ambos códigos una vez.

Cómo elegir f_W. El anexo da dos formas de fijarlo:

Tomar f_W = f_M. Esta es la estimación de peor caso, y se justifica por sí misma, ya que no puede haber más mensajes corrompidos que mensajes. Para la transmisión cíclica, f_M está bien definida; para la transmisión no cíclica hay que tomar la frecuencia máxima posible. Esto ya cubre las ráfagas en cuanto al número de intentos, porque una ráfaga no puede superar “todos los mensajes corrompidos, siempre”. El coste es más bits de código de seguridad.
Limitar f_W con contadores o temporizadores seguros. Si se recibe más de un mensaje incorrecto dentro de un intervalo de tiempo definido, se aborta la comunicación segura y se entra en el estado seguro. Por ejemplo, abortar al segundo error detectado dentro de un minuto, de modo que f_W ≤ 60/h en lugar de 36.000/h. Esto se cumple sea cual sea la estadística de las ráfagas. El precio es la disponibilidad: las ráfagas provocan disparos.

Una tercera vía que a veces se ve en la práctica, estimar f_W a partir de una tasa de error de bit medida, no es una de las opciones del anexo. Yo evitaría usarla como argumento principal: las tasas de error de bit no están garantizadas en un entorno ferroviario, y las ráfagas rompen el modelo de error aleatorio en el que se basa la estimación.

El verdadero riesgo de las ráfagas es la independencia. Multiplicar p_UT × p_US supone que los dos códigos fallan de forma independiente, pero ambos ven el mismo patrón de error. El error clásico es usar el mismo polinomio de CRC en las dos capas. Un patrón de error que sea múltiplo de ese polinomio burla entonces a ambos códigos, y el producto se convierte en ficción. Solo reclame crédito por p_UT si puede argumentar independencia. En caso contrario, tome p_UT = 1, como sugiere la propia nota a pie del anexo.

Dónde vive la ventana. La ventana debe residir en la capa de seguridad. No se puede acreditar un contador situado en la capa de transmisión no confiable.

Ecuación 3: fallo silencioso del verificador de transmisión

Qué “decodificador” falla. Es el verificador del código de transmisión, como el controlador CAN o el MAC de Ethernet. No es el verificador del código de seguridad, que sigue funcionando y es la última barrera que queda. Por eso aparece p_US en la ecuación. Si fallara el propio verificador de seguridad, la respuesta está en el diseño SIL del equipo de seguridad, no en este anexo.

Adónde fue la tasa de fallo. El anexo define k2 como el factor que describe el porcentaje de fallos de hardware que provocan una inhabilitación no detectada de la decodificación de transmisión. Su derivación informativa supone que solo en 1 de cada 10.000 fallos de hardware el verificador del código de transmisión falla sin ser detectado, y que la duración media de ese estado (sin EMI) es T = MTBF = 1/R_HW. R_HW se cancela entonces:

k2 = 10⁻⁴ × R_HW × (1 / R_HW) = 10⁻⁴

Observe que el anexo reutiliza el símbolo T para esta duración. No tiene nada que ver con la ventana T. El anexo indica que, si es posible realizar una comprobación periódica del mecanismo de codificación de transmisión, k2 puede despreciarse. (Por analogía con los intervalos de prueba periódica de la IEC 61508, k2 se comportaría entonces como λ_silencioso × τ / 2 para un intervalo de prueba τ. Esto es una extensión mía, no texto del anexo.) El anexo también señala que su estimación es muy pesimista, ya que una pequeña degradación de la calidad de la transmisión normalmente llevaría al estado seguro. Sin ninguna justificación, tome k2 = 1, lo que equivale a asumir que el verificador está siempre averiado.

Por qué 1/T es la tasa de intentos. Con el verificador averiado, todos los mensajes corrompidos llegan a la capa de seguridad. El mecanismo de ventana limita los intentos a aproximadamente uno por T. Sin una ventana, los intentos serían f_W, y la ecuación 3 se reduciría a la ecuación 2 con p_UT = 1. Si no se implementa tal mecanismo, el anexo exige entrar en el estado seguro inmediatamente después del primer error detectado; de lo contrario, deben introducirse otras medidas frente a posibles condiciones de error.

Este 1/T solo cubre el caso de tolerar un único error detectado antes de pasar al estado seguro: disparo en el segundo, no en el sexto. Si su diseño, en cambio, tolera N errores dentro de una ventana W más amplia (por ejemplo, cinco errores en una hora en lugar de uno por minuto), la propia ecuación 3 no le da eso directamente. La condición pasa a ser W ≥ N × T_req, donde T_req es el T mínimo que da la ecuación 3 para el caso de un solo error con su presupuesto de R_H3. Así que “cinco en una hora” solo es válido una vez que se ha comprobado frente a esa desigualdad; no es automáticamente equivalente a “uno por minuto” solo porque ambas frases suenen igual de estrictas.

Si toma p_UT = 1, la ecuación 3 se vuelve redundante. Ya está asumiendo que el verificador no filtra nada, así que perderlo no cambia nada. Puede fijar R_H3 = 0 y reasignar su parte del presupuesto. Esta es mi lectura, no texto del anexo: el anexo sigue enumerando los tres términos, así que documente el argumento de forma explícita y acuérdelo con su evaluador.

Últimas observaciones

También es posible acortar c, dentro de ciertos límites. El anexo permite reducir c a la mitad (al menos) para alcanzar el mismo objetivo repitiendo cada mensaje y comprobando la coherencia de dos copias mutuamente independientes: dos testigos independientes hacen el trabajo de bits de código adicionales. Incluso sugiere que es posible una mejora adicional más allá de la mitad, pero recomienda detenerse ahí en lugar de entrar en cálculos más finos. Esto no es gratis: solo cuenta como una ganancia real una vez que se ha demostrado que los fallos de causa común —un único fallo que corrompe ambas copias de la misma manera— son despreciables.

Esta independencia tiene que ser real, no simplemente asumida. Enviar ambas copias por la misma red no es suficiente: los fallos de hardware allí tienden a ser persistentes, de modo que el mismo defecto puede corromper ambas copias de la misma manera y aun así superar la comprobación de coherencia, una de las razones por las que la ecuación 1 tampoco concede crédito al código de transmisión. El truco ayuda de forma fiable frente a los errores de bit aleatorios de la ecuación 2; obtener un beneficio genuino frente a R_HW o frente a un verificador de código de transmisión compartido requiere dos vías físicamente separadas.

Un error heredado habitual es calcular T = N_max × Δt, el número máximo de paquetes erróneos multiplicado por el período de paquete. Ese es el tiempo de reacción del sistema ante una ráfaga, no la ventana de la ecuación 3. No contiene p_US ni R_H3, así que no puede garantizar el objetivo. Con un contador de mensajes consecutivos, ni siquiera acota la tasa de intentos. Con N = 3 y Δt = 100 ms, resulta en T = 0,3 s e implica unos 12.000 intentos por hora, frente a un requisito de aproximadamente 1,4 por hora. Si su mecanismo realmente tolera N errores en una ventana W, la condición correcta es W ≥ N × T_req.

Un ejemplo resuelto

Este ejemplo verifica un diseño en el que las decisiones ya están tomadas: T, n y el mecanismo de ventana ya están implementados, no siguen abiertos. Canal: CRC de transmisión de 16 bits, código de seguridad de 32 bits, R_HW = 1 × 10⁻⁴/h (sin datos del fabricante), n = 3, m = 5 (k1 = 15), f_W ≤ 60/h mediante una ventana de un minuto, independencia entre los dos códigos acreditada, y una capa de seguridad que ya utiliza un temporizador de 10 minutos para T. Objetivo: R_H = 1 × 10⁻¹⁰/h.

Resultados:

Ec. 1: R_HW × p_US × k1 = 10⁻⁴ × 2⁻³² × 15 ≈ 3,5 × 10⁻¹³/h.
Ec. 2: p_UT × p_US × f_W = 2⁻¹⁶ × 2⁻³² × 60 ≈ 2,1 × 10⁻¹³/h.
Ec. 3, sin comprobación periódica del verificador del código de transmisión (k2 = 1): R_H3 = k2 × p_US / T = 1 × 2⁻³² / (1/6) ≈ 1,4 × 10⁻⁹/h. Total ≈ 1,4 × 10⁻⁹/h — por encima del objetivo de 1 × 10⁻¹⁰/h. Este diseño no cumple.
Ec. 3, con comprobación periódica implementada (k2 = 10⁻⁴): R_H3 = k2 × p_US / T = 10⁻⁴ × 2⁻³² / (1/6) ≈ 1,4 × 10⁻¹³/h. Total ≈ 7,0 × 10⁻¹³/h — cómodamente dentro del objetivo. Este diseño cumple.

Aquí no hace falta resolver nada, solo sustituir: se introduce lo que el diseño ya tiene y se comprueba la suma frente al objetivo. El resultado también muestra hasta qué punto una sola suposición, si el verificador se prueba periódicamente o no, puede decidir si un diseño ya fijado cumple o no.

Si T, n o la ventana todavía no están decididos, el sentido se invierte: en lugar de comprobar un T ya elegido, se resuelven las ecuaciones para obtener el T (o c, o n) mínimo que debe tener el diseño, y también se puede optar por no repartir el presupuesto objetivo a partes iguales entre las tres ecuaciones. Ese enfoque de “derivar primero”, y cómo aprovechar bien el presupuesto liberado, se trata en detalle en nuestro curso de EN 50159.

Los errores más comunes

Reclamar crédito por p_UT usando el mismo polinomio de CRC en ambas capas, o sin ningún argumento de independencia.
Acreditar contadores de error situados en la capa de transmisión. Solo cuentan los contadores y temporizadores seguros del equipo de seguridad.
Contar p_UT dos veces cuando una ventana de la capa de seguridad ya solo ve tramas que superaron el CRC de transmisión.
Contadores de errores consecutivos que se reinician por completo con cada mensaje correcto. Los fallos intermitentes los burlan.
Calcular T como N_max × período de paquete en lugar de derivarlo de la ecuación 3.
Confundir los dos significados de T en el anexo: la ventana, y la duración del estado de fallo silencioso en la nota sobre k2.
Pensar que el “decodificador” de la ec. 3 es el verificador de seguridad, y concluir que p_US es irrelevante ahí.
Mezclar unidades, como mensajes por segundo frente a tasas de peligro por hora.
Tratar la redundancia de red como si redujera R_HW. A efectos de integridad, se suma.
Invertir en exceso en cifras precisas de R_HW cuando un argumento de sensibilidad muestra que no importan, o invertir de menos cuando el código de seguridad es corto y sí importan.
Verificar el código de seguridad en hardware que no es de seguridad, como una pasarela estándar. Un único fallo podría entonces burlar ambas barreras, y el modelo deja de ser válido.
Usar p_US = 2^-c sin demostrar que el código es “propio” (proper) para la longitud de mensaje y el polinomio reales.

Reflexión final

El Anexo C.4 parece aritmética, pero en realidad es un conjunto de requisitos de arquitectura disfrazados. Cada cifra favorable que se utilice debe estar respaldada por una característica de diseño: un polinomio independiente, una ventana segura, un contador que no se reinicia, una prueba periódica del verificador. En caso de duda, tome el valor conservador (p_UT = 1, k2 = 1, f_W = f_M) y deje que unos pocos bits adicionales de código de seguridad le compren un caso de seguridad más simple y más defendible.

Este artículo es una orientación para interpretar la norma y no sustituye a la propia norma ni al criterio de su evaluador.

Profundice en la comunicación relacionada con la seguridad

Si quiere profundizar en su dominio de la EN 50159 y en la comunicación relacionada con la seguridad que hay detrás de los sistemas de enclavamiento y control remoto, nuestros cursos online en RAMSRail.com están diseñados para ingenieros y jefes de proyecto que necesitan un conocimiento práctico y aplicable de estas normas.

Descubra nuestros cursos de formación en RAMS en RAMSRail.com