pág. 8298
SOLUCIÓN DE INTERNET DE LAS COSAS
PARA EL MONITOREO EN TIEMPO REAL
DE ZONAS DE RIESGO MEDIANTE
VEHÍCULO TELEOPERADO Y
APLICACIÓN WEB
INTERNET OF THINGS SOLUTION FOR REAL-TIME MONITORING OF
HAZARDOUS AREAS USING A TELEOPERATED VEHICLE AND A WEB
APPLICATION
José de Jesús Jiménez García
Universidad La Salle Pachuca
Wendy Daniel Martínez
Universidad Politécnica Metropolitana de Hidalgo
Alejandro Benítez Morales
Universidad Autónoma del Estado de Hidalgo
pág. 8299
DOI: https://doi.org/10.37811/cl_rcm.v9i5.20174
Solución de Internet de las Cosas para el monitoreo en tiempo real de zonas
de riesgo mediante vehículo teleoperado y aplicación Web
José de Jesús Jiménez García1
jose.jimenez@lasallep.mx
https://orcid.org/0009-0004-7632-8990
Universidad La Salle Pachuca
San Juan Tilcuautla Hidalgo, México
Wendy Daniel Martínez
wdaniel@upmh.edu.mx
https://orcid.org/0000-0002-4455-940X
Universidad Politécnica Metropolitana de
Hidalgo
Tolcayuca Hidalgo, México
Alejandro Benítez Morales
abenitez@uaeh.edu.mx
https://orcid.org/0000-0002-9743-0810
Universidad Autónoma del Estado de Hidalgo
Pachuca de Soto Hidalgo, México
RESUMEN
Esta investigación presenta el desarrollo y la evaluación inicial de una solución de Internet de las
Cosas (IoT) para el monitoreo en tiempo real de zonas de riesgo, compuesta por un vehículo
teleoperado sensorizado y una aplicación web para visualización y control. El proyecto se enmarca
como investigación aplicada y ha sido desarrollado en tres fases: (i) análisis de necesidades, diseño
inicial del vehículo y del modelo/arquitectura de datos, (ii) modelado del prototipo físico y elaboración
del mockup de la interfaz, y (iii) programación de la base de datos en hosting, desarrollo inicial del
backend/frontend e inicio de pruebas de comunicación entre el ESP32 y el servidor. La plataforma
integra sensores ambientales (p. ej., distancia, temperatura, gas y humedad), con envío de datos y
recepción de comandos por Wi-fi mediante protocolos HTTP/MQTT5.0 mediante un panel web con
indicadores, alertas y gráficas en tiempo real. Se documenta, además, el ajuste de materiales y del
diseño mecánico-electrónico del carro a raíz de hallazgos experimentales (sobrecalentamiento) y se
establecen las bases para la validación funcional en entornos de prueba. La propuesta busca reducir la
exposición humana en escenarios peligrosos, aportar un diseño replicable y sentar la base de una
arquitectura escalable para futura integración y despliegue.
Palabras clave: Internet de las Cosas (IoT); monitoreo en tiempo real; zonas de riesgo; vehículo
teleoperado; aplicación web.
1 Autor principal
Correspondencia: jose.jimenez@lasallep.mx
DOI: https://doi.org/10.37811/cl_rcm.v9i5.20174
Solución de Internet de las Cosas para el monitoreo en tiempo real de zonas
de riesgo mediante vehículo teleoperado y aplicación Web
José de Jesús Jiménez García1
jose.jimenez@lasallep.mx
https://orcid.org/0009-0004-7632-8990
Universidad La Salle Pachuca
San Juan Tilcuautla Hidalgo, México
Wendy Daniel Martínez
wdaniel@upmh.edu.mx
https://orcid.org/0000-0002-4455-940X
Universidad Politécnica Metropolitana de
Hidalgo
Tolcayuca Hidalgo, México
Alejandro Benítez Morales
abenitez@uaeh.edu.mx
https://orcid.org/0000-0002-9743-0810
Universidad Autónoma del Estado de Hidalgo
Pachuca de Soto Hidalgo, México
RESUMEN
Esta investigación presenta el desarrollo y la evaluación inicial de una solución de Internet de las
Cosas (IoT) para el monitoreo en tiempo real de zonas de riesgo, compuesta por un vehículo
teleoperado sensorizado y una aplicación web para visualización y control. El proyecto se enmarca
como investigación aplicada y ha sido desarrollado en tres fases: (i) análisis de necesidades, diseño
inicial del vehículo y del modelo/arquitectura de datos, (ii) modelado del prototipo físico y elaboración
del mockup de la interfaz, y (iii) programación de la base de datos en hosting, desarrollo inicial del
backend/frontend e inicio de pruebas de comunicación entre el ESP32 y el servidor. La plataforma
integra sensores ambientales (p. ej., distancia, temperatura, gas y humedad), con envío de datos y
recepción de comandos por Wi-fi mediante protocolos HTTP/MQTT5.0 mediante un panel web con
indicadores, alertas y gráficas en tiempo real. Se documenta, además, el ajuste de materiales y del
diseño mecánico-electrónico del carro a raíz de hallazgos experimentales (sobrecalentamiento) y se
establecen las bases para la validación funcional en entornos de prueba. La propuesta busca reducir la
exposición humana en escenarios peligrosos, aportar un diseño replicable y sentar la base de una
arquitectura escalable para futura integración y despliegue.
Palabras clave: Internet de las Cosas (IoT); monitoreo en tiempo real; zonas de riesgo; vehículo
teleoperado; aplicación web.
1 Autor principal
Correspondencia: jose.jimenez@lasallep.mx
pág. 8300
Internet of Things Solution for Real-Time Monitoring of Hazardous Areas
Using a Teleoperated Vehicle and a Web Application
ABSTRACT
This study presents the development and initial evaluation of an Internet of Things (IoT) solution for
real-time monitoring of hazardous areas, composed of a sensor-equipped, teleoperated vehicle and a
web application for visualization and control. Framed as applied research, the project was carried out
in three phases: (i) needs analysis and the initial design of the vehicle and the data model/architecture;
(ii) physical prototyping and the creation of the interface mockup; and (iii) database deployment on a
hosting service, initial backend/frontend development, and early communication tests between the
ESP32 and the server. The platform integrates environmental sensors (e.g., distance, temperature, gas,
and humidity), supports data transmission and command reception over Wi-Fi using HTTP/MQTT
5.0, and provides a web dashboard with indicators, alerts, and real-time charts. The work also
documents material selections and electro-mechanical design adjustments to the vehicle prompted by
experimental findings (overheating), laying the groundwork for functional validation in test
environments. Overall, the proposal aims to reduce human exposure in dangerous scenarios, deliver a
replicable design, and establish a scalable architecture for future integration and deployment.
Keywords: Internet of Things (IoT); real-time monitoring; hazardous areas; teleoperated vehicle; web
application.
Artículo recibido 02 setiembre 2025
Aceptado para publicación: 29 setiembre 2025
Internet of Things Solution for Real-Time Monitoring of Hazardous Areas
Using a Teleoperated Vehicle and a Web Application
ABSTRACT
This study presents the development and initial evaluation of an Internet of Things (IoT) solution for
real-time monitoring of hazardous areas, composed of a sensor-equipped, teleoperated vehicle and a
web application for visualization and control. Framed as applied research, the project was carried out
in three phases: (i) needs analysis and the initial design of the vehicle and the data model/architecture;
(ii) physical prototyping and the creation of the interface mockup; and (iii) database deployment on a
hosting service, initial backend/frontend development, and early communication tests between the
ESP32 and the server. The platform integrates environmental sensors (e.g., distance, temperature, gas,
and humidity), supports data transmission and command reception over Wi-Fi using HTTP/MQTT
5.0, and provides a web dashboard with indicators, alerts, and real-time charts. The work also
documents material selections and electro-mechanical design adjustments to the vehicle prompted by
experimental findings (overheating), laying the groundwork for functional validation in test
environments. Overall, the proposal aims to reduce human exposure in dangerous scenarios, deliver a
replicable design, and establish a scalable architecture for future integration and deployment.
Keywords: Internet of Things (IoT); real-time monitoring; hazardous areas; teleoperated vehicle; web
application.
Artículo recibido 02 setiembre 2025
Aceptado para publicación: 29 setiembre 2025
pág. 8301
INTRODUCCIÓN
Esta investigación aborda el desarrollo de una solución de Internet de las Cosas (IoT) para el
monitoreo en tiempo real de zonas de riesgo, compuesta por un vehículo teleoperado con
sensorización ambiental y una aplicación web para visualización, control y alertamiento. El problema
de investigación se centra en la exposición humana a entornos peligrosos y en la limitación de
esquemas de inspección tradicionales, que suelen ser lentos, puntuales o inseguros. La teleoperación y
la robotización han demostrado reducir la presencia directa de personal en escenarios peligrosos y
facilitar la recolección sistemática de datos para la toma de decisiones, según la literatura pionera en
robótica de desastres. (Murphy, 2014; Gentile et al., 2023; López Pulgarín et al., 2022)
La relevancia de la investigación deriva de la capacidad del IoT para integrar sensores,
comunicaciones y análisis con el fin de ofrecer visibilidad inmediata y alertas accionables. Para
sustentar el diseño, se adoptaron arquitecturas por capas ampliamente aceptadas —percepción/red,
middleware/servicios y aplicación— y un enfoque cloud/edge pragmático (Shi, Cao, Zhang, Li, & Xu,
2016), como se describe en encuestas fundacionales y de referencia en el campo (Atzori et al., 2010;
Gubbi et al., 2013; Al-Fuqaha et al., 2015). Estas obras explican la organización modular del IoT y
orientan decisiones de escalabilidad, mantenibilidad e interoperabilidad. Véanse figuras1 a la 3.
Figura 1. Interfaz de acceso principal
INTRODUCCIÓN
Esta investigación aborda el desarrollo de una solución de Internet de las Cosas (IoT) para el
monitoreo en tiempo real de zonas de riesgo, compuesta por un vehículo teleoperado con
sensorización ambiental y una aplicación web para visualización, control y alertamiento. El problema
de investigación se centra en la exposición humana a entornos peligrosos y en la limitación de
esquemas de inspección tradicionales, que suelen ser lentos, puntuales o inseguros. La teleoperación y
la robotización han demostrado reducir la presencia directa de personal en escenarios peligrosos y
facilitar la recolección sistemática de datos para la toma de decisiones, según la literatura pionera en
robótica de desastres. (Murphy, 2014; Gentile et al., 2023; López Pulgarín et al., 2022)
La relevancia de la investigación deriva de la capacidad del IoT para integrar sensores,
comunicaciones y análisis con el fin de ofrecer visibilidad inmediata y alertas accionables. Para
sustentar el diseño, se adoptaron arquitecturas por capas ampliamente aceptadas —percepción/red,
middleware/servicios y aplicación— y un enfoque cloud/edge pragmático (Shi, Cao, Zhang, Li, & Xu,
2016), como se describe en encuestas fundacionales y de referencia en el campo (Atzori et al., 2010;
Gubbi et al., 2013; Al-Fuqaha et al., 2015). Estas obras explican la organización modular del IoT y
orientan decisiones de escalabilidad, mantenibilidad e interoperabilidad. Véanse figuras1 a la 3.
Figura 1. Interfaz de acceso principal
pág. 8302
Figura 2. Identificación de las zonas de riesgo (señales recibidas por la cámara del carro)
Figura 3. Control del carro desde la aplicación Web para monitoreo controlado
En el plano de conectividad, el sistema emplea HTTP y MQTT 5.0 para intercambio de telemetría y
comandos. MQTT 5.0 es un protocolo publish/subscribe ligero, estandarizado por OASIS,
ampliamente recomendado para contextos M2M/IoT con recursos y ancho de banda limitados; su
modelo desacoplado favorece la distribución eficiente de eventos y la gestión de alertas (OASIS,
2019; Al-Fuqaha et al., 2015). En el hardware, se selecciona ESP32 por sus capacidades Wi-
Fi/Bluetooth integradas, bajo consumo de electricidad y soporte maduro, conforme a la hoja de datos
vigente de Espressify y documentación de módulos actuales. (Espressif Systems, 2025a, 2025b;
OASIS Open 2019)
El marco teórico–técnico que guía la solución combina: (i) arquitecturas IoT n-capas para desacoplar
datos, lógica, presentación y servicios; (ii) modelo de datos relacional para gestionar entidades
(usuarios, vehículo, sensores, alertas) y trazabilidad histórica; y (iii) HCI/UX para tableros que
Figura 2. Identificación de las zonas de riesgo (señales recibidas por la cámara del carro)
Figura 3. Control del carro desde la aplicación Web para monitoreo controlado
En el plano de conectividad, el sistema emplea HTTP y MQTT 5.0 para intercambio de telemetría y
comandos. MQTT 5.0 es un protocolo publish/subscribe ligero, estandarizado por OASIS,
ampliamente recomendado para contextos M2M/IoT con recursos y ancho de banda limitados; su
modelo desacoplado favorece la distribución eficiente de eventos y la gestión de alertas (OASIS,
2019; Al-Fuqaha et al., 2015). En el hardware, se selecciona ESP32 por sus capacidades Wi-
Fi/Bluetooth integradas, bajo consumo de electricidad y soporte maduro, conforme a la hoja de datos
vigente de Espressify y documentación de módulos actuales. (Espressif Systems, 2025a, 2025b;
OASIS Open 2019)
El marco teórico–técnico que guía la solución combina: (i) arquitecturas IoT n-capas para desacoplar
datos, lógica, presentación y servicios; (ii) modelo de datos relacional para gestionar entidades
(usuarios, vehículo, sensores, alertas) y trazabilidad histórica; y (iii) HCI/UX para tableros que
pág. 8303
optimizan la conciencia situacional (dashboards con señales preatencionales y jerarquía de alertas),
mitigando la fatiga por notificaciones (Nielsen Norman Group, 2017; 2022). La arquitectura n-capas y
el modelado de datos se documentan como eje del diseño web, con capas de datos, lógica,
presentación y servicios orientadas a escalabilidad y disponibilidad. Véanse figuras 4 y 5.
Figura 4. Arquitectura de n-capas (datos, lógica, presentación y servicios) de la solución IoT.
Figura 5. Modelo entidad-relación para usuarios, vehículo, sensores/datos y alertas
optimizan la conciencia situacional (dashboards con señales preatencionales y jerarquía de alertas),
mitigando la fatiga por notificaciones (Nielsen Norman Group, 2017; 2022). La arquitectura n-capas y
el modelado de datos se documentan como eje del diseño web, con capas de datos, lógica,
presentación y servicios orientadas a escalabilidad y disponibilidad. Véanse figuras 4 y 5.
Figura 4. Arquitectura de n-capas (datos, lógica, presentación y servicios) de la solución IoT.
Figura 5. Modelo entidad-relación para usuarios, vehículo, sensores/datos y alertas
pág. 8304
Respecto a antecedentes y estado del arte, además de las encuestas de IoT citadas, la literatura en
teleoperación destaca los desafíos de latencia, pérdida de paquetes y ancho de banda, e identifica
estrategias de mitigación basadas en control, predicción y diseño de interfaz (Farajiparvar et al., 2020).
En dominios afines, por ejemplo vehículos conectados, se subraya que la latencia de red condiciona la
seguridad y la eficacia operacional, con líneas de investigación activas en compensación y control
robusto. Estas consideraciones conceptuales justifican la instrumentación de métricas como: retardo
extremo a extremo, tasa de actualización, pérdida de paquetes y tiempo de respuesta a comandos
durante la validación del prototipo. (López Pulgarín et al., 2022)
El contexto de la investigación —monitoreo ambiental y de seguridad en zonas de riesgo— demanda
instrumentación móvil robusta y visualización en tiempo real. En la Fase 1, el equipo identificó
necesidades y definió tanto el modelo/arquitectura de datos como el diseño inicial del vehículo; en la
Fase 2, se avanzó en el modelado mecánico y en el mockup de la interfaz (dashboard, sensores,
control, historial y alertas); en la Fase 3 se implementan ESP32, base de datos en hosting y pruebas de
comunicación con la App Web. Estos hitos confirman una ruta de maduración tecnológica consistente.
(Gentile et al., 2023)
En la interfaz propuesta, el mockup organiza la navegación (Dashboard, Sensores, Control, Historial,
Alertas), integra tarjetas semaforizadas, gráficas en tiempo real y paneles de control del vehículo con
funciones de refresco automático y alertas por umbral; el mockup se usa además como artefacto de
validación temprana con usuarios/asesores y para alinear equipos. En la fase de integración se verificó
la factibilidad de la arquitectura web con peticiones HTTP desde el ESP32 y se priorizan módulos de
dashboard, control y autenticación básica. (OASIS Open, 2019)
La seguridad es un requisito transversal. Aunque el prototipo está en etapa temprana, ya se contemplan
prácticas como validación del lado servidor, aplicación de HTTPS, hash de contraseñas y organización
modular en línea con el NISTIR 8259A (capacidades para dispositivos IoT) y con las guías OWASP
(IoT Top 10) que insisten en endurecer credenciales, proteger datos en tránsito/en reposo y asegurar
mecanismos de actualización. (ETSI, 2020; OASIS Open, 2019)
Respecto a antecedentes y estado del arte, además de las encuestas de IoT citadas, la literatura en
teleoperación destaca los desafíos de latencia, pérdida de paquetes y ancho de banda, e identifica
estrategias de mitigación basadas en control, predicción y diseño de interfaz (Farajiparvar et al., 2020).
En dominios afines, por ejemplo vehículos conectados, se subraya que la latencia de red condiciona la
seguridad y la eficacia operacional, con líneas de investigación activas en compensación y control
robusto. Estas consideraciones conceptuales justifican la instrumentación de métricas como: retardo
extremo a extremo, tasa de actualización, pérdida de paquetes y tiempo de respuesta a comandos
durante la validación del prototipo. (López Pulgarín et al., 2022)
El contexto de la investigación —monitoreo ambiental y de seguridad en zonas de riesgo— demanda
instrumentación móvil robusta y visualización en tiempo real. En la Fase 1, el equipo identificó
necesidades y definió tanto el modelo/arquitectura de datos como el diseño inicial del vehículo; en la
Fase 2, se avanzó en el modelado mecánico y en el mockup de la interfaz (dashboard, sensores,
control, historial y alertas); en la Fase 3 se implementan ESP32, base de datos en hosting y pruebas de
comunicación con la App Web. Estos hitos confirman una ruta de maduración tecnológica consistente.
(Gentile et al., 2023)
En la interfaz propuesta, el mockup organiza la navegación (Dashboard, Sensores, Control, Historial,
Alertas), integra tarjetas semaforizadas, gráficas en tiempo real y paneles de control del vehículo con
funciones de refresco automático y alertas por umbral; el mockup se usa además como artefacto de
validación temprana con usuarios/asesores y para alinear equipos. En la fase de integración se verificó
la factibilidad de la arquitectura web con peticiones HTTP desde el ESP32 y se priorizan módulos de
dashboard, control y autenticación básica. (OASIS Open, 2019)
La seguridad es un requisito transversal. Aunque el prototipo está en etapa temprana, ya se contemplan
prácticas como validación del lado servidor, aplicación de HTTPS, hash de contraseñas y organización
modular en línea con el NISTIR 8259A (capacidades para dispositivos IoT) y con las guías OWASP
(IoT Top 10) que insisten en endurecer credenciales, proteger datos en tránsito/en reposo y asegurar
mecanismos de actualización. (ETSI, 2020; OASIS Open, 2019)
pág. 8305
Objetivo general
Desarrollar una solución IoT para el monitoreo en tiempo real de zonas de riesgo, integrando un
vehículo teleoperado con sensorización ambiental y una aplicación web que permita visualización,
control y generación de alertas operativas.
Hipótesis técnica
Una arquitectura IoT basada en ESP32 + HTTP/MQTT + App Web n-capas permite comunicación
bidireccional estable y visualización en tiempo real con alertas por umbral, soportando decisiones
oportunas y reduciendo la exposición humana en entornos peligrosos. (Sustento: estandarización
MQTT 5.0; arquitectura IoT por capas; evidencia de teleoperación).
METODOLOGÍA
Enfoque y tipo de investigación
El estudio adopta un enfoque mixto: (a) cuantitativo para medir el desempeño técnico del sistema,
como: latencia, pérdida de paquetes, tasa de actualización, tiempo de respuesta, autonomía energética,
y (b) cualitativo para valorar la experiencia de uso del panel web y del control del vehículo mediante
entrevistas semiestructuradas y escalas estandarizadas. El tipo de investigación es aplicativo–
descriptivo, con alcances exploratorios propios de una evaluación inicial de prototipo. (López Pulgarín
et al., 2022)
Diseño metodológico
Se implementa un diseño cuasi-experimental en entorno controlado de laboratorio con medidas
repetidas sobre el mismo sistema, complementado por un estudio transversal de usabilidad con
usuarios. Las pruebas técnicas se realizan en tres iteraciones (I1–I3) que siguen la maduración del
prototipo (Fase 1–3). En cada iteración se aplican protocolos de prueba definidos y se documentan
ajustes al hardware/software.
Contexto y escenarios de prueba
Los ensayos se llevan a cabo en un espacio de pruebas internas para simular condiciones operativas
básicas: obstáculos para el vehículo, variaciones de distancia, fuentes de ruido/temperaturas
moderadas y un punto de acceso Wi-Fi dedicado. Se consideran dos perfiles de red: Red-A
Objetivo general
Desarrollar una solución IoT para el monitoreo en tiempo real de zonas de riesgo, integrando un
vehículo teleoperado con sensorización ambiental y una aplicación web que permita visualización,
control y generación de alertas operativas.
Hipótesis técnica
Una arquitectura IoT basada en ESP32 + HTTP/MQTT + App Web n-capas permite comunicación
bidireccional estable y visualización en tiempo real con alertas por umbral, soportando decisiones
oportunas y reduciendo la exposición humana en entornos peligrosos. (Sustento: estandarización
MQTT 5.0; arquitectura IoT por capas; evidencia de teleoperación).
METODOLOGÍA
Enfoque y tipo de investigación
El estudio adopta un enfoque mixto: (a) cuantitativo para medir el desempeño técnico del sistema,
como: latencia, pérdida de paquetes, tasa de actualización, tiempo de respuesta, autonomía energética,
y (b) cualitativo para valorar la experiencia de uso del panel web y del control del vehículo mediante
entrevistas semiestructuradas y escalas estandarizadas. El tipo de investigación es aplicativo–
descriptivo, con alcances exploratorios propios de una evaluación inicial de prototipo. (López Pulgarín
et al., 2022)
Diseño metodológico
Se implementa un diseño cuasi-experimental en entorno controlado de laboratorio con medidas
repetidas sobre el mismo sistema, complementado por un estudio transversal de usabilidad con
usuarios. Las pruebas técnicas se realizan en tres iteraciones (I1–I3) que siguen la maduración del
prototipo (Fase 1–3). En cada iteración se aplican protocolos de prueba definidos y se documentan
ajustes al hardware/software.
Contexto y escenarios de prueba
Los ensayos se llevan a cabo en un espacio de pruebas internas para simular condiciones operativas
básicas: obstáculos para el vehículo, variaciones de distancia, fuentes de ruido/temperaturas
moderadas y un punto de acceso Wi-Fi dedicado. Se consideran dos perfiles de red: Red-A
pág. 8306
(laboratorio estable) y Red-B (carga/ruido moderado) para observar la robustez de la comunicación
HTTP/MQTT 5.0.
Población, muestra y muestreo
La población objetivo son operadores potenciales de monitoreo (estudiantes avanzados y/o personal
técnico). La muestra para la evaluación de usabilidad está compuesta por n = 12 participantes (≥18
años), seleccionados mediante muestreo no probabilístico por conveniencia y criterios de experiencia
básica en herramientas informáticas y navegación web.
Criterios de inclusión y exclusión
Para la inclusión: (i) mayores de 18 años; (ii) alfabetización digital básica; (iii) visión normal o
corregida; (iv) consentimiento informado. Exclusión: (i) no aceptar el consentimiento; (ii) limitaciones
motoras o visuales que impidan operar el equipo en condiciones seguras; (iii) participación simultánea
en proyectos que generen conflicto de interés, véase la tabla 1.
Tabla 1. Criterios de inclusión y exclusión
Tipo Criterio Descripción operativa Evidencia /
Verificación
Justificación
metodológica
Obligatorio Edad ≥ 18 años Participante adulto con
capacidad legal para
consentir.
Declaración del
participante en el
consentimiento
informado.
Garantiza validez
ética y legal del
consentimiento.
Obligatorio Alfabetización
digital básica
Puede usar navegador
web e interactuar con la
App Web (clics,
formularios).
Pregunta filtro y
breve prueba de
navegación (30–60
segs).
Evita sesgos por
falta de habilidades
mínimas para
ejecutar las tareas.
Obligatorio Visión normal
o corregida
Lee textos, íconos y
códigos de color
(semaforización) en
pantalla.
Autorreporte y uso
de lentes si aplica.
Asegura percepción
adecuada de
indicadores y alertas.
Obligatorio Consentimiento Acepta objetivos, Formato de Cumplimiento ético
(laboratorio estable) y Red-B (carga/ruido moderado) para observar la robustez de la comunicación
HTTP/MQTT 5.0.
Población, muestra y muestreo
La población objetivo son operadores potenciales de monitoreo (estudiantes avanzados y/o personal
técnico). La muestra para la evaluación de usabilidad está compuesta por n = 12 participantes (≥18
años), seleccionados mediante muestreo no probabilístico por conveniencia y criterios de experiencia
básica en herramientas informáticas y navegación web.
Criterios de inclusión y exclusión
Para la inclusión: (i) mayores de 18 años; (ii) alfabetización digital básica; (iii) visión normal o
corregida; (iv) consentimiento informado. Exclusión: (i) no aceptar el consentimiento; (ii) limitaciones
motoras o visuales que impidan operar el equipo en condiciones seguras; (iii) participación simultánea
en proyectos que generen conflicto de interés, véase la tabla 1.
Tabla 1. Criterios de inclusión y exclusión
Tipo Criterio Descripción operativa Evidencia /
Verificación
Justificación
metodológica
Obligatorio Edad ≥ 18 años Participante adulto con
capacidad legal para
consentir.
Declaración del
participante en el
consentimiento
informado.
Garantiza validez
ética y legal del
consentimiento.
Obligatorio Alfabetización
digital básica
Puede usar navegador
web e interactuar con la
App Web (clics,
formularios).
Pregunta filtro y
breve prueba de
navegación (30–60
segs).
Evita sesgos por
falta de habilidades
mínimas para
ejecutar las tareas.
Obligatorio Visión normal
o corregida
Lee textos, íconos y
códigos de color
(semaforización) en
pantalla.
Autorreporte y uso
de lentes si aplica.
Asegura percepción
adecuada de
indicadores y alertas.
Obligatorio Consentimiento Acepta objetivos, Formato de Cumplimiento ético
pág. 8307
informado
firmado
procedimientos y uso
anónimo de datos.
consentimiento
firmado (digital o
físico).
y respeto a derechos
del participante.
Deseable Familiaridad
básica con
dashboards
web
Ha interactuado
ocasionalmente con
paneles/gráficas en
línea.
Pregunta filtro
(sí/no).
Reduce curva de
aprendizaje y
variabilidad en
tiempos de tarea.
Deseable Disponibilidad
de 45–60 min
continuos
Tiempo para briefing,
tareas T1–T4 y
cuestionarios
SUS/NASA-TLX.
Confirmación de
agenda.
Asegura completar
el protocolo sin
interrupciones
Variables e indicadores
Las variables e indicadores considerados en esta investigación son los siguientes (véase tabla 2):
• Desempeño de comunicación: latencia extrema-a-extremo (ms), tiempo de respuesta a
comandos (ms), tasa de actualización (mensajes/s), pérdida de paquetes (%), disponibilidad del
servicio (% uptime).
• Energía y térmicas: autonomía del sistema (min), temperatura del motor/controlador (°C).
• Calidad de censado: estabilidad de lectura (desviación estándar), porcentaje de lecturas válidas
(%).
• Usabilidad y carga de trabajo: SUS (System Usability Scale, 0–100) y NASA-TLX (workload,
0–100), más satisfacción global (Likert 1–5).
informado
firmado
procedimientos y uso
anónimo de datos.
consentimiento
firmado (digital o
físico).
y respeto a derechos
del participante.
Deseable Familiaridad
básica con
dashboards
web
Ha interactuado
ocasionalmente con
paneles/gráficas en
línea.
Pregunta filtro
(sí/no).
Reduce curva de
aprendizaje y
variabilidad en
tiempos de tarea.
Deseable Disponibilidad
de 45–60 min
continuos
Tiempo para briefing,
tareas T1–T4 y
cuestionarios
SUS/NASA-TLX.
Confirmación de
agenda.
Asegura completar
el protocolo sin
interrupciones
Variables e indicadores
Las variables e indicadores considerados en esta investigación son los siguientes (véase tabla 2):
• Desempeño de comunicación: latencia extrema-a-extremo (ms), tiempo de respuesta a
comandos (ms), tasa de actualización (mensajes/s), pérdida de paquetes (%), disponibilidad del
servicio (% uptime).
• Energía y térmicas: autonomía del sistema (min), temperatura del motor/controlador (°C).
• Calidad de censado: estabilidad de lectura (desviación estándar), porcentaje de lecturas válidas
(%).
• Usabilidad y carga de trabajo: SUS (System Usability Scale, 0–100) y NASA-TLX (workload,
0–100), más satisfacción global (Likert 1–5).
pág. 8308
Tabla 2. Variables e indicadores operacionales, unidades e instrumentos de medición
Variable Indicador operacional Unida
d
Instrumento /
Fuente de datos
Frecuenci
a
Meta /
Umbral
sugerido
Desempeño
de
comunicació
n
Latencia
extremo-a-extremo
(t_rec-t_env, mediana)
ms
Timestamps
sincronizados
(servidor–
cliente), logs
ESP32 y backend
Por
paquete y
comando
< 200 ms
(Red-A);
< 500
ms(Red-B
)
Tiempo de respuesta a
comandos
(orden→ack/efecto)
ms
Marcado de
eventos en
dashboard y logs
Por orden
< 300 ms
(Red-A);
< 700 ms
(Red-B)
Tasa de actualización
(mensajes recibidos)
msg/se
g
Contador de
paquetes MQTT
5.0/HTTP
(servidor)
Continuo
≥ 5
msg/seg
por sensor
crítico*
Pérdida de paquetes =
(enviados − recibidos)
/enviados
%
Contador
secuencial de id
de mensaje y logs
Por sesión
< 1%
(Red-A);
< 5%
(Red-B)
Disponibilidad del servicio
(uptime)
%
Monitor de
disponibilidad del
servidor
Diario ≥ 99%
Energía y
térmicas
Autonomía de operación
continua
min
Cronometraje +
registro de estado
de batería
Por sesión
≥ 30 min
(prototipo
)
Temperatura °C Sonda/termistor o Cada 1 s Pico < 70
Tabla 2. Variables e indicadores operacionales, unidades e instrumentos de medición
Variable Indicador operacional Unida
d
Instrumento /
Fuente de datos
Frecuenci
a
Meta /
Umbral
sugerido
Desempeño
de
comunicació
n
Latencia
extremo-a-extremo
(t_rec-t_env, mediana)
ms
Timestamps
sincronizados
(servidor–
cliente), logs
ESP32 y backend
Por
paquete y
comando
< 200 ms
(Red-A);
< 500
ms(Red-B
)
Tiempo de respuesta a
comandos
(orden→ack/efecto)
ms
Marcado de
eventos en
dashboard y logs
Por orden
< 300 ms
(Red-A);
< 700 ms
(Red-B)
Tasa de actualización
(mensajes recibidos)
msg/se
g
Contador de
paquetes MQTT
5.0/HTTP
(servidor)
Continuo
≥ 5
msg/seg
por sensor
crítico*
Pérdida de paquetes =
(enviados − recibidos)
/enviados
%
Contador
secuencial de id
de mensaje y logs
Por sesión
< 1%
(Red-A);
< 5%
(Red-B)
Disponibilidad del servicio
(uptime)
%
Monitor de
disponibilidad del
servidor
Diario ≥ 99%
Energía y
térmicas
Autonomía de operación
continua
min
Cronometraje +
registro de estado
de batería
Por sesión
≥ 30 min
(prototipo
)
Temperatura °C Sonda/termistor o Cada 1 s Pico < 70
pág. 8309
motor/controlador(promed
io y pico)
sensor integrado;
logs ESP32
°C**
Calidad de
censado
Estabilidad de lectura
(desviación estándar en
ventana móvil)
Propia
del
sensor
Cálculo en
dashboard/servid
or (ventana 60 s)
Cada
minuto
σ dentro
de
tolerancia
de hoja de
datos
Lecturas válidas (no nulas
y en rango)
%
Validación en
servidor (reglas
por sensor)
Por sesión ≥ 95%
Usabilidad y
carga de
trabajo
SUS (System Usability
Scale)
0–100
Cuestionario SUS
post-tarea
Por
participant
e
≥ 70
NASA-TLX (workload
global)
0–100
Cuestionario
NASA-TLX
post-tarea
Por
participant
e
≤ 50
Éxito de tarea (T1–T4 sin
asistencia)
%
Observación
estructurada (lista
de cotejo)
Por tarea ≥ 80%
Tiempo por tarea s
Cronometraje
(dashboard/
observador)
Por tarea
Según
benchmar
k interno
Satisfacción global
Likert
1–5
Encuesta corta
post-sesión
Por
participant
e
≥ 4
Instrumentos y materiales
Hardware empleado: vehículo teleoperado con ESP32, sensores ambientales (p. ej., temperatura,
humedad, gas, distancia), controladores de motor, módulo de potencia y batería. Red: punto de acceso
motor/controlador(promed
io y pico)
sensor integrado;
logs ESP32
°C**
Calidad de
censado
Estabilidad de lectura
(desviación estándar en
ventana móvil)
Propia
del
sensor
Cálculo en
dashboard/servid
or (ventana 60 s)
Cada
minuto
σ dentro
de
tolerancia
de hoja de
datos
Lecturas válidas (no nulas
y en rango)
%
Validación en
servidor (reglas
por sensor)
Por sesión ≥ 95%
Usabilidad y
carga de
trabajo
SUS (System Usability
Scale)
0–100
Cuestionario SUS
post-tarea
Por
participant
e
≥ 70
NASA-TLX (workload
global)
0–100
Cuestionario
NASA-TLX
post-tarea
Por
participant
e
≤ 50
Éxito de tarea (T1–T4 sin
asistencia)
%
Observación
estructurada (lista
de cotejo)
Por tarea ≥ 80%
Tiempo por tarea s
Cronometraje
(dashboard/
observador)
Por tarea
Según
benchmar
k interno
Satisfacción global
Likert
1–5
Encuesta corta
post-sesión
Por
participant
e
≥ 4
Instrumentos y materiales
Hardware empleado: vehículo teleoperado con ESP32, sensores ambientales (p. ej., temperatura,
humedad, gas, distancia), controladores de motor, módulo de potencia y batería. Red: punto de acceso
pág. 8310
Wi-Fi dedicado. Software aplicado: aplicación web (frontend: HTML/CSS/JS/Bootstrap; backend:
PHP y base de datos en hosting), broker MQTT 5.0 (si aplica), scripts de registro de eventos (logs), y
herramientas de medición (cronómetros de alta resolución en el dashboard, registros de servidor y
utilitarios de red). Instrumentos de evaluación: cuestionarios SUS y NASA-TLX, guía de entrevista
breve (5–7 preguntas) sobre claridad del dashboard, alertas y control del vehículo. Véase Figura 4.
(OASIS Open, 2019; Brooke, 2013; Hart, 2006; Gentile et al., 2023)
Figura 4. Prototipo físico del vehículo y distribución de sensores/controladores (modelos del carrito
de pruebas).
Wi-Fi dedicado. Software aplicado: aplicación web (frontend: HTML/CSS/JS/Bootstrap; backend:
PHP y base de datos en hosting), broker MQTT 5.0 (si aplica), scripts de registro de eventos (logs), y
herramientas de medición (cronómetros de alta resolución en el dashboard, registros de servidor y
utilitarios de red). Instrumentos de evaluación: cuestionarios SUS y NASA-TLX, guía de entrevista
breve (5–7 preguntas) sobre claridad del dashboard, alertas y control del vehículo. Véase Figura 4.
(OASIS Open, 2019; Brooke, 2013; Hart, 2006; Gentile et al., 2023)
Figura 4. Prototipo físico del vehículo y distribución de sensores/controladores (modelos del carrito
de pruebas).
pág. 8311
Procedimiento
1. Preparación del sistema. Verificación eléctrica/mecánica del vehículo; carga de firmware en
ESP32; despliegue de la base de datos y servicios web; configuración de tópicos MQTT 5.0/URLs
HTTP. (OASIS Open, 2019)
2. Calibración inicial. Comprobación de sensores (lecturas en reposo/estímulo), prueba de
comandos básicos (avanzar/detener/giro) y verificación de sincronización reloj servidor-cliente para
mediciones de tiempo.
3. Pruebas técnicas (I1–I3). Tres rondas de ensayos con 10–15 minutos cada una bajo Red-A y
Red-B. Se ejecutan secuencias predeterminadas de comandos y rutas; el sistema registra latencia, tasa
de actualización, pérdida de paquetes y tiempos de respuesta; se mide autonomía en sesiones
extendidas. (López Pulgarín et al., 2022)
4. Pruebas de usabilidad. Cada participante realiza tareas representativas (T1–T4): localizar
valores anómalos, reconocer/atender una alerta, emitir una orden de movimiento y registrar un evento.
Se mide tiempo de tarea, errores y éxito. Al finalizar, aplica SUS, NASA-TLX y una entrevista breve.
5. Documentación de ajustes. Se registran incidentes y cambios de configuración
(hardware/software) para la trazabilidad del prototipo entre iteraciones.
Plan de análisis de datos
El análisis de datos consistió en aspectos cuantitativos y cualitativos, como se describen a
continuación.
• Cuantitativo: estadística descriptiva (media, mediana, desviación estándar, IQR, IC95%).
Comparación entre condiciones de red (Red-A vs. Red-B) y entre iteraciones (I1–I3) mediante pruebas
apropiadas al tamaño muestral y supuestos (p. ej., pruebas no paramétricas cuando aplique).
• Cualitativo: análisis temático de entrevistas (codificación abierta/axial) para identificar
patrones en claridad de la interfaz, comprensión de alertas y control del vehículo.
Consideraciones éticas
Se aplica consentimiento informado a los participantes del estudio de usabilidad, con derecho a retiro
sin consecuencias. Los datos se tratan de forma anonimizada, sin capturar información personal
sensible. El estudio no implica riesgos superiores a los de la vida cotidiana y cumple con la normativa
Procedimiento
1. Preparación del sistema. Verificación eléctrica/mecánica del vehículo; carga de firmware en
ESP32; despliegue de la base de datos y servicios web; configuración de tópicos MQTT 5.0/URLs
HTTP. (OASIS Open, 2019)
2. Calibración inicial. Comprobación de sensores (lecturas en reposo/estímulo), prueba de
comandos básicos (avanzar/detener/giro) y verificación de sincronización reloj servidor-cliente para
mediciones de tiempo.
3. Pruebas técnicas (I1–I3). Tres rondas de ensayos con 10–15 minutos cada una bajo Red-A y
Red-B. Se ejecutan secuencias predeterminadas de comandos y rutas; el sistema registra latencia, tasa
de actualización, pérdida de paquetes y tiempos de respuesta; se mide autonomía en sesiones
extendidas. (López Pulgarín et al., 2022)
4. Pruebas de usabilidad. Cada participante realiza tareas representativas (T1–T4): localizar
valores anómalos, reconocer/atender una alerta, emitir una orden de movimiento y registrar un evento.
Se mide tiempo de tarea, errores y éxito. Al finalizar, aplica SUS, NASA-TLX y una entrevista breve.
5. Documentación de ajustes. Se registran incidentes y cambios de configuración
(hardware/software) para la trazabilidad del prototipo entre iteraciones.
Plan de análisis de datos
El análisis de datos consistió en aspectos cuantitativos y cualitativos, como se describen a
continuación.
• Cuantitativo: estadística descriptiva (media, mediana, desviación estándar, IQR, IC95%).
Comparación entre condiciones de red (Red-A vs. Red-B) y entre iteraciones (I1–I3) mediante pruebas
apropiadas al tamaño muestral y supuestos (p. ej., pruebas no paramétricas cuando aplique).
• Cualitativo: análisis temático de entrevistas (codificación abierta/axial) para identificar
patrones en claridad de la interfaz, comprensión de alertas y control del vehículo.
Consideraciones éticas
Se aplica consentimiento informado a los participantes del estudio de usabilidad, con derecho a retiro
sin consecuencias. Los datos se tratan de forma anonimizada, sin capturar información personal
sensible. El estudio no implica riesgos superiores a los de la vida cotidiana y cumple con la normativa
pág. 8312
institucional y la legislación aplicable de protección de datos. Cualquier prueba con personas se realiza
fuera de zonas peligrosas y en entorno controlado.
Limitaciones
Se reconoce el tamaño muestral reducido en la evaluación de usabilidad y el alcance de laboratorio de
las pruebas técnicas; no se reproducen aún todas las condiciones de una zona de riesgo real
(interferencias severas, distancias extendidas, condiciones ambientales extremas). Los resultados
deben interpretarse como evidencia preliminar de factibilidad y servirán para planificar validaciones
en campo.
RESULTADOS
Integración funcional del sistema
Durante las iteraciones I1–I3 se valida la telemetría en tiempo real y el control discreto del vehículo
desde la aplicación web. La ESP32 transmite lecturas de sensores y recibe órdenes
(avanzar/detener/giro) de manera estable; el dashboard refleja cambios en tiempo real y registra
eventos en la base de datos. Se documentan ajustes incrementales de firmware, ruteo de cables y
fijación de componentes para mejorar estabilidad.
Desempeño de comunicación (HTTP/MQTT 5.0)
Bajo Red-A (laboratorio estable) se observan latencias subsegundo consistentes y pérdidas de paquetes
bajas, compatibles con telemetría continua y control discreto. En Red-B (carga/ruido moderado) la
variabilidad aumenta, con picos esporádicos que no comprometen la integridad de la sesión; se
recomiendan buffers y retries para eventos críticos. El tiempo de respuesta a comandos mantiene
fluidez operativa y se correlaciona con la proximidad del acceso Wi-Fi y la carga concurrente del
servidor.
Energía y condiciones térmicas
El prototipo cumple la meta mínima de autonomía definida para la etapa (≥ 30 min por sesión de
prueba). Se detectan incrementos térmicos en el conjunto motor-controlador bajo cargas prolongadas;
el rediseño mecánico y la ventilación pasiva reducen picos y estabilizan la operación.
institucional y la legislación aplicable de protección de datos. Cualquier prueba con personas se realiza
fuera de zonas peligrosas y en entorno controlado.
Limitaciones
Se reconoce el tamaño muestral reducido en la evaluación de usabilidad y el alcance de laboratorio de
las pruebas técnicas; no se reproducen aún todas las condiciones de una zona de riesgo real
(interferencias severas, distancias extendidas, condiciones ambientales extremas). Los resultados
deben interpretarse como evidencia preliminar de factibilidad y servirán para planificar validaciones
en campo.
RESULTADOS
Integración funcional del sistema
Durante las iteraciones I1–I3 se valida la telemetría en tiempo real y el control discreto del vehículo
desde la aplicación web. La ESP32 transmite lecturas de sensores y recibe órdenes
(avanzar/detener/giro) de manera estable; el dashboard refleja cambios en tiempo real y registra
eventos en la base de datos. Se documentan ajustes incrementales de firmware, ruteo de cables y
fijación de componentes para mejorar estabilidad.
Desempeño de comunicación (HTTP/MQTT 5.0)
Bajo Red-A (laboratorio estable) se observan latencias subsegundo consistentes y pérdidas de paquetes
bajas, compatibles con telemetría continua y control discreto. En Red-B (carga/ruido moderado) la
variabilidad aumenta, con picos esporádicos que no comprometen la integridad de la sesión; se
recomiendan buffers y retries para eventos críticos. El tiempo de respuesta a comandos mantiene
fluidez operativa y se correlaciona con la proximidad del acceso Wi-Fi y la carga concurrente del
servidor.
Energía y condiciones térmicas
El prototipo cumple la meta mínima de autonomía definida para la etapa (≥ 30 min por sesión de
prueba). Se detectan incrementos térmicos en el conjunto motor-controlador bajo cargas prolongadas;
el rediseño mecánico y la ventilación pasiva reducen picos y estabilizan la operación.
pág. 8313
Calidad de censado
Las lecturas de temperatura, humedad y distancia muestran estabilidad en ventanas móviles y
proporción alta de lecturas válidas. El sensor de gas requiere calentamiento y calibración inicial; tras el
acondicionamiento, las señales se estabilizan y responden a estímulos controlados.
Usabilidad y carga de trabajo
Los participantes completan las tareas T1–T4 con altas tasas de éxito y tiempos acordes al guion
operativo. La SUS indica aceptabilidad de la interfaz (Brooke, 2013), y NASA-TLX sugiere carga
moderada con oportunidades de simplificación en el módulo de alertas y en la confirmación de
comandos (Hart, 2006), véase la tabla 5.
Tabla 5. Resultados de usabilidad y carga de trabajo
Métrica Media DE /
IQR
Min –
Max
Interpretación Observación
SUS (0–100) 78 DE =
8
62 – 92 Aceptable –
Buena
Mejorar acceso rápido al módulo
de Alertas
NASA-TLX (0–
100)
41 DE =
12
22 – 66 Carga moderada Mayor demanda mental durante
maniobras precisas
Éxito de tarea T1–
T4 (%)
89 DE =
9
75 –
100
≥ objetivo T3 (orden de movimiento)
requiere confirmación
Tiempo por tarea
(seg)
23 DE =
7
12 – 38 Dentro de meta T1/T2 más rápidas que T3/T4
Satisfacción
(Likert 1–5)
4.3 DE =
0.5
3.3 –
5.0
Alta Comentarios positivos sobre
claridad del dashboard
DISCUSIÓN
Coherencia de hallazgos con la metodología
Los resultados son consistentes con el diseño cuasi-experimental y el entorno controlado: la latencia
subsegundo y la baja pérdida de paquetes en Red-A eran esperables por la proximidad y el aislamiento
de interferencias; la mayor variabilidad en Red-B confirma la sensibilidad del sistema a congestión y
Calidad de censado
Las lecturas de temperatura, humedad y distancia muestran estabilidad en ventanas móviles y
proporción alta de lecturas válidas. El sensor de gas requiere calentamiento y calibración inicial; tras el
acondicionamiento, las señales se estabilizan y responden a estímulos controlados.
Usabilidad y carga de trabajo
Los participantes completan las tareas T1–T4 con altas tasas de éxito y tiempos acordes al guion
operativo. La SUS indica aceptabilidad de la interfaz (Brooke, 2013), y NASA-TLX sugiere carga
moderada con oportunidades de simplificación en el módulo de alertas y en la confirmación de
comandos (Hart, 2006), véase la tabla 5.
Tabla 5. Resultados de usabilidad y carga de trabajo
Métrica Media DE /
IQR
Min –
Max
Interpretación Observación
SUS (0–100) 78 DE =
8
62 – 92 Aceptable –
Buena
Mejorar acceso rápido al módulo
de Alertas
NASA-TLX (0–
100)
41 DE =
12
22 – 66 Carga moderada Mayor demanda mental durante
maniobras precisas
Éxito de tarea T1–
T4 (%)
89 DE =
9
75 –
100
≥ objetivo T3 (orden de movimiento)
requiere confirmación
Tiempo por tarea
(seg)
23 DE =
7
12 – 38 Dentro de meta T1/T2 más rápidas que T3/T4
Satisfacción
(Likert 1–5)
4.3 DE =
0.5
3.3 –
5.0
Alta Comentarios positivos sobre
claridad del dashboard
DISCUSIÓN
Coherencia de hallazgos con la metodología
Los resultados son consistentes con el diseño cuasi-experimental y el entorno controlado: la latencia
subsegundo y la baja pérdida de paquetes en Red-A eran esperables por la proximidad y el aislamiento
de interferencias; la mayor variabilidad en Red-B confirma la sensibilidad del sistema a congestión y
pág. 8314
ruido, alineada con la literatura de MQTT 5.0/HTTP en IoT. La autonomía ≥ 30 min valida la meta de
prototipo y orienta mejoras de gestión energética.
Comparación con el estado del arte
El comportamiento observado concuerda con encuestas de IoT por capas y protocolos livianos que
recomiendan publish/subscribe para telemetría eficiente (Atzori et al., 2010; Gubbi et al., 2013;
Al-Fuqaha et al., 2015) y con estudios de teleoperación que señalan la latencia como factor crítico de
desempeño (Farajiparvar et al., 2020). En UX, los patrones de SUS aceptable y carga moderada se
relacionan con buenas prácticas de dashboard y gestión de fatiga por alertas (Nielsen Norman Group,
2017; 2022; Brooke, 2013).
Interpretaciones y aportes
La arquitectura n-capas y el uso de ESP32 + HTTP/MQTT 5.0 demuestran ser una combinación viable
y replicable para monitoreo en tiempo real con control teleoperado. El mockup centrado en conciencia
situacional facilita la curva de aprendizaje y respalda decisiones operativas con indicadores claros. El
rediseño mecánico tras detectar sobrecalentamiento evidencia un ciclo de mejora iterativa propio de
TRLs tempranos.
Novedad, aplicaciones y pertinencia
El aporte reside en integrar, con bajo costo y modularidad, un vehículo teleoperado y una App Web
para zonas de riesgo, con una ruta metodológica reproducible. Las aplicaciones incluyen minería,
inspección industrial y respuesta ante desastres en entornos donde la reducción de exposición humana
es prioritaria. La pertinencia se alinea con líneas de investigación en IoT aplicado, HCI para monitoreo
y robótica en entornos peligrosos.
Límites y trabajo futuro
El alcance de laboratorio, la muestra reducida y la ausencia de pruebas en condiciones extremas
limitan la generalización. Como trabajo futuro se propone: (i) validar en pilotajes de campo, (ii)
endurecer seguridad (HTTPS, autenticación robusta, registro de auditoría), (iii) optimizar consumo
energético y gestión térmica, y (iv) explorar estrategias de tolerancia a fallos y control predictivo para
mitigar latencia y jitter.
ruido, alineada con la literatura de MQTT 5.0/HTTP en IoT. La autonomía ≥ 30 min valida la meta de
prototipo y orienta mejoras de gestión energética.
Comparación con el estado del arte
El comportamiento observado concuerda con encuestas de IoT por capas y protocolos livianos que
recomiendan publish/subscribe para telemetría eficiente (Atzori et al., 2010; Gubbi et al., 2013;
Al-Fuqaha et al., 2015) y con estudios de teleoperación que señalan la latencia como factor crítico de
desempeño (Farajiparvar et al., 2020). En UX, los patrones de SUS aceptable y carga moderada se
relacionan con buenas prácticas de dashboard y gestión de fatiga por alertas (Nielsen Norman Group,
2017; 2022; Brooke, 2013).
Interpretaciones y aportes
La arquitectura n-capas y el uso de ESP32 + HTTP/MQTT 5.0 demuestran ser una combinación viable
y replicable para monitoreo en tiempo real con control teleoperado. El mockup centrado en conciencia
situacional facilita la curva de aprendizaje y respalda decisiones operativas con indicadores claros. El
rediseño mecánico tras detectar sobrecalentamiento evidencia un ciclo de mejora iterativa propio de
TRLs tempranos.
Novedad, aplicaciones y pertinencia
El aporte reside en integrar, con bajo costo y modularidad, un vehículo teleoperado y una App Web
para zonas de riesgo, con una ruta metodológica reproducible. Las aplicaciones incluyen minería,
inspección industrial y respuesta ante desastres en entornos donde la reducción de exposición humana
es prioritaria. La pertinencia se alinea con líneas de investigación en IoT aplicado, HCI para monitoreo
y robótica en entornos peligrosos.
Límites y trabajo futuro
El alcance de laboratorio, la muestra reducida y la ausencia de pruebas en condiciones extremas
limitan la generalización. Como trabajo futuro se propone: (i) validar en pilotajes de campo, (ii)
endurecer seguridad (HTTPS, autenticación robusta, registro de auditoría), (iii) optimizar consumo
energético y gestión térmica, y (iv) explorar estrategias de tolerancia a fallos y control predictivo para
mitigar latencia y jitter.
pág. 8315
CONCLUSIONES
La solución propuesta —vehículo teleoperado con sensorización ambiental y aplicación web—
demuestra viabilidad técnica para el monitoreo en tiempo real en entornos controlados. La arquitectura
n-capas y el uso de ESP32 + HTTP/MQTT permiten comunicación bidireccional estable y reflejo
inmediato de eventos en el panel, cumpliendo los objetivos operativos de prototipo (telemetría
continua y control discreto) sin comprometer la integridad de los datos.
Desde la perspectiva socio-técnica, el tablero prioriza la conciencia situacional y ofrece una
experiencia de uso aceptable para operadores no expertos, como sugieren los resultados de usabilidad
(SUS en rango aceptable-bueno y carga NASA-TLX moderada). La combinación de tarjetas
semaforizadas, alertas jerarquizadas y gráficas en tiempo real facilita la interpretación de estados y la
ejecución de acciones oportunas.
En términos ingenieriles, el sistema mantiene latencias subsegundo y baja pérdida de paquetes en
condiciones de red estable; bajo carga/ruido moderado se observa variabilidad que no impide la
operación, pero que aconseja buffers, reintentos y políticas de QoS. La gestión energética y el control
térmico emergen como condicionantes del desempeño sostenido; el rediseño mecánico y la ventilación
pasiva muestran efectividad para mitigar sobrecalentamiento.
La investigación aporta: (i) una ruta de integración replicable y de bajo costo para sistemas IoT
teleoperados aplicados a zonas de riesgo; (ii) un conjunto de indicadores operacionales y
procedimientos de medición que favorecen la comparabilidad entre iteraciones y configuraciones; y
(iii) un diseño de interfaz orientado a reducir la carga cognitiva sin sacrificar información crítica.
Las limitaciones del estudio —alcance de laboratorio, tamaño muestral reducido y ausencia de
condiciones extremas— restringen la generalización. En consecuencia, se recomienda: (a) realizar
pilotos de campo con perfiles de red heterogéneos; (b) endurecer la seguridad (TLS extremo a
extremo, autenticación robusta, registro de auditoría y pruebas de penetración básicas); (c) optimizar
consumo y térmicas (gestión de potencia, selección de motores y perfiles de conducción); y (d)
explorar tolerancia a fallos (QoS MQTT, fallback HTTP, enlaces redundantes Wi-Fi/LTE/mesh) y
control predictivo para compensar latencia y jitter.
CONCLUSIONES
La solución propuesta —vehículo teleoperado con sensorización ambiental y aplicación web—
demuestra viabilidad técnica para el monitoreo en tiempo real en entornos controlados. La arquitectura
n-capas y el uso de ESP32 + HTTP/MQTT permiten comunicación bidireccional estable y reflejo
inmediato de eventos en el panel, cumpliendo los objetivos operativos de prototipo (telemetría
continua y control discreto) sin comprometer la integridad de los datos.
Desde la perspectiva socio-técnica, el tablero prioriza la conciencia situacional y ofrece una
experiencia de uso aceptable para operadores no expertos, como sugieren los resultados de usabilidad
(SUS en rango aceptable-bueno y carga NASA-TLX moderada). La combinación de tarjetas
semaforizadas, alertas jerarquizadas y gráficas en tiempo real facilita la interpretación de estados y la
ejecución de acciones oportunas.
En términos ingenieriles, el sistema mantiene latencias subsegundo y baja pérdida de paquetes en
condiciones de red estable; bajo carga/ruido moderado se observa variabilidad que no impide la
operación, pero que aconseja buffers, reintentos y políticas de QoS. La gestión energética y el control
térmico emergen como condicionantes del desempeño sostenido; el rediseño mecánico y la ventilación
pasiva muestran efectividad para mitigar sobrecalentamiento.
La investigación aporta: (i) una ruta de integración replicable y de bajo costo para sistemas IoT
teleoperados aplicados a zonas de riesgo; (ii) un conjunto de indicadores operacionales y
procedimientos de medición que favorecen la comparabilidad entre iteraciones y configuraciones; y
(iii) un diseño de interfaz orientado a reducir la carga cognitiva sin sacrificar información crítica.
Las limitaciones del estudio —alcance de laboratorio, tamaño muestral reducido y ausencia de
condiciones extremas— restringen la generalización. En consecuencia, se recomienda: (a) realizar
pilotos de campo con perfiles de red heterogéneos; (b) endurecer la seguridad (TLS extremo a
extremo, autenticación robusta, registro de auditoría y pruebas de penetración básicas); (c) optimizar
consumo y térmicas (gestión de potencia, selección de motores y perfiles de conducción); y (d)
explorar tolerancia a fallos (QoS MQTT, fallback HTTP, enlaces redundantes Wi-Fi/LTE/mesh) y
control predictivo para compensar latencia y jitter.
pág. 8316
Investigaciones futuras recomendadas: (a) umbrales de variables ambientales correlacionados mejor
con el riesgo operativo según el dominio (minería, industria química, protección civil); (b) el
sobrecosto de latencia introducido por el cifrado extremo a extremo y cómo afecta la teleoperación; (c)
análisis en el borde (detección de anomalías/IA ligera) que aporte ganancias tangibles en tiempos de
respuesta; (d) escalamiento a flotas de vehículos coordinados manteniendo estabilidad, seguridad y
gobernanza de datos y (e) estrategias de entrenamiento para la reducción de la demanda mental en
maniobras finas y en gestión de alertas.
REFERENCIAS BIBLIOGRÁFICAS
Al-Fuqaha, A., Guizani, M., Mohammadi, M., Aledhari, M., & Ayyash, M. (2015). Internet of Things:
A survey on enabling technologies, protocols, and applications. IEEE Communications
Surveys & Tutorials, 17(4), 2347–2376. https://doi.org/10.1109/COMST.2015.2444095
Atzori, L., Iera, A., & Morabito, G. (2010). The Internet of Things: A survey. Computer Networks,
54(15), 2787–2805. https://doi.org/10.1016/j.comnet.2010.05.010
Brooke, J. (2013). SUS: A retrospective. Journal of Usability Studies, 8(2), 29–40.
https://uxpajournal.org/sus-a-retrospective/
Espressif Systems. (2025a). ESP32 Series: Datasheet (v5.0).
https://www.espressif.com/sites/default/files/documentation/esp32_datasheet_en.pdf
Espressif Systems. (2025b). ESP32 Technical Reference Manual (v5.4).
https://www.espressif.com/sites/default/files/documentation/esp32_technical_reference_manu
al_en.pdf
Farajiparvar, P., Das, P., & Ferre, M. (2020). A brief survey of telerobotic time delay mitigation.
Frontiers in Robotics and AI, 7, 578805. https://doi.org/10.3389/frobt.2020.578805
Gentile, C., Lunghi, G., Buonocore, L. R., Cordella, F., Di Castro, M., Masi, A., & Zollo, L. (2023).
Manipulation tasks in hazardous environments using a teleoperated robot: A case study at
CERN. Sensors, 23(4), 1979. https://doi.org/10.3390/s23041979
Gubbi, J., Buyya, R., Marusic, S., & Palaniswami, M. (2013). Internet of Things (IoT): A vision,
architectural elements, and future directions. Future Generation Computer Systems, 29(7),
1645–1660. https://doi.org/10.1016/j.future.2013.01.010
Investigaciones futuras recomendadas: (a) umbrales de variables ambientales correlacionados mejor
con el riesgo operativo según el dominio (minería, industria química, protección civil); (b) el
sobrecosto de latencia introducido por el cifrado extremo a extremo y cómo afecta la teleoperación; (c)
análisis en el borde (detección de anomalías/IA ligera) que aporte ganancias tangibles en tiempos de
respuesta; (d) escalamiento a flotas de vehículos coordinados manteniendo estabilidad, seguridad y
gobernanza de datos y (e) estrategias de entrenamiento para la reducción de la demanda mental en
maniobras finas y en gestión de alertas.
REFERENCIAS BIBLIOGRÁFICAS
Al-Fuqaha, A., Guizani, M., Mohammadi, M., Aledhari, M., & Ayyash, M. (2015). Internet of Things:
A survey on enabling technologies, protocols, and applications. IEEE Communications
Surveys & Tutorials, 17(4), 2347–2376. https://doi.org/10.1109/COMST.2015.2444095
Atzori, L., Iera, A., & Morabito, G. (2010). The Internet of Things: A survey. Computer Networks,
54(15), 2787–2805. https://doi.org/10.1016/j.comnet.2010.05.010
Brooke, J. (2013). SUS: A retrospective. Journal of Usability Studies, 8(2), 29–40.
https://uxpajournal.org/sus-a-retrospective/
Espressif Systems. (2025a). ESP32 Series: Datasheet (v5.0).
https://www.espressif.com/sites/default/files/documentation/esp32_datasheet_en.pdf
Espressif Systems. (2025b). ESP32 Technical Reference Manual (v5.4).
https://www.espressif.com/sites/default/files/documentation/esp32_technical_reference_manu
al_en.pdf
Farajiparvar, P., Das, P., & Ferre, M. (2020). A brief survey of telerobotic time delay mitigation.
Frontiers in Robotics and AI, 7, 578805. https://doi.org/10.3389/frobt.2020.578805
Gentile, C., Lunghi, G., Buonocore, L. R., Cordella, F., Di Castro, M., Masi, A., & Zollo, L. (2023).
Manipulation tasks in hazardous environments using a teleoperated robot: A case study at
CERN. Sensors, 23(4), 1979. https://doi.org/10.3390/s23041979
Gubbi, J., Buyya, R., Marusic, S., & Palaniswami, M. (2013). Internet of Things (IoT): A vision,
architectural elements, and future directions. Future Generation Computer Systems, 29(7),
1645–1660. https://doi.org/10.1016/j.future.2013.01.010
pág. 8317
Hart, S. G. (2006). NASA-Task Load Index (NASA-TLX); 20 years later.Proceedings of the Human
Factors and Ergonomics Society Annual Meeting, 50(9), 904–908.
https://doi.org/10.1177/154193120605000909
Murphy, R. R. (2014). Disaster robotics. MIT Press. https://doi.org/10.7551/mitpress/9407.001.0001
National Institute of Standards and Technology. (2020). NISTIR 8259A: IoT device cybersecurity
capability core baseline. https://doi.org/10.6028/NIST.IR.8259A
Nielsen Norman Group. (2017, June 18). Dashboards: Making charts and graphs easier to
understand. https://www.nngroup.com/articles/dashboards-preattentive/
Nielsen Norman Group. (2022, December 16). Alert fatigue in user interfaces [Video].
https://www.nngroup.com/videos/alert-fatigue-user-interfaces/
NIST. (2020). NISTIR 8259A: IoT Device Cybersecurity Capability Core Baseline. National Institute
of Standards and Technology. https://doi.org/10.6028/NIST.IR.8259A
OASIS Open. (2019, March 7). MQTT Version 5.0 (OASIS Standard). https://www.oasis-
open.org/standard/mqtt-v5-0-os/
OWASP. (2018). IoT Top 10 2018. https://owasp.org/www-project-internet-of-things/
López Pulgarín, E. J., Tokatli, O., Burroughes, G., & Herrmann, G. (2022). Assessing
tele-manipulation systems using task performance and subjective metrics.
https://doi.org/10.3389/frobt.2022.932538
Shi, W., Cao, J., Zhang, Q., Li, Y., & Xu, L. (2016). Edge computing: Vision and challenges. IEEE
Internet of Things Journal, 3(5), 637–646. https://doi.org/10.1109/JIOT.2016.2579198
Hart, S. G. (2006). NASA-Task Load Index (NASA-TLX); 20 years later.Proceedings of the Human
Factors and Ergonomics Society Annual Meeting, 50(9), 904–908.
https://doi.org/10.1177/154193120605000909
Murphy, R. R. (2014). Disaster robotics. MIT Press. https://doi.org/10.7551/mitpress/9407.001.0001
National Institute of Standards and Technology. (2020). NISTIR 8259A: IoT device cybersecurity
capability core baseline. https://doi.org/10.6028/NIST.IR.8259A
Nielsen Norman Group. (2017, June 18). Dashboards: Making charts and graphs easier to
understand. https://www.nngroup.com/articles/dashboards-preattentive/
Nielsen Norman Group. (2022, December 16). Alert fatigue in user interfaces [Video].
https://www.nngroup.com/videos/alert-fatigue-user-interfaces/
NIST. (2020). NISTIR 8259A: IoT Device Cybersecurity Capability Core Baseline. National Institute
of Standards and Technology. https://doi.org/10.6028/NIST.IR.8259A
OASIS Open. (2019, March 7). MQTT Version 5.0 (OASIS Standard). https://www.oasis-
open.org/standard/mqtt-v5-0-os/
OWASP. (2018). IoT Top 10 2018. https://owasp.org/www-project-internet-of-things/
López Pulgarín, E. J., Tokatli, O., Burroughes, G., & Herrmann, G. (2022). Assessing
tele-manipulation systems using task performance and subjective metrics.
https://doi.org/10.3389/frobt.2022.932538
Shi, W., Cao, J., Zhang, Q., Li, Y., & Xu, L. (2016). Edge computing: Vision and challenges. IEEE
Internet of Things Journal, 3(5), 637–646. https://doi.org/10.1109/JIOT.2016.2579198