Robotique autonome
Les robots d'inspection et industriels génèrent des observations visuelles, thermiques et de capteurs que les équipes de maintenance doivent interpréter dans leur contexte, sans que cette interprétation n'ait jamais autorité sur le contrôle du moteur ou les verrouillages de sécurité. Cette page explique comment un tel flux de travail serait planifié et exécuté sur inTheEU Assist, et non un enregistrement d'un déploiement terminé.
Comment le flux de travail serait structuré
Les observations collectées par un robot, les images, les relevés thermiques, la télémétrie, seraient ingérées et indexées sur place, alimentant un pack de connaissances étendu au propre locataire de l'opérateur. Un agent configuré pour le flux de travail comparerait une nouvelle observation à l'historique de maintenance approuvé et proposerait une découverte candidate, saisie avec le statut proposé et liée à l'actif et à la mission spécifiques dont elle provenait. Une demande d’inspection plus approfondie suivrait le même cheminement proposé à approuvé avant tout repositionnement.
Le système de contrôle du robot, le contrôle du moteur et des actionneurs, l'évitement des collisions, l'arrêt d'urgence et les verrouillages de sécurité resteraient entièrement en dehors de ce flux de travail. La plate-forme ne détiendra, ne demandera ou n’exécutera jamais d’autorité sur ces systèmes, et aucune action n’atteindra le robot tant qu’elle n’aura pas passé une approbation explicite.
Là où se situe l’approbation humaine
Chaque découverte ou demande de repositionnement nécessiterait l'approbation explicite d'un ingénieur nommé avant d'être traitée comme établie ou d'y donner suite. Il ne s’agit pas d’une politique superposée au flux de travail. C'est le mécanisme par lequel le flux de travail se déroule : une étape non approuvée n'exécute tout simplement pas l'étape suivante.
Sur quoi cela s’appuie-t-il aujourd’hui et sur quoi cela ne s’appuie-t-il pas ?
Le flux de travail de signalement des résultats, le cycle de vie des évaluations proposées à approuvées et la chaîne d'audit signée derrière chaque action sont des éléments fonctionnels de la plateforme. Ce qui n'en fait pas encore partie : un modèle de perception spécifique au robot, entraîné sur l'équipement et l'environnement d'un opérateur donné, qui est exactement ce qu'un premier pilote construirait. Le système de contrôle déterministe du robot reste totalement en dehors du champ d’application de la plate-forme, de par sa conception. Le jugement technique dans un déploiement robotique resterait avec la propre équipe de l'opérateur tout au long, et toute compétence de perception spécifique à l'actif serait développée parallèlement à elle, et non fournie sous forme de modèle standard.
Une partie de l'architecture sous-jacente à cet ensemble de capacités est documentée dans des dossiers encore en cours. Cette page décrit ce pour quoi la plateforme est conçue, à un niveau approprié pour la planification d'un projet pilote, et non une spécification de mise en œuvre.
Les fonctionnalités et l'interface de la plateforme sont sujettes à une amélioration continue. Les descriptions contenues dans ce guide peuvent ne pas refléter la présentation ou le libellé exact de la dernière version publiée.