When we tested the failure scenarios at NIST, we found the system to be very resilient, explains Will Sobel, CEO at System Insights. Since each device can determine if it can recover from an alarm or error, there is no need for a central system to arbitrate simple situations like out of material or a dropped work piece. The robot will just carry on. It has one task: deliver a piece of material to the machine tool and complete the task. All recoverable scenarios are handled. The scenarios are also fairly general and can be used across multiple parts and processes. For example, a dropped work piece can be recovered by getting another work piece and carrying on.
Software systems and advanced architectures provide greater flexibility and reliability. This is true for a simple bar-feeder up to a mobile robotic platform that can collect the necessary material and load a machine or perform assembly. By using software system architectures that are similar to what has been used to coordinate thousands of machines in data centers, the science of integrating manufacturing equipment can be similarly improved.
Another benefit of this solution is additional components can be added dynamically if needed and workflow can be altered based on part and process. For example, if the inspection station becomes the bottleneck, an additional gauging station can be added and only the robot need become aware. The new inspection station will make a request to have material loaded, and all that the robot needs to know is where to place the material physically in the gauge. The remaining workflow is identical and will not need to change. As well, if there is no inspection plan available for the current part, the inspection station will tell the robot to skip the inspection step for that part type. All this information will be communicated without the need for central control, each device deciding its own activities based on the current part type and its knowledge of the steps that are required to complete the manufacturing process. Similarly the output conveyor would be the input for the next process, and, if the next equipment is MTConnect-ready, you can horizontally integrate as needed.
Simple process dependency and flow, as well as system-wide monitoring and distributed coordination, will allow devices to communicate their needs and stationary or mobile platforms to service them. This swarm behavior has been tested in the lab for various collaborative automation projects, mainly for toy university projects. We have taken the architecture and distributed intelligent components and figured out how to make this into an industrial platform for integrating disparate devices. The core lies in providing the correct level of communication and moving the complexity to the component of the system that has the most knowledge, reducing bandwidth and decreasing reaction times.