¿Qué es el protocolo P100 en ascensores?
El protocolo P100 es un formato abierto basado en tonos DTMF que usan los ascensores para enviar alarmas, pruebas periódicas y eventos técnicos al centro de rescate, cumpliendo EN 81-28.
Dónde se usa hoy el P100 y por qué importa
En el pasado, el protocolo P100 se utilizaba principalmente en teléfonos de emergencia de ascensores conectados por línea analógica. Actualmente, sigue presente en soluciones de numerosos fabricantes que siguen fabricando productos analógicos y es entendido por muchas centrales receptoras de alarmas (CRA) como formato común para alarmas, llamadas de prueba y eventos técnicos.
Su importancia no está en ser el protocolo más moderno, sino en ser el denominador común del sector. P100 permite que un ascensor de un fabricante pueda comunicarse con una central o plataforma de otro sin depender de protocolos propietarios de cada una de las marcas. Además, en muchos casos es una pieza clave para cumplir la EN 81-28, ya que facilita las llamadas de test periódicas y la identificación automática del ascensor, algo crítico en rescates y auditorías de seguridad.
En un contexto donde conviven equipos analógicos P100 es una buena idea porque reduce fricción, simplifica integraciones y asegura interoperabilidad, pero en la era de las redes móviles e IP ¿Sigue siendo buena idea?
¿Cuál fue el origen del protocolo P100?
El P100 no nace como una norma oficial publicada por un organismo de estandarización (no es un EN, ISO o ETSI). Nace como un estándar de facto: una solución práctica impulsada por la propia industria de teléfonos de emergencia para ascensores.
El contexto: ascensores + telealarma + necesidad de interoperar
Durante años, muchas instalaciones resolvían la emergencia con una simple llamada de voz. El problema era evidente: la central podía recibir la llamada, pero no siempre sabía automáticamente qué ascensor estaba llamando, ni si era una alarma real, una prueba o un fallo técnico. Cada fabricante podía resolverlo “a su manera”, con formatos distintos, lo que complicaba integraciones y mantenimiento.
El punto de inflexión: EN 81-28 (2003)
Con la publicación de EN 81-28:2003, el sector se vio empujado a garantizar cosas muy concretas en los sistemas de alarma remota, como:
identificación del ascensor/instalación ante el centro receptor
llamadas de prueba automáticas periódicas (el famoso test cada 3 días, como mínimo)
supervisión del sistema (estado y disponibilidad)
La norma no dijo “usa P100”, pero sí definió el problema. Y la industria necesitaba una forma simple y compatible de enviar esos datos.
La solución práctica: datos cortos por tonos DTMF
En ese entorno (línea telefónica analógica, DTMF fiable, centrales ya preparadas para decodificar tonos), varios fabricantes fueron convergiendo en un esquema común: mandar un pequeño paquete de datos al inicio de la llamada usando tonos DTMF.
Ahí es donde aparece P100 y se consolida como “idioma común”:
protocolo abierto / no propietario
mínima cantidad de información
fácil de implementar y decodificar
suficiente para identificación + tipo de evento + detalle
Con el tiempo, manuales de fabricantes lo empiezan a describir como protocolo universal / no propietario, y plataformas lo empezaron a soportar como compatibilidad hacia atrás.
En resumen:
Origen aproximado: primera mitad de los 2000
Motivo: dar respuesta práctica a las necesidades de telealarma y a los requisitos que empuja EN 81-28
Autoría: no atribuible a una sola entidad; es una convergencia industrial
Resultado: se convierte en un estándar de facto muy extendido
Propósito y función principal del protocolo P100
El protocolo P100 existe para resolver un problema muy concreto en la telefonía de emergencia de ascensores: que, cuando se produce una llamada (de alarma o de prueba), el receptor no tenga que “adivinar” qué ascensor está llamando ni qué tipo de evento es.
En la práctica, P100 permite que el teléfono de emergencia envíe una pequeña cantidad de datos al inicio de la llamada, usando tonos DTMF, con tres piezas de información:
Call type: qué tipo de llamada es (alarma, test, fin de rescate, evento técnico, etc.).
ID: qué equipo/ascensor está llamando (normalmente un identificador numérico de hasta 8 dígitos).
DATA: un código opcional que detalla el evento (por ejemplo, fin de rescate, fallo de botón, fallo de audio, etc.).
¿Qué aporta esto en un sistema real?
Si lo reduces a “para qué sirve”, P100 aporta cuatro cosas muy prácticas:
Identificación automática del ascensor
Sin depender de que el operario pregunte, de que el usuario hable, o de que exista un listado manual. La central recibe el ID y sabe el origen.
Clasificación del evento desde el primer segundo
No es lo mismo una alarma real que una llamada de prueba o un evento técnico. Con el call type (y a veces DATA) el sistema puede etiquetar, registrar y enrutar correctamente.
Supervisión y trazabilidad
Las llamadas de prueba periódicas y los eventos técnicos generan un histórico útil: el sistema demuestra que está vivo, y deja rastro de incidencias (audio, botón, alimentación, etc.).
Interoperabilidad (hasta cierto punto)
Al ser un formato abierto/no propietario, P100 ha servido como “lenguaje común” entre teléfonos de distintos fabricantes y plataformas receptoras, especialmente en el núcleo de eventos más básicos.
En resumen: P100 convierte una llamada telefónica en una llamada “con identidad y contexto”, para que un centro de rescate pueda actuar rápido, registrar correctamente y supervisar el estado de los equipos sin depender únicamente de voz o procesos manuales.
Normativa EN 81-28 y el protocolo P100
La EN 81-28 es la norma europea que regula los sistemas de alarma remota en ascensores. Define qué debe garantizar un sistema de emergencia, pero no impone ningún protocolo de comunicación concreto. Aquí es donde conviene separar claramente norma y tecnología.
Qué exige realmente la EN 81-28
De forma resumida, la norma exige que el sistema de alarma:
Permita una comunicación bidireccional entre la cabina y el centro de rescate.
Identifique la instalación que realiza la llamada.
Realice llamadas de prueba automáticas y periódicas (habitualmente cada 72 horas).
Supervise el estado del sistema (alimentación, audio, disponibilidad).
Garantice que los fallos relevantes se detectan y se comunican.
La EN 81-28 define el resultado esperado, no el “cómo”.
Dónde encaja P100
El protocolo P100 encaja de forma natural porque permite cumplir varios de esos requisitos con una solución simple:
La identificación del ascensor se envía automáticamente mediante el campo ID.
Las llamadas de prueba se implementan como Checking Call (call type 3).
Los eventos técnicos (audio, pulsador, alimentación, etc.) se envían como mensajes P100 con códigos DATA.
Todo se transmite en una única llamada, sin necesidad de sistemas adicionales.
Por eso, en la práctica, muchos fabricantes adoptaron P100 como mecanismo habitual para cumplir EN 81-28, especialmente en entornos analógicos donde el envío de DTMF era fiable y bien entendido por las centrales.
Lo importante: EN 81-28 ≠ P100
Un punto clave que genera confusión en el sector es este:
La EN 81-28 no exige P100.
No lo menciona.
No lo define.
No lo estandariza.
P100 es simplemente una de las formas más utilizadas para cumplir la norma, no la única posible. Existen y han existido otras soluciones (protocolos propietarios, CPC, tramas de datos IP, etc.) que también pueden cumplir los requisitos si están bien implementadas.
Estructura general del protocolo P100
El protocolo P100 se basa en una estructura muy simple y deliberadamente limitada, pensada para transmitir pequeñas cantidades de información de forma rápida y fiable en una llamada telefónica. Su diseño refleja claramente el contexto para el que fue creado: líneas analógicas y tonos DTMF.
La estructura lógica básica de un mensaje P100 es siempre la misma:
Call type – ID – DATA
Call type
Es un único dígito DTMF que indica el tipo de llamada o evento que se está notificando. Define el contexto general de la comunicación, por ejemplo:
alarma de emergencia,
llamada de prueba,
evento técnico,
fin de rescate.
El call type es clave porque permite a la central interpretar la llamada antes incluso de que se establezca la comunicación de voz.
ID
El campo ID identifica de forma unívoca el ascensor o equipo que genera la llamada.
En P100, el identificador es numérico y está pensado para una longitud de hasta 8 dígitos, suficiente para la mayoría de instalaciones tradicionales.
Este campo permite que la central:
localice rápidamente la instalación,
asocie la llamada a un contrato o ficha técnica,
registre correctamente eventos y pruebas EN 81-28.
DATA
El campo DATA es opcional y se utiliza para aportar detalle adicional sobre el evento.
Puede indicar, por ejemplo:
fin de proceso de rescate,
fallo de pulsador,
fallo o recuperación de audio,
otros eventos técnicos definidos por el fabricante.
Aunque en muchos casos el DATA es numérico, algunos fabricantes emplean códigos alfanuméricos (por ejemplo E101, A107, etc.) manteniendo la misma lógica de protocolo.
Cómo se transmite la información
La trama P100 se envía como una secuencia de tonos DTMF durante la llamada telefónica:
El teléfono de emergencia marca el número del centro receptor.
Una vez establecida la llamada, envía los tonos DTMF con la secuencia Call type – ID – DATA.
Si se trata de una alarma, tras el envío de datos se abre el canal de audio manos libres.
Si es una llamada de prueba o evento técnico, la llamada suele finalizar tras transmitir los datos.
No existe intercambio de datos en sentido contrario: P100 es un protocolo unidireccional, centrado exclusivamente en notificar eventos.
Una estructura simple… y deliberada
Esta simplicidad es precisamente lo que hizo a P100 tan popular en el pasado:
fácil de implementar en hardware limitado,
fácil de decodificar en centrales,
suficiente para cumplir los requisitos básicos de identificación y supervisión.
En el siguiente apartado entraremos al detalle de qué eventos y comandos concretos se usan realmente.
Tabla de comandos y tramas del protocolo P100
A continuación se muestra la tabla de comandos y eventos P100 más habituales, basada en documentación pública de fabricantes y utilizada como referencia por gran parte del sector.
Núcleo común de comandos P100
Núcleo común de comandos P100 (referencia habitual)
Formato: Call type – ID – DATA
P100 – eventos básicos (formato lógico)
Formato general:
Call type – ID – DATA
Alarm (alarma principal)
- Call type: 1
- ID: Lift ID
- DATA: –
- Comentario: Llamada de alarma desde el pulsador principal
Alarm 2 (segunda alarma)
- Call type: 1
- ID: Lift ID
- DATA: –
- Comentario: Segunda entrada configurada como alarma
Checking Call (llamada de prueba)
- Call type: 3
- ID: Lift ID
- DATA: –
- Comentario: Llamada periódica EN 81-28 (≈ cada 72 h)
Rescue process ended
- Call type: 2
- ID: Lift ID
- DATA: 500
- Comentario: Fin de rescate / fin de alarma
Button Error
- Call type: 2
- ID: Lift ID
- DATA: 800
- Comentario: Fallo de pulsador de alarma
Button Fixed
- Call type: 2
- ID: Lift ID
- DATA: 801
- Comentario: Pulsador vuelve a estado correcto
Audio Error
- Call type: 2
- ID: Lift ID
- DATA: 200
- Comentario: Fallo de audio (micrófono/altavoz)
Audio Fixed
- Call type: 2
- ID: Lift ID
- DATA: 201
- Comentario: Recuperación del sistema de audioEjemplo de trama P100 (simplificada):
2 87654321 500 → Fin de rescate para el ascensor con ID 87654321.Estos eventos forman el “core” interoperable del protocolo P100: son los más extendidos, los mejor documentados y los que, en general, una CRA puede esperar recibir y entender sin configuraciones especiales.
Extensiones y eventos técnicos adicionales
Más allá de este núcleo, distintos fabricantes han añadido extensiones propias manteniendo la misma estructura Call type – ID – DATA. Algunos ejemplos documentados incluyen:
avisos por contadores de viajes,
movimientos de puertas,
estados de fuera de servicio / vuelta a servicio,
eventos relacionados con alimentación eléctrica.
Estos códigos amplían la capacidad de supervisión, pero no están estandarizados y requieren que el receptor conozca exactamente su significado.
Nota importante sobre la variabilidad
Conviene dejar claro un punto clave:
Los valores de Call type y, sobre todo, de DATA pueden variar según fabricante y configuración.
No existe una tabla “oficial” P100.
Algunos fabricantes reutilizan códigos.
Otros añaden códigos alfanuméricos propios.
La interpretación final depende siempre de la CRA o plataforma receptora.
Por eso, cuando se trabaja con P100 en entornos reales, es fundamental verificar qué eventos están realmente soportados y cómo se interpretan, especialmente más allá del núcleo básico.
En el siguiente apartado aclaramos una duda muy habitual en el sector:
¿Qué es el CPC y su relación con el protocolo P100?
El CPC (Central Protocol Communication) es otro protocolo de transmisión de eventos usado en sistemas de alarma y, especialmente, en telefonía de emergencia de ascensores. Al igual que P100, no es una norma oficial, sino un estándar de facto surgido de la práctica industrial para resolver el mismo problema: identificar automáticamente una llamada y su contexto en una central receptora.
Qué tienen en común P100 y CPC
P100 y CPC comparten más cosas de las que a menudo se piensa:
Ambos están basados en DTMF sobre canal de voz.
Ambos transmiten eventos cortos, no datos complejos.
Ambos envían la información al inicio de la llamada, antes o independientemente de la conversación de voz.
Ambos se usan para alarmas, llamadas de prueba y eventos técnicos.
Ninguno está definido por una norma EN, ISO o ETSI.
En esencia, resuelven el mismo problema con una filosofía muy parecida.
Diferencias clave entre CPC y P100
Donde empiezan a separarse es en el detalle técnico y en el ecosistema que los ha adoptado:
Longitud del identificador
P100 está pensado para IDs de hasta 8 dígitos.
CPC admite identificadores más largos (habitualmente hasta 16 dígitos), lo que lo hizo atractivo para ciertas CRA y sistemas más antiguos con numeraciones internas extensas.
Flexibilidad del formato
P100 es muy simple y rígido, con pocos tipos de llamada bien definidos.
CPC permite mayor variedad de códigos y estructuras, a costa de ser algo más complejo.
Uso histórico
P100 se ha impuesto sobre todo en el mundo del ascensor como protocolo abierto común.
CPC ha sido muy usado en centrales receptoras clásicas y en entornos donde ya existía infraestructura compatible.
Por qué suelen aparecer juntos
En la práctica, muchas centrales receptoras y plataformas declaran compatibilidad con:
P100 / CPC / Contact ID
Esto no significa que sean equivalentes, sino que:
el sistema puede decodificar varios formatos DTMF,
y adaptarse a lo que envíe el equipo de campo.
Por eso, en proyectos reales, P100 y CPC conviven, y la elección de uno u otro suele depender más de:
el fabricante del teléfono,
la CRA existente,
o la compatibilidad histórica,
que de una decisión técnica “pura”.
Relación real entre ambos
Es importante dejar claro que:
CPC no es una evolución formal de P100, ni P100 lo es de CPC.
Son protocolos hermanos, nacidos en el mismo contexto tecnológico.
Ambos responden a un mundo dominado por telefonía analógica y DTMF.
Esta relación explica por qué, cuando se analizan los problemas actuales de fiabilidad en redes IP o móviles, las limitaciones afectan por igual a P100 y a CPC: no es un problema de implementación concreta, sino de modelo de comunicación heredado.
Y con esto ya tenemos todo el contexto técnico necesario para la última pregunta, que es la realmente importante hoy:
¿Debería el protocolo P100 ser un estándar en la era digital?
El protocolo P100 cumplió muy bien su función en el contexto para el que fue diseñado: telefonía analógica, líneas estables y transmisión fiable de tonos DTMF. Durante años fue una solución sencilla, interoperable y suficiente para cumplir con los requisitos de la EN 81-28.
El problema es que el contexto tecnológico ha cambiado, pero el protocolo no.
El choque entre P100 y las redes actuales
Hoy, la mayoría de los sistemas de alarma de ascensores ya no funcionan sobre líneas analógicas puras. Operan sobre:
redes móviles (2G, 4G, LTE),
VoIP,
enlaces IP,
infraestructuras con compresión de audio y transcodificación.
Y aquí aparece el conflicto técnico de fondo:
P100 depende de que los tonos DTMF lleguen íntegros.
Las redes modernas no están diseñadas para garantizar eso.
Codecs de voz, supresión de silencios, jitter, pérdidas de paquetes o transcodificaciones intermedias pueden:
deformar los tonos,
hacerlos parcialmente ilegibles,
provocar decodificaciones erróneas,
o generar enganches de llamada y falsos estados.
Esto no es una cuestión teórica ni puntual: es una realidad operativa que afecta al día a día de muchas empresas de ascensores y centros de rescate.
El riesgo de seguir “forzando” P100
En la práctica, seguir usando P100 como si nada hubiera cambiado implica asumir riesgos claros:
llamadas de prueba que “se realizan” pero no se interpretan correctamente,
eventos técnicos que no llegan o llegan corruptos,
alarmas que se quedan colgadas esperando tonos,
dificultades de diagnóstico cuando algo falla.
El protocolo no tiene mecanismos propios de verificación, reintento o confirmación, porque nunca los necesitó en el entorno analógico para el que fue concebido.
Entonces, ¿hay que abandonar P100?
No necesariamente. Pero sí hay que ponerlo en su sitio.
En entornos analógicos puros, P100 sigue siendo una solución válida.
Como lenguaje lógico (estructura de eventos), sigue siendo comprensible y útil.
Como mecanismo de transporte basado en DTMF, empieza a mostrar límites claros.
Por eso, muchas soluciones modernas están optando por:
capturar la semántica P100,
convertirla en datos estructurados,
y transportarla por canales IP fiables (por ejemplo, MQTT, HTTPS, etc.).
De este modo, se mantiene la compatibilidad conceptual con P100, pero se elimina la fragilidad del transporte por audio.
Reflexión final
P100 no es “malo” ni “incorrecto”. Es un protocolo hijo de su tiempo. El problema aparece cuando se pretende usarlo sin adaptaciones en un entorno tecnológico para el que no fue diseñado.
La pregunta ya no debería ser:
“¿Cumple P100 la EN 81-28?”
Sino:
“¿Es razonable seguir confiando la seguridad de los usuarios a tonos DTMF en redes digitales modernas?”
Responder a eso con honestidad técnica es, probablemente, el siguiente paso que el sector del ascensor tiene que dar.