Robótica autónoma
Los robots industriales y de inspección generan observaciones visuales, térmicas y de sensores que los equipos de mantenimiento necesitan interpretar en contexto, sin que esa interpretación adquiera nunca autoridad sobre el control del motor o los interbloqueos de seguridad. Esta página establece cómo se planificaría y ejecutaría dicho flujo de trabajo en inTheEU Assist, no un registro de una implementación completa.
Cómo se estructuraría el flujo de trabajo
Las observaciones recopiladas por un robot, imágenes, lecturas térmicas y telemetría se ingerirían e indexarían en las instalaciones, alimentando un paquete de conocimientos dirigido al propio inquilino del operador. Un agente configurado para el flujo de trabajo compararía una nueva observación con el historial de mantenimiento aprobado y propondría un hallazgo candidato, ingresado con un estado de propuesto y vinculado al activo específico y la misión de donde proviene. Una solicitud de inspección más detallada seguiría el mismo camino desde lo propuesto hasta lo aprobado antes de llevar a cabo cualquier reposicionamiento.
El propio sistema de control del robot, el control de motores y actuadores, la prevención de colisiones, la parada de emergencia y los dispositivos de seguridad quedarían completamente fuera de este flujo de trabajo. La plataforma nunca tendría, solicitaría ni ejecutaría autoridad sobre esos sistemas, y ninguna acción llega al robot hasta que haya pasado por una aprobación explícita.
Donde se encuentra la aprobación humana
Cada solicitud de hallazgo o reposicionamiento requeriría la aprobación explícita de un ingeniero designado antes de que se considere establecida o se actúe en consecuencia. Esta no es una política superpuesta al flujo de trabajo. Es el mecanismo por el cual avanza el flujo de trabajo: una etapa no aprobada simplemente no ejecuta el siguiente paso.
En qué se basa esto hoy y en qué no
El flujo de trabajo de señalización de hallazgos, el ciclo de vida de revisión de propuesta a aprobación y la cadena de auditoría firmada detrás de cada acción son partes funcionales de la plataforma. Lo que aún no forma parte de esto: un modelo de percepción específico del robot entrenado en el propio equipo y entorno de un operador determinado, que es exactamente lo que construiría un piloto inicial. El sistema de control determinista del robot permanece completamente fuera del alcance de la plataforma, por diseño. El criterio de ingeniería en un despliegue de robótica permanecería en manos del propio equipo del operador en todo momento, y cualquier habilidad de percepción específica de un activo se desarrollaría junto con ellos, no se proporcionaría como un modelo estándar.
Parte de la arquitectura subyacente a este conjunto de capacidades está documentada en documentos aún en curso. Esta página describe para qué está diseñada la plataforma, en un nivel apropiado para planificar un piloto, no una especificación de implementación.
Las características y la interfaz de la plataforma están sujetas a mejoras continuas. Es posible que las descripciones de esta guía no reflejen el diseño o la redacción exactos de la última versión publicada.