Resilient Federated INTERSECT Autonomous Additive Manufacturing Experiment Demonstration

Engineering notes

Key topics: self-driving, control. See the paper for implementation details and experimental results.

Chinese explanation / 中文解读

中文解读待补充：本站会优先为端到端自动驾驶、BEV感知、3D目标检测、轨迹预测、路径规划、LiDAR感知等高价值论文补充中文说明。

Original abstract

Modern scientific research uses modeling, simulation, data analytics, and artificial intelligence (AI). The automation of such processes in the context of experiments reduces human-in-the-loop needs and future laboratories will be “self-driving”. The involved instruments and computing/data resources are federated to orchestrate distributed workflows. Failure resilience in federated ecosystems for instrument science presents a critical challenge. Failures disrupt experiments and make them potentially useless, wasting valuable resources and creating setbacks. Oak Ridge National Laboratory’s Self-driven Experiments for Science / Interconnected Science Ecosystem (INTERSECT) offers a federated ecosystem for instrument science, enabling autonomous experiments, self-driving laboratories, smart manufacturing, and AI-driven design, discovery, and evaluation. This work documents the recent advances in creating a resilient INTERSECT ecosystem. The proposed solution includes a resilient architecture with resilience design patterns, a resilient system of systems (SoS) architecture, and a resilient microservices architecture; and a resilient software development kit (SDK) with reliable service communication and asynchronous and synchronous failure detection and notification. The resilience capabilities are demonstrated for an autonomous additive manufacturing (AAM) process with a real-time feedback loop.The demonstration of the INTERSECT AAM cross-facility experiment offers fail-stop and fail-over resilience capabilities of a real-time feedback loop using theresilient INTERSECT ecosystem architecture and SDK. These resilience capabilities have been tested by injecting various failures. This artifact is a video of a part the testing campaign that demonstrates the following three scenarios: The active path accepts the simulation request but returns no results. After the configurable 60-second per-request timeout elapses, the proxy re-sends the same request to the standby path, which takes over seamlessly. Notably, in this specific scenario the active is not marked down — a timeout can be transient, so it stays in rotation. The active path stops answering the watchdog’s heartbeats entirely. After three consecutive missed configurable 30- second heartbeats the proxy declares it unhealthy and removes it from rotation — this, not a one-off request failure, is what takes it out of service. The active path starts answering the watchdog’s heartbeats again; on that recovery the proxy automatically fails back to the higher-priority active path, and control updates resume flowing from it. Throughout, the workflow keeps running — control updates continue reaching the printer across every scenario.

Links and sources

Comments