Checklist para pilotar un RTLS en metro

Los pilotos de localización en interiores fallan casi siempre por las mismas razones, y casi ninguna es tecnológica. Fallan porque nadie comprobó si los puntos de acceso servían, porque no se pactó qué significaba «funciona», o porque el comité de empresa se enteró tarde.

Esta es la lista de lo que hay que tener resuelto antes de empezar, ordenada por el momento en que hay que resolverlo.

Antes de firmar nada

1. Cuántos puntos de acceso pueden activar FTM

Es la comprobación que decide el proyecto entero, y se hace con un inventario, no con un piloto.

La medición por tiempo de vuelo necesita que el punto de acceso soporte el protocolo FTM y lo tenga habilitado. La mayoría de equipos 802.11ac y 802.11ax profesionales lo soportan, pero viene desactivado de fábrica y hay que habilitarlo desde la controladora.

Pide a tu área de red el listado de modelos y firmware por estación. Si la respuesta es que la mayoría del parque no lo soporta, la conversación cambia por completo: o hay renovación prevista, o este no es el sistema adecuado. Mejor saberlo en la semana cero.

2. Qué terminales hay realmente en servicio

No qué terminales figuran en el inventario: cuáles llevan encima los agentes en el turno de noche del sábado.

Hace falta Android 10 o superior con chipset compatible. La heterogeneidad de flota es normal, y no es un problema si se conoce: se cierra una matriz de modelos homologados probándolos, y los que no entran se sustituyen o se dejan fuera del alcance del piloto.

3. Qué decisión operativa vas a tomar con el dato

Suena a pregunta de consultor, pero es la que evita comprar precisión que no necesitas.

Si la decisión es «a qué punto mando el apoyo y por qué acceso entra», con saber la zona y el sentido de circulación sobra. Si la decisión requiere distinguir dos posiciones separadas por medio metro, estás en otro problema y necesitas otra tecnología.

Escríbelo en una frase. Esa frase determina los criterios de aceptación.

4. Con qué sistema se va a integrar

Un portal más al que nadie mira no cambia nada. El dato tiene que llegar al sistema donde tu gente ya trabaja: el gestor de incidencias, el mapa operacional, el cuadro de mando.

Averigua antes si ese sistema admite entrada por API o por webhook, y quién lo mantiene. Si es un integrador externo, métele en la conversación desde el principio.

Antes de instalar

5. Habla con la representación de los trabajadores

Antes. Siempre antes.

Localizar personal es tratar un dato personal en contexto laboral, y el artículo 90 de la LOPDGDD exige información previa expresa, clara e inequívoca a la plantilla y a sus representantes. Al margen de la obligación legal, es lo que decide si el sistema se usa o si los teléfonos se quedan en la taquilla.

El encuadre importa: no es «vamos a saber dónde estáis», es «si te pasa algo en un túnel, queremos poder llegar antes». Pero solo funciona si el sistema después hace exactamente eso.

Lo tienes desarrollado en ¿Es legal geolocalizar a un trabajador?.

6. Pacta los criterios de aceptación por escrito y con números

Esta es la comprobación que evita la discusión del final. Sin umbrales numéricos acordados, «ha funcionado» es una opinión.

Mínimo a pactar:

| Criterio | Umbral | |---|---| | Precisión media en estación | valor en metros | | Latencia de publicación | valor en segundos | | Disponibilidad durante el piloto | porcentaje | | Terminales concurrentes | número | | Autonomía del terminal | un turno completo sin recargar | | Hallazgos críticos de seguridad | cero abiertos al cierre |

Y define cómo se mide cada uno: con qué puntos de referencia, en cuántas estaciones, en qué franjas horarias y quién levanta acta.

7. Elige bien el alcance

Una línea o un conjunto de estaciones. Ni una sola estación —no genera evidencia extrapolable— ni la red entera —no cabe en el calendario ni en el presupuesto de un piloto.

Elige la línea que tenga la mezcla más representativa: estaciones grandes y pequeñas, algún intercambiador, algún tramo problemático. Si eliges solo lo fácil, el resultado no te sirve para decidir.

8. Pasa el filtro de ciberseguridad antes, no después

Tu área de sistemas va a evaluarlo igual. Que lo haga en la semana uno y no en la semana diez.

Lo que hay que pedirle al proveedor: arquitectura y flujos de datos, controles de identidad y acceso, cifrado, registro auditable, resultado de auditoría externa reciente, proceso de gestión de vulnerabilidades y compromiso de notificación de incidentes. Está desarrollado en qué exige NIS2.

Durante el piloto

9. Mide contra puntos de referencia conocidos

La precisión no se comprueba mirando si el punto del mapa «parece bien». Se comprueba con puntos de referencia marcados sobre el plano, recorridos con guion y registro de lo que el sistema decía en cada instante.

Conviene hacerlo a ciego o a simple ciego: quien recorre no ve la lectura del sistema mientras la toma.

10. Mide en las condiciones malas, no en las buenas

Un andén vacío a las once de la mañana no es el escenario que importa. Los que importan:

• Hora punta, con el andén lleno de gente absorbiendo señal.
• Con un tren parado en la estación ocupando media planta.
• En los tramos donde solo hay un punto de acceso a la vista.
• En transiciones entre niveles y en pasillos de correspondencia.

Si el sistema aguanta ahí, aguanta en el resto. Si solo se prueba en condiciones favorables, el número que salga no vale para decidir.

11. Comprueba qué hace el sistema cuando no sabe

Es la prueba que más dice sobre la calidad de un sistema y la que casi nadie hace.

Métete en una zona sin cobertura y mira qué muestra el portal. ¿Marca la lectura como degradada? ¿Avisa de que ese terminal lleva tiempo sin reportar? ¿O te sigue enseñando la última posición conocida como si fuera actual?

Un sistema que no distingue entre «está aquí» y «estaba aquí hace ocho minutos» es peor que no tener sistema, porque te da confianza sobre un dato falso.

12. Prueba la autonomía en un turno real

No en una prueba de laboratorio de dos horas. Un turno completo, con el terminal haciendo su trabajo habitual además de reportar posición.

Si el teléfono no llega al final del turno, el sistema no se va a usar, por muy preciso que sea.

Al cerrar

El entregable del piloto no es una demo bonita. Es un informe con los números medidos contra los criterios pactados, las condiciones en que se midieron y las no conformidades encontradas con su plan de acción.

Ese documento es lo que tu comité puede llevar al expediente de compra. Sin él, la decisión vuelve a apoyarse en impresiones.

Para seguir leyendo

• Qué hace falta de verdad para desplegar, con las cuatro fases y los entregables
• RTLS con etiquetas o sobre smartphone