New Robot Operations Group Is Solving Fleet Management Problems

Introduction

In this article, we introduce you to the Robot Operations Group, a new working group with the mission of addressing the issues around remote monitoring and remote management of robotic fleets. In the last couple of years, many of the robot manufacturers have attempted to custom-build their own robot operations software from the ground up. In addition, several software-only companies have emerged in the last two years to tackle the problem of creating a universal robot operations software solution.

What is the Robot Operations Group?

The Robot Operations Group (ROG) is a cross-industry working group aimed at developing and sharing best practices for the operation at scale of autonomous robots. Robot Operations (RobOps) encompasses all of the processes for managing autonomous robot fleets. Many of the emerging autonomous mobile robotic companies are trying to solve RobOps problems from scratch. The mission of the ROG is to develop and share the best practices for RobOps, and enable the industry to quickly evolve. The ROG currently includes members from robot manufacturers, robot software vendors, end users and university researchers.

The ROG is attempting to define the best practices for solving the problems of managing a large, remote fleet of robots. While the concepts are initially targeting autonomous mobile robots (AMR) the concepts are applicable to fixed robot fleets as well.

The Foundation of the ROG

The RobOps Group was formed by two individuals: Florian Pestoni (CEO of InOrbit) and Joe Wieceik (Software Operations Manager for Brain Corp). The RobOps working group has expanded to include 54 individuals from a variety of member companies.

The ROG started meeting regularly in April 2020 to begin the discussion and creation of best practices and it was initiated by a meeting of like minds at the 2019 Robobusiness show. There currently are no accepted standards for any of the processes that the group is addressing, however that may be one endgame for the output of this working group. The ROG meets once every 6 weeks to stay engaged.

The RobOps Manifesto

Every good working group has to start with a manifesto, and the RobOps working group is no different. You can find the complete manifesto on the ROG website.

The core of the ROG Manifesto is the following:

Modern robots are complex systems. While they can achieve a high degree of autonomy, there are still what we call autonomy exceptions, where the robot cannot continue operating safely nor efficiently.

Effective operations at scale require:

Accepting that autonomy exceptions will occur
Taking steps to resolve the exceptions immediately
Reducing the incidence of exceptions over time

RobOps Is Key For Robotic Service Providers

The Mobile Robot Guide was the first to identify the need for Robotic Service Providers (RSP). We are predicting that in the future, a new type of channel partner will emerge in the robotics industry, called a Robotic Service Provider. The business model of robots-as-a-service (RaaS) is now widely accepted. RasS enables an automation end user to pay for the automation services in a subscription model.

An RSP is simply an organization that deploys autonomous robots across a variety of end customers and uses RaaS as a business model. The RSP owns the actual robots, and is responsible for the operation and maintenance of the solution. Customers only pay for the service provided by the robots.

The processes of RobOps are central to the services delivered by an RSP. Thus, the success of RSPs depend on the maturity and adoption of the processes being addressed by the ROG. We will continue to monitor and follow the progress of this working group.

The Core RobOps Issues

The manifesto goes on in detail to explain the problems being addressed by the group. If you are managing a large fleet of robots, then you will be familiar with many of the issues. The issues are compounded when these issues need to be addressed remotely. So whether you are working as a support tech for a robot company or internally managing a fleet of robots on your own factory floor or warehouse, you are familiar with the chaos in getting a system back online and functional.

The Failure Reporting Analysis and Corrective Action System (FRACAS) diagram

The Failure Reporting Analysis and Corrective Action System (FRACAS) diagram (image courtesy of RobOps)

Monitoring/Observability

In this definition, observability supports drilling down and understanding implicit failure modes. The ROG is adopting and adapting best practices from IT Service Management (ITSM), as a robot fleet is really nothing more than a distributed system, with compute/storage/networking on each robot. Developing a system to gather, reconcile, monitor and manage alerts helps the robotic fleet manager to quickly understand when a problem has occurred and then take action to resolve it.

Configuration Management

Likewise, the ROG is also borrowing best practices from ITSM for managing and updating the (software) configurations of each individual robot. Similar to how companies have historically managed the software and apps on employee laptops, ROG sees a fleet of robots in a similar fashion. By deploying a software agent on the robots, it becomes possible to track, manage and troubleshoot problems when they arise.

ITSM solved these system management problems two decades ago with well defined processes for configuration management, incident management and problem resolution. The software development processes of continuous integration (CI) and continuous deployment (CD) also offer a time-tested framework to help the robot manufacturers continuously improve their solutions that are deployed in the field. The acceptance of cloud-robotics puts the CI/CD processes on a critical path for overall growth in this market.

Safety, Security and Auditing

The ROG also addresses critical issues around robot safety, security and auditing. Many end users balk at accepting cloud-enabled robotic solutions because it creates a clear and present danger as an attack vector for hackers. Adding to this, many robotic startups are immature in their information security processes, given that they are roboticists and not cloud experts. The ROG intends to address these issues so that robotic startups can begin from a more mature and well intentioned architecture for their remote operations features.

Interventions

Lastly, ROG is discussing the process of intervention in the case of a remote system failure. The group is looking at frameworks such as Closed-Loop Corrective Action (CLCA) to identify, analyze, and correct a problem with a product or process. Runbook automation is yet another mature ITSM process that provides an established structure for recovering from a system failure.

How Can You Contribute?

The ROG is open to anyone who wants to contribute. Start by reading the ROG Manifesto. Then if you are interested, join the group discourse or their Meetup Group. The group meets every 6 weeks.