Autonome Robotik
Inspektions- und Industrieroboter erzeugen visuelle, thermische und sensorische Beobachtungen, die Wartungsteams im Kontext interpretieren müssen, ohne dass diese Interpretation jemals Autorität über Motorsteuerung oder Sicherheitsverriegelungen erlangt. Auf dieser Seite wird dargelegt, wie ein solcher Arbeitsablauf auf inTheEU Assist geplant und ausgeführt werden würde, und es handelt sich nicht um eine Aufzeichnung einer abgeschlossenen Bereitstellung.
Wie der Arbeitsablauf strukturiert sein würde
Von einem Roboter gesammelte Beobachtungen, Bilder, thermische Messwerte und Telemetrie würden vor Ort erfasst und indiziert und als Wissenspaket für den eigenen Mieter des Betreibers bereitgestellt. Ein für den Workflow konfigurierter Agent vergleicht eine neue Beobachtung mit der genehmigten Wartungshistorie und schlägt einen Kandidatenbefund vor, der mit dem Status „Vorgeschlagen“ eingegeben und an die spezifische Anlage und Mission gebunden ist, von der er stammt. Eine Anfrage nach einer genaueren Prüfung würde dem gleichen Weg vom Vorschlag bis zur Genehmigung folgen, bevor eine Neupositionierung durchgeführt wird.
Das eigene Steuerungssystem des Roboters, Motor- und Aktuatorsteuerung, Kollisionsvermeidung, Not-Aus und Sicherheitsverriegelungen würden völlig außerhalb dieses Arbeitsablaufs bleiben. Die Plattform würde niemals die Autorität über diese Systeme behalten, anfordern oder ausführen, und keine Aktion erreicht den Roboter, bis er eine ausdrückliche Genehmigung durchlaufen hat.
Wo menschliche Zustimmung sitzt
Jede Feststellungs- oder Neupositionierungsanfrage bedarf der ausdrücklichen Genehmigung eines benannten Ingenieurs, bevor sie als festgestellt oder umgesetzt behandelt wird. Dabei handelt es sich nicht um eine Richtlinie, die über dem Workflow liegt. Es ist der Mechanismus, durch den der Workflow überhaupt abläuft: Eine nicht genehmigte Phase führt den nächsten Schritt einfach nicht aus.
Worauf sich das heute stützt und worauf nicht
Der Workflow zur Feststellung von Feststellungen, der Lebenszyklus der vorgeschlagenen bis zur genehmigten Überprüfung und die unterzeichnete Prüfkette hinter jeder Aktion sind funktionierende Teile der Plattform. Was noch nicht Teil davon ist: ein roboterspezifisches Wahrnehmungsmodell, das auf der eigenen Ausrüstung und Umgebung eines bestimmten Bedieners trainiert wird, was genau das ist, was ein erster Pilot bauen würde. Das deterministische Steuerungssystem des Roboters bleibt konstruktionsbedingt vollständig außerhalb des Anwendungsbereichs der Plattform. Das technische Urteilsvermögen bei einem Robotikeinsatz verbleibt durchgehend beim eigenen Team des Betreibers, und alle anlagenspezifischen Wahrnehmungsfähigkeiten würden gemeinsam mit ihnen entwickelt und nicht als Standardmodell bereitgestellt.
Ein Teil der diesem Funktionsumfang zugrunde liegenden Architektur ist in noch laufenden Einreichungen dokumentiert. Auf dieser Seite wird beschrieben, wofür die Plattform konzipiert ist, und zwar auf einer Ebene, die für die Planung eines Pilotprojekts geeignet ist, und nicht als Implementierungsspezifikation.
Plattformfunktionen und Benutzeroberfläche unterliegen einer kontinuierlichen Verbesserung. Die Beschreibungen in diesem Handbuch spiegeln möglicherweise nicht das genaue Layout oder den Wortlaut der neuesten veröffentlichten Version wider.