Un wearable para seguridad industrial debe recoger información y hacer llegar una alerta a quien puede actuar. Gerard Fernández explica esa propuesta en el capítulo 40 de Toque de Ingenio: ENGIDI desarrolla tecnología para reducir el tiempo de reacción ante incidentes en entornos de trabajo. La entrevista muestra cómo sensores, comunicaciones y plataforma necesitan responder a las condiciones reales del operario.
Invitado: Gerard Fernández, presentado en el episodio como CEO de ENGIDI.
Conversación publicada: 4 de marzo de 2025. Episodio: 40. Duración: 58 min.
En este capítulo:
- Por qué una alerta necesita un recorrido completo desde el dispositivo hasta la respuesta de la organización.
- Cómo la cobertura y el entorno de trabajo condicionan el desarrollo de un wearable industrial.
- Qué aprendió ENGIDI al contrastar su propuesta con los operarios que debían utilizarla.
Gerard sitúa el producto en trabajos donde un incidente puede pasar inadvertido o donde localizar a una persona resulta difícil. En lugar de presentar la tecnología como una garantía absoluta, define una función concreta: aportar información y facilitar la reacción. El artículo recoge los equipos, experiencias y planes descritos en marzo de 2025.
La propuesta empieza por reducir el tiempo de reacción
El episodio utiliza ejemplos de operarios en instalaciones industriales y trabajos de mantenimiento. Si una persona pierde actividad o se encuentra en una situación que requiere atención, depender únicamente de que alguien lo advierta puede retrasar la respuesta.
ENGIDI plantea un dispositivo que acompaña al trabajador y reporta información a una plataforma. El objetivo es que la organización reciba una señal y pueda comprobar qué está ocurriendo. La tecnología se integra en una actuación que sigue necesitando responsables y procedimientos.
Gerard define el propósito de forma precisa:
«reducir el tiempo de reacción».
Gerard Fernández, 3:54.
Esta definición ayuda a establecer el alcance del producto. Un sistema de alertas puede aportar información para actuar, pero no elimina por sí mismo las condiciones de riesgo ni sustituye todas las medidas de prevención. La utilidad debe evaluarse dentro de la organización que recibe y gestiona los avisos.
Sensores y plataforma cumplen funciones diferentes
Durante la conversación se mencionan sensores de temperatura, humedad y movimiento, además de funciones de localización. El dispositivo recoge datos y los envía para que la plataforma los procese. La información adquiere sentido al relacionarse con una sesión y con el contexto de trabajo.
El ejemplo de una persona expuesta a condiciones ambientales exigentes permite comprender ese recorrido. Medir una variable es el primer paso; interpretar cuándo conviene prestar atención requiere reglas y criterios. Después, alguien debe recibir una notificación comprensible y decidir qué hacer.
Para un proyecto de desarrollo electrónico, esto plantea varias preguntas de integración. Qué dato se necesita, con qué frecuencia, cómo se transmite y qué sucede si deja de llegar. Las respuestas condicionan tanto el circuito y su consumo como la experiencia del servicio.
También importa qué ve la persona que lleva el dispositivo. La entrevista comenta el significado de una luz de estado y todo el funcionamiento que debe existir detrás de ella. Un indicador sencillo puede representar una cadena técnica compleja que el usuario necesita interpretar de un vistazo.
La conectividad se diseña para el lugar de uso
Gerard explica que la cobertura fue uno de los problemas relevantes del desarrollo. Una conexión que funciona en la oficina no describe necesariamente una planta, una carretera o una zona aislada. El equipo debe poder comunicar en los lugares donde se espera utilizarlo.
ENGIDI describe una solución que trabaja con varios operadores y contempla diferentes condiciones de red. La intención es ampliar las posibilidades de comunicación cuando un proveedor no ofrece cobertura suficiente. Esa capacidad debe formar parte de las decisiones del producto y de su despliegue.
La conversación aborda además proyectos con infraestructura de comunicaciones para zonas sin cobertura celular. Gerard recuerda un caso vinculado a equipos de rescate en el entorno del Teide. En ese tipo de aplicación, la solución incluye crear un área de conectividad y transmitir la información hacia el exterior.
El ejemplo permite distinguir dispositivo y sistema. Un wearable puede necesitar infraestructura adicional para responder en un entorno determinado. Definir ese requisito pronto evita presentar la conectividad como una propiedad universal del objeto, independiente del lugar donde se utiliza.
Preguntar al operario cambia las decisiones de producto
Uno de los aprendizajes más valiosos de la entrevista está en la validación con clientes industriales. Gerard cuenta que una idea puede parecer interesante a un departamento de innovación y encontrar dificultades al llegar a la operación cotidiana.
El trabajador conoce gestos, restricciones y problemas que pueden no aparecer en una reunión corporativa. Si el producto le resulta incómodo o no responde a una necesidad que reconoce, la adopción puede fallar aunque la presentación técnica haya generado interés.
Gerard identifica ese error como no haber preguntado a:
«quién teníamos que preguntarle que es el usuario final».
Gerard Fernández, 31:05.
El caso conecta con un principio de diseño de producto: quien aprueba una compra y quien utiliza el equipo pueden tener prioridades diferentes. El desarrollo necesita comprender ambas. Una solución industrial debe aportar valor a la empresa y encajar en la actividad de sus operarios.
La confianza también influye. Gerard explica que algunos trabajadores pueden interpretar la tecnología como un instrumento de control. Comunicar para qué se utiliza la información y cómo ayuda en una incidencia forma parte de la implantación. El significado del dispositivo para quien lo lleva importa tanto como sus funciones.
Prototipos para validar detalles que parecen pequeños
Gerard describe varias generaciones de hardware y numerosas revisiones de programación antes del equipo presentado en la mesa. Cada versión recogía problemas encontrados y modificaciones necesarias. El desarrollo combinaba cambios físicos y lógicos que debían funcionar juntos.
La conversación se detiene en un ejemplo aparentemente menor: la luz de estado. Color, difusión y visibilidad pueden requerir pruebas propias. Una indicación que se entiende en un ambiente puede perder claridad con otra iluminación o desde una posición diferente.
Esos detalles recuerdan que el uso industrial plantea condiciones concretas. La forma de llevar el dispositivo, la interpretación de sus señales y el entorno previsto deben convertirse en preguntas de prueba. La calidad percibida y la facilidad de uso se construyen con decisiones acumuladas.
Los prototipos permiten contrastar esas cuestiones antes de consolidar una versión. El objetivo es aprender qué necesita cambiar y por qué. Una prueba bien definida ayuda a decidir si el siguiente paso requiere otra geometría, otra interacción o una revisión del sistema completo.
Foco comercial y evolución de la plataforma
La entrevista explora aplicaciones diferentes, pero Gerard distingue las que sostienen el negocio de otras que resultan especialmente motivadoras. Conocer esa diferencia ayuda a concentrar recursos. Una tecnología versátil necesita una primera propuesta comercial que pueda desarrollarse y atenderse.
Al hablar del futuro, plantea una conexión más amplia entre dispositivos y datos del entorno. Lo presenta como una dirección de desarrollo, no como una capacidad ya demostrada en todas las situaciones mencionadas. Esa visión exige avanzar desde funciones concretas y comprobables.
El episodio muestra así dos escalas de trabajo: resolver de forma fiable una alerta actual y preparar una plataforma que pueda evolucionar. Mantener claras ambas permite comunicar qué hace el producto y qué nuevas preguntas está investigando el equipo.
Qué puede aprender otro equipo de desarrollo
- Definir quién recibe una alerta y cómo se incorpora a una respuesta operativa.
- Validar comunicaciones y estados del dispositivo en su entorno real de uso.
- Incluir a los operarios junto a los responsables de compra e innovación.
- Probar los detalles físicos y de interacción que determinan si la herramienta se utiliza correctamente.
ENGIDI muestra cómo desarrollar un producto industrial conectado exige escuchar, integrar y probar. Para empresas que preparan un wearable o un equipo que debe trabajar fuera de la oficina, i-mas puede ayudar a ordenar requisitos y convertirlos en un sistema físico utilizable. Puedes contarnos qué necesitas desarrollar.
Para seguir leyendo: Los sensores y la visión artificial aplicados a la seguridad en escalada con Lizcore.
Fuente del artículo: entrevista de Edgar Guerrero con Gerard Fernández en Toque de Ingenio, publicada el 4 de marzo de 2025. Las citas enlazan con sus pasajes en el vídeo; los aprendizajes son una síntesis editorial de la conversación.
