A Control Design reader writes: More factories are asking about how they can incorporate robotics or autonomous mobile robots (AMRs)/automated guided vehicles (AGVs) into their current production lines and machines. We work with electronics manufacturers, and some can have up to a dozen work cells for assembly with operators and machines from raw material to finished product. Our experience with robotics is limited to new development, where we can start from scratch. We’ve found it harder to integrate robotics into existing lines and work cells, and mobile transports are often limited to the manufacturer’s own specific fleet-management software. How do we begin to incorporate these technologies with our existing customers? What standards are guiding interoperability between robotics and machinery? How do we start small and scale slowly? And how do we accommodate customers looking for full-scale automation upgrades?
Answers
Prioritizing device integration in the software stack will ease interoperability challenges
Interoperability challenges can be extremely frustrating, especially when they follow on the heels of a significant capital-expenditure spend.
But some interoperability challenges are actually software-architecture problems in disguise. More specifically, you might simply be trying to integrate devices in the wrong part of the software stack.
In simple terms, a software stack is the hierarchy of software that comes pre-installed on the device. On industrial robots the software stack is commonly structured as low-, mid- and high-level, with each level handling different processes.
For example, at the low level, you will find software that deals with currents, encoders and safety stops. Mid-level refers to software that typically handles motion planning, kinematics and external I/O interaction. Meanwhile, software that handles the user interface and non-safety-related operator button clicks is referred to as high-level.
This structure makes it easy to give priority at a central-processing-unit (CPU) level to the tasks that are most important. In the case of industrial robots, priority is often given to safety-related tasks.
Different companies often have different processes for adding features in the different levels of the software stack. This often means that software in the low-level part of the stack gets scrutinized more than its high-level software counterpart. This makes sense, because ensuring that the safety-stop code is bug-free is at the top of most companies’ priority list, but it can also mean drawbacks.
In practice, it is possible to integrate your software and/or devices at any level of the software stack, but each level has benefits and drawbacks.
As a general rule, if you find integration extremely cumbersome, you were likely trying to integrate it at the lowest level of the stack. Manufacturers leave this low-level integration path open to enable advanced use cases, such as real-time synchronization. The good news is, for many applications, this low-level integration is completely unnecessary.
Avoid the common misconception that you need to integrate at the lowest levels to increase process speed: This is usually not the case.
On the higher-level of the stack, integration tends to be more developer-friendly. Moreover, at the high level, developers tend to have lots of options when it comes to communications protocols, including representational state transfer (REST) architectural-style application programming interfaces (APIs). The downside of choosing integration with this part of the stack is that it can provide limited access to low-level telemetry at high rates.
Even with a good understanding of high-, medium- and low-level software interfaces, you might still find yourself in a situation where it is difficult to integrate Brand A robot with Brand B AGV.
In these situations, it can be good to make use of an intermediary system. Supervisory control and data acquisition (SCADA) systems are sometimes used in these scenarios, but they do require some expertise to use effectively. At the other end of the complexity scale, an industrial Windows PC with a set of small Python scripts can work wonders. And C# programming provides yet another option for overcoming integration challenges.
Integrating robotics, AGVs and devices isn’t always easy. However, a solid understanding of the available software stacks will get you a long way there.
Fredrik Ryden / CEO / Olis Robotics
AMR fleet management systems can simplify integration
A work cell can mean different things. For our purposes here, our focus is on the machines of manufacturing and how robots are interacting with machines. The work cell could include one specialized person working with machinery, a group of work cells and operators working together or a fully automated line of machines and robotics.
Most of Otto Motors deployments are in existing facilities. Because autonomous mobile robots don’t require additional physical infrastructure and because they can autonomously navigate around people, obstacles and other vehicles, they can drop into existing facilities quite well. It’s one of the core benefits of the technology.
AMRs can transfer material between many kinds of work cells with a variety of transfer mechanisms. Smaller payloads can be loaded and unloaded by people from fixed carriers. For material that needs to be moved by a person or a robot, depending where in the workflow it is, AMRs can carry dual purpose carts that hold the material. For heavy or cumbersome material, AMRs can have attachments like lifts, conveyors or custom attachments that can automatically receive material from one machine and load it into another machine.
This last work cell integration we call connecting “islands of automation” and turning them into “networks of automation.” It’s very compelling for customers because they spend millions of dollars on their manufacturing equipment and want to avoid relying on manually driven vehicles to move the inputs and outputs between them. It gives them a much higher return on investment (ROI) on the entire multimillion-dollar system to have AMRs safely and reliably connect the islands of automation.
So, how do we begin to incorporate these technologies and what standards are guiding interoperability between robotics and machinery? An AMR fleet management system can manage AMRs, but it can also be responsible for integration to all the factory endpoints described above. The fleet management system can have REST, web socket and OPC UA APIs for machinery to call into it. It can also connect easily to factory-programmable logic controllers (PLCs) using OPC UA calls managed by Ignition, Kepware or similar systems. It also maintains interlocks for simple management of shared state and handshakes.
Using these standard mechanisms, an AMR fleet-management system provides a simple and scalable integration point between the AMRs and the factory. Integrations that can be accomplished include but are not limited to:
● material transfer between robots, attachments and work-cell equipment
● managing automatic doors
● following traffic lights along with manual and AGV traffic.
And how do we start small and scale slowly? Most of our customers start by automating discrete workflows with a few robots and a fleet manager. This provides a low-cost exposure to working with AMRs, mapping, job setup, factory integration, troubleshooting and maintenance. As workflows succeed and show value in terms of safety and business continuity, and as customers become comfortable with the technology, they expand into other workflows, and in some cases, standardize on Otto AMRs for material transfer for greater ROI.
Lastly, how do we accommodate customers looking for full-scale automation upgrades? Some customers do a complete overhaul and deploy up to 100 AMRs at once in a greenfield environment. For large-scale projects, the services team from Otto Motors and any partner, such as a system integrator, work together to construct a map, traffic rules, job definitions and factory integrations. For large overhaul projects, we add simulation. For a small robot job, it doesn’t matter if the workflow requires 2.1 or 2.7 robots, it just rounds up to three. But, in a large deployment, facility, traffic rule or workflow optimizations can become magnified with small differences resulting in the removal of many robots from the deployment, which yields dramatic increases in ROI. Otto Motors has simulation technology that we use with the customer and/or partner. We can run an arbitrary number of scenarios, evaluating whether they will work technically, have sufficient throughput and result in the best ROI.
Jay Judkowitz / vice president of product / Otto Motors by Rockwell Automation
