Operational Considerations for a Robotics as a Service

Preamble

Surely whole point of a robotics as a service (RaaS) is to deploy robots and get paid. But there are a lot of considerations that are easy to overlook when making sure you are ready.

The idea for most people who get into this field often looks something like this:

  1. Design a robot
  2. Build some of those robots
  3. Deploy them
  4. …
  5. Profit?

But inside those ellipses be dragons. Let’s try and figure out how to conquer them.

Pragmatism

A hard truth about RaaS is that the robot is only part of the business model.

Too often engineers are focused on building things but the service requires that you build an operational team of people and procedures to enable the robot.

It’s useful to think of the robot as a tool that the Operations team will use to provide the service, especially early on if the robot won’t be a fully autonomous solution from day one. This also allows for a significant part of the product development feedback to be from an internal customer, the Operations team.

Lean Principles and Hardware Development

The Lean Startup is now widely considered obligatory reading for leaders in startups. The core idea is that the most egregious time waste is working on a product that customers do not want and that the solution to this is to run experiments on your prospective customer base in order to learn what they really want and cater to that need. This is accomplished through build, measure, learn feedback loops, and the goal of the product development team should be to get through as many of these loops as quickly as possible. There are many similar frameworks for development that put the customer forward, such as the powerful and popular Agile.

I think that this is a great tenet and that it works very well in particular scenarios. Build, measure, learn feedback loops are important for product development and also quality management. Often quality management systems and practices like ISO-9001 form similar loops. Trying to implement these loops, fast, in robotics when hardware is involved is beyond challenging for most companies, especially if resources are such that you can’t have several teams working in parallel.

These development practices often struggle without continuous integration and continuous delivery (CI/CD) to back them up. CI/CD is pervasive in software development, where product overheads are low. When it comes to hardware development these practices are often impotent. In a world of suppliers, manufacturing partners, lead times, bills of materials, procurement and drawing packs, Waterfall planning and risk analysis/ mitigation are still going to be the best way to make sure that hardware is delivered on time.

However, I would still argue that in the early days of a startup it is critical to get your product out there in front of customers early, so you can apply any course corrections as soon as possible. Minimum viable product (MVP) is a term you hear a lot around startups, but on real robots there are mission critical systems and a real chance to endanger human life, even in simple domestic scenarios. An MVP, clearly, isn’t going to cut it for many systems. Even on less critical system this will mean putting out products that are prone to failure, due to a lack of development and testing time. With much of the testing being done post-deployment.

How should you balance the need to get something in front of customers for feedback and the need to make working, reliable, safe hardware?

Understanding Early Stage Deployment

As mentioned earlier RaaS requires an operational team of people and procedures to enable the robot to carry out it’s tasks. The amount of development work on the robot has an inverse relationship to the amount of people and quality of the procedures required to operate it.

In an early stage startup it is foolish to think that you can develop yourself out of the need for an Operations team and a solid set of operating procedures.

In fact it might be better to lean in the opposite direction early on. Having the tools, people and procedures to fully operate a robot could be a great way to get your service out in front of real customers, without time spent developing high levels of autonomy or durability. It also gives you something to fallback on should the robotic product not be perfect first time, spoiler, it won’t be. Monitoring the work load of the Operations team allows you to figure out what the key features your robotic platform needs to make the Operations team’s lives easier. This helps keep the development time down by working on what is actually required, rather than trying to guess every edge case you might encounter.

Operational Requirements

In order to build an Operations team you need to understand what tasks they will be undertaking. Will they be teleoperating the robot? Will they be carrying out service and repairs? Will the need to assist customers with technical support? If so will this be on site or remote?

There are three types of operational support regularly provided to deployed robots in the field:

  • human operation - making up for a lack of human robot interaction or user interface and lack of autonomy
  • hardware maintenance and repair - making up for lack of durability
  • robot swap out - also making up for lack of durability (for scenarios where repair will take longer than allowable service down time)

Human Operation

Let’s take a deeper look at human operation, starting with some assumptions. A robot operates during daylight for 16 hours a day, for 10 months of the year. It can work for 3 hours at a time and needs 2.5 hours to recharge. Three working sessions and two charges can happen during the available daily 16 hours, assuming the robot can charge over night and is fully charged at the start of the day. Operating in this way allows for 21 working sessions per week, or 910 over the reduced 10 month year.

Consider employing a team of operations staff to monitor, run and support robots, seven days a week over the daily 16 hours available for work. These could be split into two eight hour shifts. Here, I’m also assuming that the Operations team are located in the same time zone as the deployed robots.

Using a few different cases for a fixed level of available operational capacity we can model how many robots could be deployed, at various levels of autonomy, ie. required human operation time.

\[ Human Operation Ratio = \cfrac{Operational Capacity(days/year) * Daily Operating Time(Hours)}{Number Of Robots * Number Of Working Sessions(/robot year) * Factor Of Safety} \]

The equation above is used in the following plot (figure 1) to show lines show a constant operational resource capacity. For a given capacity you can hover over the plot and get an idea of how the development of the robot needs to progress as more robots are deployed. Alternatively, you could rearrange the equation for a known level of autonomy to predict how much operational capacity you require at a given stage of development.

Figure 1: Human Operation Requirement

Durability

A plot for the time required to maintain and repair robots follows a similar shape so I have omitted it from this post, but it should not be omitted from planning and setting up a RaaS Operations team. It should logically follow that the more time spent developing the reliability and ease of maintenance of your robotic platform the less time will be required for field repairs and maintenance.

Deployment

It’s important to take the time to evaluate where a business is, both technically and operationally prior to moving forward with robot deployment. When we choose to deploy we essentially step onto the above plot at some point, for a given technical readiness of the robot, number of robots to be deployed and operational capacity to support them. Working on robot development projects should enable us to travel down the y-axis of the two plots mentioned previously. This should have you reducing either the required human interactions or reducing the likelihood of failure, or both. Going to manufacture and deploying more robots allows us to travel to the right on the x-axis. Hopefully you never travel back up the y-axis but this may happen if a bad development makes it into the field.

Operational Workflows and Procedures

I just wanted to add a word on some of the operations procedures that need consideration, this list is not by any means exhaustive but hopefully it sparks the right sort of conversations as it is often tricky to get those developing the robot to engage with these more practical considerations. These are split into three phases of a robots life.

  1. Manufacture

    • Who will purchase any raw materials and off the shelf componentry?
    • Who will manufacture any custom plastics, metalwork, PCBs?
    • How will all these parts make it to the assembly line?
    • How will custom parts be checked for conformity to specification?
    • Who will assemble the robot?
    • What are the critical assembly methods?
    • How will you ensure consistency of assembly?
    • Who will ensure that the correct version and level of software and firmware is present?
    • Who will calibrate any sensors and set correct configurations?
    • Are you recording the state of the robots part serial numbers and firmware software versions at manufacture?

  2. Deployment

    • Have you carried out a risk assessment for a given deployment? To consider any chances for the robot to harm people during use.
    • For a given site have you established a risk management plan?
    • What other hardware or physical infrastructure (power, wifi, etc.) does the robot need?
    • If that isn’t available who will provide it and when?
    • How will the robot and associated hardware reach the deployment site?
    • Who will deploy the robot and any associated hardware?
    • Are there any site specific configurations that need to be created?
    • How will deployment be confirmed?

  3. Use

    • How will the robot be used?
    • What times of day will the robot be used?
    • Can the robot operate in all weather conditions?
    • Does the robot need on-site supervision of any kind?
    • Does the robot need off-site supervision of any kind?
    • What level of control does a supervisor need?
    • What is the flow of actions that need to take place for the robot to carry out the service?
    • How are those actions going to be chained together into robot behaviours?
    • What/ who will trigger the robots behaviours to start?
    • What happens if there is an issue?
    • How are faults recorded and categorised?
    • How are faults fedback into the design process?
    • How are critical issues escalated and dealt with? Especially if there are other deployed robots at risk.
    • Who will create any containment and mitigation actions?
    • Who will carry out any containment and mitigation actions?
    • Are there critical or difficult maintenance operations that need documentation?
    • What maintenance operations are required and at what frequency?
    • Who will be carrying out maintenance on the robot?
    • Who will be the first line of response to triage the severity of the fault?
    • How will the first responder diagnose the issue?
    • How will you ensure consistency of repair?
    • What happens at the end of life?
    • How will the robot be recovered and reused / recycled?

Hey you!

Found this useful or interesting?

Consider donating to support.

Any question, comments, corrections or suggestions?

Reach out on the social links below through the buttons.