Robot availability needs an operating definition

A percentage without a definition cannot be compared

A robot availability target only becomes useful when everyone counts the same system, time and outcome. A controller can remain powered while a failed gripper, unavailable fleet service or blocked interface prevents the configured application from completing work. A bare uptime percentage can hide that difference.

SEMI E10-0422 provides one industry-body example of disciplined measurement. Its public scope defines multiple uptime measures and six mutually exclusive equipment states over an observation period. SEMI E10 applies to semiconductor and related manufacturing equipment, not universally to robotics, but it demonstrates why the measure and state rules must be named before two claims can be compared.

Start with the required operating window

IEC's dependability vocabulary defines required time as the interval during which an item is required to be up. Its availability entry says time intervals are assigned to up or down states or excluded. For a robot project, the practical requirement is therefore a versioned counting rule, not a percentage copied from a proposal.

• State the scheduled days, shifts, start and end times, breaks, peaks and observation period.
• Name the required outcome, such as the configured cell completing the accepted task—not merely a powered robot controller.
• Define how planned maintenance, cleaning, charging, calibration, setup, product changeovers and customer-caused stops are treated.
• Separate productive, ready-but-waiting, degraded, planned-down, unplanned-down and outside-window states so every measured interval has one agreed treatment.
• Approve the formula and exclusions before measurement starts; do not change the denominator after a poor result without a recorded review.

Measure the configured system, not a convenient component

Draw the boundary around everything required for the promised outcome: robot, controller, end effector, sensors, safeguards, PLC, conveyors or doors, fleet software, network, chargers, utilities and material upstream or downstream interfaces. Dependencies outside the main measure should still be reported separately with a reason and data owner.

Tie each result to the exact asset, hardware, software, firmware, application program, tooling and relevant site configuration. Otherwise a dashboard can silently combine different operating conditions or carry evidence across a change that affected the result.

Recovery has more than one clock

IEC distinguishes time to restoration, which runs from failure until restoration, from active repair time, which excludes technical, administrative and logistic delays. That distinction matters to an operations team: a short hands-on repair does not mean a short production interruption if detection, access, diagnosis, parts, restart or validation take longer.

• Define separate timestamps for detection, notification, acknowledgement, remote diagnosis, on-site attendance, part availability, technical repair, validated restart and stable accepted production.
• Record the initiating event, affected dependency, reason code, responsible party, intervention steps and any temporary restriction.
• Set an intervention-rate requirement as well as a duration target; repeated operator rescue can fail the operational need even when the system is reported as available.
• Define who may recover the system, the required competence, approved procedure, tools, spares, access, backup and escalation path.
• Treat return to the accepted configured task as the recovery endpoint. A cleared alarm or reboot is not enough if the task has not been revalidated.

Put maintenance and support ownership into the offer

IEC 60300-3-4:2022 publicly describes quantitative and qualitative reliability, maintainability, supportability and availability requirements together with means of assuring them. IEC 60300-3-10:2025 covers life-cycle maintenance programmes and maintenance data, while IEC 60300-3-14:2024 connects support activities with reliability, maintainability and availability. Those scopes support treating support as part of the operational requirement, not an after-sale footnote.

Name the customer, integrator, manufacturer and third-party responsibilities for monitoring, first response, diagnosis, maintenance, software, consumables, spares, repair, escalation and evidence export. Also state support hours, region, communication channel, preventive-maintenance windows, remote-access conditions, warranty boundaries and end-of-support handling.

Instrument the evidence without turning telemetry into proof

OPC UA for Robotics Part 1 version 1.02 describes access to asset, operational-state and condition-monitoring data such as motor temperature, load and on-time. That can help identify the exact asset and provide inputs for maintenance and availability analysis. It does not prove that a proposed robot exposes every needed field, that its state map matches the buyer's counting rule or that the resulting availability figure is correct.

KUKA currently claims that some of its service packages can include a priority hotline, a maximum time for specialists to start and a maximum time for standard-spare-part supply, depending on the contract. Those are KUKA manufacturer claims about its own offers, not independently verified restoration results and not evidence for another provider or region. Response, attendance, part supply, repair and accepted production restoration must remain separate milestones.

Agree the evidence before acceptance

The cited IEC catalogue pages describe standards scopes; their full paid texts were not reviewed for this article. SEMI E10 has a defined sector scope, OPC UA defines information models, and KUKA describes its own service offer. None independently certifies a robot application or guarantees its performance. RobotAtom records the availability requirement, evidence, ownership and unknowns. It does not certify availability, safety, suitability or compliance.

• Approve the operating window, formula, system boundary, state map, exact configuration and data sources before the trial or observation period.
• Use attributable timestamps and reason codes, and reconcile missing telemetry, clock drift, manual edits and overlapping faults.
• Exercise agreed failure and recovery scenarios under representative conditions, including unavailable dependencies and interrupted tasks.
• Preserve raw evidence, calculations, exceptions, reviewer, date and decision, and state what the observation period cannot establish.
• Continue production monitoring where a short trial cannot support a longer-term availability conclusion, and reopen the evidence after material changes.