Que es realmente un MDT

Un terminal de datos móvil es una pantalla con conexión de datos dentro del vehículo. Esa es la versión corta y honesta. Historicamente era una laptop reforzada o una unidad fija en el tablero; hoy con la misma frecuencia es una tableta en un soporte, corriendo una aplicación suministrada por el proveedor de su software de despacho a través de una conexión celular o de radio para datos. El equipo no es la parte interesante. Lo que lo convierte en un MDT y no en simplemente un navegador en una tableta es que se comunica con su sistema de despacho asistido por computadora (CAD), de modo que la unidad en campo y el despachador en la consola ven el mismo registro de incidente.

Quitando el mercadeo, un MDT cumple tres funciones basicas. Recibe información del centro de despacho. Envía el estado de vuelta al centro de despacho. Y le da a la tripulación una forma de consultar material de referencia sin usar el radio. Todo lo demás que se le agregue es una variación de una de esas tres.

Que hace durante una llamada

Este es el flujo de trabajo que la mayoría de las tripulaciones reconoce una vez pasa la novedad. Llega una llamada. En lugar del despacho por voz, o junto a el, el incidente aparece en la pantalla: dirección, tipo de llamada, cualquier nota que el despachador haya escrito, y a menudo un mapa con la posición de la unidad y una ruta. La tripulación confirma recibido. A medida que avanza la llamada, el oficial o el conductor toca botones de estado en lugar de transmitir cada cambio: en camino, en el lugar, trasladando, disponible. Cada toque marca la hora en el registro del lado del despacho sin ocupar el canal.

Las funciones comunes se dividen así:

• Recepción del despacho. Dirección, tipo de llamada, calles transversales, notas del llamante, y cualquier alerta de peligro que el despachador haya adjuntado, entregadas como texto que se puede releer en lugar de una transmisión de voz que se escucho una sola vez.
• Botones de estado. El gran ahorro de tráfico de radio. En camino, en el lugar, libre, y así sucesivamente, registrados con marca de hora. Aquí vive buena parte del ahorro real de tiempo, porque los cambios de estado son constantes y repetitivos.
• Mapeo y rutas. Ver su propia posición, la ubicación del incidente, y una ruta sugerida. Útil en una zona que no conoce bien, y útil para la segunda unidad que debe posicionarse o llegar desde otra dirección.
• Acceso móvil a registros. Preplanes, ubicaciones de hidrantes, notas de ocupación, guías operativas estándar, e historial de incidentes previos para una dirección, todo accesible desde la cabina o en el lugar sin necesidad de llamar de vuelta a la estación.

Este último punto es donde un MDT deja de ser una comodidad de despacho y se convierte en una herramienta operativa. Un preplano que muestra la conexión del sistema contra incendios, la ubicación de la caja de llaves y donde están los materiales peligrosos vale más en el camino de ida que archivado en una carpeta en la estación. Pero esto solo funciona si el preplano existe, está actualizado, y de verdad está cargado en el sistema al que la pantalla puede acceder. Guarde esa idea, porque es el tema central de todo el artículo.

CAD-to-CAD y por qué le importa a la ayuda mutua

Todo lo anterior asume una sola agencia, un solo centro de despacho, un solo sistema CAD. Los incidentes reales no respetan esos límites. Usted acude en ayuda mutua a la jurisdicción vecina, o ellos acuden a la suya, y ahora dos centros de despacho tienen cada uno su propio CAD, su propia lista de unidades, y su propia imagen del mismo incidente. La integración CAD-to-CAD es el intento de conectar esos dos sistemas para que los datos del incidente crucen la frontera.

Cuando funciona, el valor es claro. Un centro vecino puede enviar un incidente directamente a su CAD en lugar de transmitirlo por teléfono, lo cual es más rápido y pierde menos información en el camino. Sus unidades que responden a la llamada de ellos pueden aparecer en su tablero con estado real. Ambos centros pueden ver que maquinas están comprometidas y en donde, algo que importa mucho durante un evento grande cuando todos toman recursos del mismo grupo de carros. Para un departamento pequeño que depende de la ayuda automática y mutua para completar una asignación, esto no es un lujo. Todo el sentido de un convenio de ayuda es que responda la unidad apropiada más cercana sin importar de que agencia sea, y CAD-to-CAD es la infraestructura que permite que los dos sistemas de despacho coordinen eso sin que una persona lea direcciones por teléfono.

Por qué la interoperabilidad es más difícil de lo que parece

Ahora la parte honesta. La interoperabilidad CAD-to-CAD entre agencias vecinas es real, existe en el campo, y es despareja y con frecuencia difícil de poner en marcha. No salga de una demostración de un proveedor creyendo que es solo marcar una casilla.

El problema empieza porque dos agencias rara vez usan el mismo software de despacho, e incluso cuando lo usan, lo configuran distinto. Los tipos de llamada no coinciden. Su codigo de incendio estructural es el codigo de incendio activo de ellos. Las convenciones de nombres de unidades difieren. Las definiciones de estado difieren, así que su “en el lugar” y el “llegada” de ellos pueden no corresponder de forma limpia. Los formatos de dirección y los datos de mapa subyacentes difieren, lo que significa que una ubicación que se geocodifica sin problemas en un sistema puede ubicarse en el lugar equivocado o fallar en validarse en el otro. Cada uno de esos desajustes tiene que traducirse, y alguien tiene que construir y mantener esa traducción.

Existen estándares de datos compartidos y convenciones de mensajería que hacen esto más alcanzable de lo que era hace una década, y el avance más amplio hacia la infraestructura del 911 de nueva generación (NG911) está empujando a los centros hacia sistemas más interconectados y orientados a datos que pueden transmitir información más completa, incluyendo mejores datos de ubicación del llamante, entre agencias. Esa dirección es real y ayuda. Pero los estándares describen como pueden comunicarse los sistemas; no garantizan que dos centros en particular, con dos proveedores en particular, en dos ciclos de presupuesto en particular, hayan hecho el trabajo de integración y lo mantengan al día. La gobernanza, el reparto de costos, y quien es responsable de la conexión cuando falla son tan parte del proyecto como la tecnología. Un enfoque regional, donde varios vecinos acuerdan convenciones en conjunto, tiende a funcionar mucho mejor que dos agencias uniendo un enlace entre si de forma aislada.

• Tipos de llamada y códigos desiguales que hay que mapear de una agencia a otra.
• Nombres de unidades y definiciones de estado distintos que rompen la imagen compartida si se traducen sin cuidado.
• Datos de dirección y mapa inconsistentes que pueden ubicar mal o rechazar una ubicación al cruzar el límite.
• Mantenimiento continuo, porque un cambio de configuración en cualquiera de los dos lados puede romper el enlace sin que nadie lo note.
• Gobernanza y costos, que suelen ser la verdadera razón por la que una integración prometedora nunca se concreta.

Nada de esto significa que CAD-to-CAD no valga la pena perseguirlo. Significa que debe tratarlo como un proyecto operativo regional con socios, no como una función que se compra, y debe hacer preguntas difíciles sobre quien lo mantiene antes de depender de el en una noche mala.

El problema de distracción que nadie muestra en la demostración

Una pantalla en la cabina ayuda a la tripulación y compite por su atención al mismo tiempo. Ambas cosas son ciertas. El mismo MDT que le permite al conductor ver la ruta también lo invita a leer notas del llamante, tocar el estado, y estudiar un mapa mientras la maquina avanza. Manejar en respuesta de emergencia ya es una de las cosas más peligrosas que hace su personal, y una pantalla interactiva brillante dentro del campo visual es un riesgo de distracción conocido. Fingir lo contrario no lo hace más seguro.

La buena noticia es que este es un problema manejable si se trata como un asunto de política y capacitación, no como un asunto de equipo. El carro tiene un conductor y un oficial por una razón. La misma disciplina que mantiene un celular fuera de las manos del conductor aplica al MDT: quien maneja no opera la pantalla, sin excepción. La interacción ocurre antes de que las ruedas se muevan, en un alto, o a través del oficial en el asiento del pasajero. Algunos sistemas pueden bloquear o simplificar la pantalla mientras el vehículo está en movimiento, y si el suyo puede hacerlo, usela. La posición de montaje también importa; una pantalla ubicada baja o a un lado es peor que una colocada donde una mirada rápida no signifique quitar la vista del camino por mucho tiempo.

El objetivo es sacar el trabajo rutinario del radio y llevarlo a los datos sin trasladarlo a los ojos del conductor. Si se equivoca en ese equilibrio, cambio un problema de congestion de canal por un riesgo de choque, y eso es un mal cambio.

La curaduria de lo que llega al carro

Más datos no es la meta. Los datos correctos en el momento correcto es la meta. Este es el error que convierte un MDT útil en uno saturado: la tentación de enviar todo a la pantalla solo porque la pantalla puede contenerlo.

Piense en el momento real de uso. En camino a una llamada, la tripulación puede asimilar un puñado de cosas: donde es, que es, que tiene de peligroso, y como entrar. Eso es, más o menos, todo. Una nota de despacho clara y corta vale más que un muro de historial autogenerado que nadie puede revisar mientras responde. Un preplano que abre directo en la única pagina que necesita el oficial primero en llegar es mejor que un documento de cuarenta paginas que hay que recorrer deslizando el dedo. La curaduria es el trabajo de decidir, con anticipación, que se gana un lugar frente a una tripulación que tiene segundos, no minutos.

• Mantenga las notas de despacho cortas y estructuradas. Peligros y acceso primero. Esto es tanto un asunto de flujo de trabajo y capacitación del despachador como de tecnología.
• Haga que los preplanes sean fáciles de revisar rápido. La primera pantalla debe llevar lo esencial de seguridad de vida y acceso; el detalle puede quedar más abajo para la tripulación que tenga tiempo en el lugar.
• Depure la biblioteca de referencia. Si un documento está desactualizado, es peor que no tenerlo, porque la gente confia en lo que la pantalla le muestra.
• Ajuste el contenido según el rol y el momento. Lo que el conductor necesita, lo que el oficial necesita, y lo que solo es útil después de llegar son tres listas distintas.

La curaduria no es vistosa y es donde se gana o se pierde la mayor parte del valor real. El equipo es el mismo sin importar si el contenido detrás de el es disciplinado o un cajón desordenado. Sus tripulaciones solo confiaran en la pantalla si lo que les muestra se ha mantenido honesto.

?Vale la pena para un departamento pequeño?

Respuesta directa: depende, y la versión honesta de esa respuesta es menos emocionante que la versión de ventas. Los MDT rinden más donde se cumplen dos condiciones. Primero, tiene suficiente volumen de llamadas y tráfico de radio para que sacar los cambios de estado del aire realmente alivie la congestion y agilice las cosas. Segundo, responde con suficiente frecuencia a territorio poco familiar, o maneja suficientes preplanes que valga la pena llevar, de modo que el mapeo y la referencia en cabina ayuden de verdad a la tripulación. Un departamento combinado y ocupado que cubre una mezcla de distritos obtiene más de un MDT que un departamento de bajo volumen donde cada miembro ya conoce de memoria cada calle y cada edificio.

Frente a eso, pese los costos reales, que no son solo las tabletas. Esta la conectividad de datos recurrente. Esta el trabajo de integración y configuración con su centro de despacho, que puede no controlar por completo si lo despacha un centro compartido o del condado. Esta el montaje, la energía, y la realidad de que el equipo reforzado en un vehículo con vibración tiene una vida útil limitada. Y esta el trabajo de capacitación y política para usarlo con seguridad, que no es opcional.

Un camino razonable para un departamento más pequeño es empezar de forma acotada. Haga una prueba piloto en la maquina más ocupada. Compruebe primero el valor de los botones de estado y el mapeo, porque son las funciones que se rentabilizan más rápido y dependen menos de que usted tenga una biblioteca de registros madura. Agregue el acceso móvil a preplanes y registros una vez tenga registros que valga la pena enviar. Trate CAD-to-CAD como una conversación regional separada y posterior con su centro de despacho y sus socios de ayuda mutua, no como un requisito desde el primer día. Y este dispuesto a concluir que, para su volumen de llamadas y personal, un radio bien manejado y un buen conjunto de carpetas de estación todavía funciona mejor que un programa de pantallas que no puede mantener. Esa es una respuesta legitima, no un fracaso.

La parte que importa más que el equipo

Si hay algo que llevarse de todo esto, es lo siguiente: el terminal es una ventana, y una ventana solo es tan buena como lo que hay del otro lado. Un MDT que muestra un preplano desactualizado, un tipo de llamada mal codificado, o un error de mapeo no es neutral. Engaña activamente, porque las tripulaciones confian razonablemente en lo que la pantalla oficial les dice. La calidad de los datos y el flujo de trabajo del despachador determinan si toda la inversión ayuda o perjudica, y ambas cosas están corriente arriba de cualquier dispositivo que instale.

Por eso la disciplina cotidiana importa más que la demostración. ?Están sus preplanes actualizados? ?Están limpios sus datos de direcciones e hidrantes? ?Sus despachadores escriben notas que una tripulación en camino pueda usar de verdad en tres segundos? ?Están sus tipos de llamada y estados de unidad definidos con suficiente consistencia para sobrevivir a compartirse con un vecino? Haga bien eso y hasta una instalación modesta de MDT se justifica. Hágalo mal y el terminal más capaz del mercado solo entrega información mala más rápido.