Uptime Is Intelligence

Executive Summary

Humanoid robotics is often framed as an intelligence race: better foundation models, more dexterous hands, faster locomotion and increasingly general task execution. Industrial buyers, however, ultimately purchase productive time. A robot that performs an impressive task for minutes but requires frequent intervention, uncertain repairs or long diagnostic sessions is not an autonomous worker. It is an intermittent experiment. The durable engineering challenge is therefore to make operational continuity part of intelligence itself.

This chapter argues that availability, maintainability and fleet learning must be designed into a humanoid robot from the semiconductor level upward. Reliable hardware is necessary but insufficient. The robot also needs trusted sensing, deterministic control, protected diagnostics, explicit degradation modes, repairable modular boundaries, secure lifecycle data and an operating organization capable of converting field evidence into design improvement. International dependability practice treats availability as an outcome influenced by reliability, maintainability and maintenance support. Current IEC guidance explicitly connects maintainability and maintenance with managerial, technical and financial decisions across the lifecycle IEC 60300-1 IEC 60300-3-10:2025.

The central technical proposition is a distributed cyber-physical health architecture. Current, voltage, temperature, vibration, acoustic, torque, position, communication and behavioral signals must be acquired with trustworthy timing, interpreted near the physical process, correlated across the robot and converted into operational decisions. The objective is not merely to predict a failure. It is to bound consequences: continue safely, derate, isolate a joint, restart a controller, request human assistance, schedule maintenance or stop before damage propagates. In this architecture, semiconductors do more than execute nominal functions. They provide the evidence through which the robot understands what its own body can still do.

From Peak Capability to Productive Time

Robot demonstrations are optimized to answer a narrow question: can the system perform the task? Industrial operation asks a harder sequence of questions. Can the system repeat the task? Can it tolerate variations? Can it identify its own degradation? Can it recover without specialist intervention? Can it be maintained with predictable time, tools and spares? Can a fleet operator distinguish hardware failure from autonomy failure, safety intervention, infrastructure interruption or process mismatch?

These questions expose the difference between nominal capability and useful availability. A humanoid may have excellent locomotion, manipulation and perception yet deliver poor economic performance if its effective operating time is consumed by resets, calibration, charging, thermal limits, human assistance or waiting for replacement parts. Conversely, a robot with more modest peak performance may create greater value if it completes assigned missions predictably and returns rapidly to service after faults.

A useful availability model is operational rather than promotional. It measures the fraction of scheduled time during which the robot can perform its assigned function at an acceptable quality and risk level. It accounts for failure frequency, repair duration, planned service, software deployment, calibration, energy replenishment, safety stops and human recovery. High reliability with slow restoration can still produce poor availability. Fast repair cannot compensate for cascading failures or inadequate diagnostics. The architecture must pursue four linked outcomes: fewer disruptive faults, earlier detection, bounded degradation and faster restoration.

NIST’s robotics work illustrates why system performance must be decomposed into measurable components and then recomposed around real tasks. Its performance-assessment framework combines perception, mobility, dexterity and safety measures into task-level models, while its smart-manufacturing program emphasizes robots that are capable, perceptive, mobile, collaborative and quickly integrated into the enterprise NIST performance-assessment framework NIST smart-manufacturing robotics program. The same measurement discipline must be extended to uptime.

Dependability Is a System Property

Dependability is sometimes reduced to component quality. Better bearings, stronger gears, higher-rated power devices and more robust connectors are necessary, but system uptime cannot be purchased one component at a time. A humanoid is an interconnected network of actuators, sensors, processors, communication links, energy paths, structural members and software services. Failure in one element can propagate mechanically, electrically or logically into others. Availability therefore emerges from architecture, not from a parts list.

IEC 60300-1 describes dependability management across planning, design, measurement, analysis and improvement throughout the lifecycle IEC 60300-1. The important implication for humanoids is that dependability targets must influence system definition before detailed design begins. They should determine the partitioning of power domains, sensor redundancy, diagnostic coverage, connector access, thermal margins, fault-containment regions, software restart boundaries and maintenance procedures.

Reliability asks whether a function continues without failure. Maintainability asks whether it can be restored effectively. Availability combines these with the actual support environment. A replaceable actuator is not truly maintainable if the robot cannot identify the correct module, if calibration requires factory equipment, if the software rejects the replacement or if the spare is unavailable. Likewise, a highly reliable controller may still reduce availability if a minor software fault forces a complete-body restart rather than a local recovery.

The Distributed Robot Health Architecture

Observe the machine without blinding the controller

Humanoid joints already contain rich diagnostic evidence. Phase current reflects electromagnetic torque production and can reveal friction changes, winding abnormalities and load disturbances. DC-link behavior exposes energy-flow anomalies. Temperature sensors show local thermal margin and cooling degradation. Vibration and acoustic measurements can identify bearing, gearbox and structural signatures. Position, torque and current disagreement can indicate compliance changes, backlash, calibration drift, impact or structural damage.

Industrial condition-monitoring practice uses these complementary signals because no single measurement captures the complete failure process. Infineon describes current, temperature, acoustic and motion sensing as useful indicators for wear-related robotic-system degradation, while its broader system-diagnostics material connects continuous monitoring and anomaly analysis with predictive maintenance, optimized spare-parts planning and improved uptime Infineon, Improving Uptime in Industrial Robotic Systems Infineon system diagnostics and analytics.

The diagnostic design must not degrade the control function it is intended to protect. A monitoring channel that saturates shared bandwidth, disturbs interrupt timing or creates common-cause dependencies may reduce availability. Critical signals require defined sampling integrity, timing, plausibility checking and fault containment. High-rate features often belong in the motor-control microcontroller because the raw waveform already exists there. Cross-joint anomalies belong in a supervisory processor capable of correlating body dynamics, power conditions and mission context.

Convert raw signals into local evidence

Streaming every waveform to a remote service is neither economical nor dependable. Edge processing can calculate spectral features, thermal gradients, current residuals, load histories and event signatures while controlling data volume and latency. Microcontrollers, digital signal processing blocks, analog front ends and local memory form the first diagnostic boundary. Condition-based monitoring assesses the present state of the asset. Predictive maintenance adds models intended to estimate future degradation or remaining useful life Analog Devices predictive-maintenance overview.

Model confidence must accompany every diagnosis. A classifier trained on one gearbox revision cannot silently control maintenance decisions for another. Configuration identity, firmware version, calibration, component lot, maintenance history, task profile and environment belong in the digital thread. The health record must distinguish measurement from inference, and inference from recommendation.

Convert diagnosis into bounded action

The most valuable health output is not an alarm but an action policy. A humanoid may reduce acceleration when thermal or vibration margin narrows, redistribute load to other joints, disable a degraded manipulation mode, switch to an independent sensor, return to a service location or request supervision. This graceful degradation is more demanding than binary fault detection because it requires the robot to know which remaining capabilities are trustworthy.

For a statically stable machine, some faults can be handled by stopping motion. A dynamically balanced humanoid may require controlled motion to reach a safe posture. Health monitoring therefore interacts directly with functional safety, real-time control and energy availability. A controller cannot simply declare itself failed if doing so removes the actuation needed to avoid a fall. Fault-containment and recovery strategies must be analyzed at system level.

Designing for Repair, Not Only for Assembly

Maintainability is created through access paths, connector choices, modularity, calibration procedures, diagnostic coverage, test points, software tooling and spare-part policy. IEC 60300-3-10:2025 explicitly addresses maintainability and maintenance as technical, managerial and financial concerns IEC 60300-3-10:2025. That framing is particularly relevant to humanoids because compactness encourages tightly integrated assemblies whose field replacement may be difficult.

Integration reduces mass, volume and wiring, but it can turn a replaceable sensor or power stage into an expensive complete-joint replacement. The correct modular boundary depends on failure frequency, calibration coupling, contamination exposure, repair skill, inventory cost and acceptable downtime. A field-replaceable module creates value only when the robot can identify it securely, load the correct configuration, test it and verify the repair.

Fleet Learning Is a Dependability Function

A robot fleet creates operational evidence that no laboratory can reproduce completely: contamination, operator behavior, payload variation, network interruptions, charging practices, collision histories and long-tail component interactions. The installed base therefore becomes a development instrument. Each robot can contribute evidence about which conditions preceded degradation, which diagnostic signatures were reliable, which maintenance action restored performance and whether the corrective change remained effective.

Fleet learning requires disciplined event taxonomies. A safety stop, task-planning failure, thermal derating event, broken cable, encoder anomaly and human-assistance request must not all be labeled “downtime.” Event definitions should remain stable across software releases, while configuration metadata allows engineers to detect revision-specific patterns. The desired chain is symptom, context, physical or software mechanism, operational consequence, corrective action and verified outcome.

Evidence should also flow in both directions. A central fleet system can improve thresholds, maintenance planning and anomaly models, but local systems must remain capable of safe operation when connectivity disappears. The robot should not depend on cloud access for immediate protection. Fleet intelligence should improve the local health model through controlled updates rather than replace it.

Semiconductors Become the Maintenance Interface

In a dependable humanoid, semiconductor devices do more than execute nominal functions. They observe, timestamp, protect, isolate, remember and prove. Motor-control microcontrollers can compare commanded and measured current, track switching stress and retain event histories. Gate drivers and power stages can expose protection events and thermal conditions. Magnetic, pressure, inertial, radar, acoustic and current sensors provide independent physical evidence. Secure controllers and hardware roots of trust protect robot identity, configuration, logs and update provenance.

This creates a value opportunity across traditional product categories. The most useful subsystem may not be the sensor with the highest standalone accuracy, but the validated signal chain that connects a physical symptom to a trustworthy maintenance decision. Reference architectures should therefore define diagnostic coverage, sampling integrity, event schemas, cybersecurity, lifecycle data retention and safe reaction—not merely demonstrate a cloud dashboard.

Sensing and analog front ends

Health sensing requires dynamic range, bandwidth and stability matched to the degradation mechanism. Motor current may be sampled at control-loop rates, whereas slow thermal drift can be observed at lower rates. Vibration diagnostics may require anti-alias filtering, synchronized sampling and local feature extraction. Sensor placement is equally important: a high-quality measurement at the wrong mechanical point can create false confidence.

Real-time control and compute

Control processors must distinguish nominal disturbances from degradation without compromising deterministic execution. Diagnostic tasks need bounded compute time and defined memory behavior. Safety-related monitors may require independence from the algorithms they supervise. Heterogeneous compute can separate high-rate control, health-feature extraction, AI-based pattern recognition and fleet communication while maintaining fault-containment boundaries.

Power conversion and protection

Power devices, gate drivers, current sensors and power-management controllers determine both efficiency and diagnostic visibility. Overcurrent, undervoltage, short-circuit, desaturation and thermal events should be timestamped and interpreted in context. A transient caused by a legitimate impact differs from a recurring event caused by insulation degradation. Protection hardware should prevent damage, while the diagnostic system explains why protection was activated.

Memory, identity and lifecycle evidence

Health records require durable, protected storage. Configuration data, calibration, repair history and component identity must survive module replacement and software updates. Secure boot and authenticated update mechanisms reduce the risk that corrupted or malicious software falsifies health data. The semiconductor architecture becomes a trust anchor for the complete lifecycle record.

Safety, Cybersecurity and Availability Must Be Co-Engineered

Safety and uptime are sometimes portrayed as competing objectives: stop more often to be safe, or tolerate uncertainty to remain productive. Better diagnostics can improve both by distinguishing a recoverable anomaly from an unsafe loss of control. ISO 10218-1:2025 addresses the inherently safe design and risk reduction of industrial robots, while ISO 10218-2:2025 covers integration, commissioning, operation, maintenance and decommissioning of industrial robot applications ISO 10218-1:2025 ISO 10218-2:2025.

Humanoid robots will not map perfectly onto every existing industrial-robot assumption, particularly when they are mobile, dynamically balanced or intended for changing environments. Nevertheless, the lifecycle principle is durable: safe deployment includes maintenance, configuration control, information for use and verification after intervention. The ISO robotics portfolio also shows that safety and performance are addressed through several complementary standards rather than one universal rule ISO robotics standards portfolio.

Cybersecurity is equally inseparable from uptime. A falsified health signal could trigger unnecessary downtime, hide degradation or manipulate maintenance scheduling. Diagnostic logs may reveal sensitive facility processes. Secure boot, authenticated firmware, protected calibration, trusted timestamps, role-based service access and tamper-evident records support both security and dependability. Remote recovery must never become an uncontrolled remote-actuation path.

A Practical Uptime Engineering Program

1. Define mission profiles and availability targets. Specify scheduled operating windows, task quality, environmental conditions, intervention assumptions and acceptable degraded modes for each use case.
2. Create a fault and degradation model. Include mechanics, electronics, software, infrastructure, human interaction and maintenance errors rather than limiting the analysis to hardware component failure.
3. Map signals to decisions. For each relevant fault, identify observable variables, detection latency, confidence, fault-isolation method, safe reaction and required retained evidence.
4. Design service tasks. Measure diagnosis, access, replacement, calibration, verification and return-to-service time using realistic technicians, tools and spares.
5. Instrument pilot fleets. Use stable event definitions and configuration metadata so evidence remains comparable across sites, robot revisions and software releases.
6. Close the improvement loop. Convert recurring field evidence into component, architecture, software, process and maintenance changes, then verify their effectiveness.

NIST’s measurement-science program emphasizes quantitative methods that advance robot performance, collaboration, agility, autonomy, safety and implementation NIST measurement-science program. Uptime engineering should adopt the same philosophy: define measurable properties, expose assumptions and compare performance under representative tasks and environments.

Evidence Boundaries

Verified fact: IEC dependability standards provide established lifecycle concepts for reliability, maintainability, availability and maintenance. ISO 10218 was revised in 2025 and addresses robot design, integration, operation and maintenance. NIST develops quantitative robotics performance methods.

Company claim: Semiconductor vendors describe condition monitoring, system diagnostics and predictive maintenance as methods to improve uptime and optimize maintenance. These claims are technically plausible and align with established industrial practice, but performance depends on implementation, data quality and operating context.

Editorial interpretation: Humanoid robots will need to elevate these practices into a distributed cyber-physical health architecture because dense actuation, active balance, software complexity and general-purpose deployment couple fault consequences across the body. This conclusion is an engineering synthesis rather than a published industry consensus.

Conclusion: The Robot Must Earn Its Operating Hours

The decisive industrial comparison will not be between the most humanlike robots, but between systems that deliver useful work predictably. Intelligence that cannot recognize its own degradation, protect remaining capability, explain intervention needs and improve through fleet evidence is incomplete. Uptime is not a maintenance statistic placed after autonomy. It is a system-level expression of sensing, control, semiconductor integrity, software architecture, service design and organizational learning.

The commercial winner will make failures less frequent, less surprising and less consequential. It will turn every operating hour into evidence and every repair into a design input. In that architecture, semiconductors form the sensory and trusted substrate through which the robot understands not only what the world is doing, but what its own body can still do safely.

Glossary

Availability

The ability of an item to be in a state to perform a required function under stated conditions, assuming required external resources are provided.

Condition-based monitoring

Continuous or periodic observation of physical variables to assess current asset health and detect developing faults.

Digital thread

A traceable flow of configuration, operational, maintenance and design data across the product lifecycle.

Graceful degradation

A controlled reduction of capability that preserves essential functions when faults or constraints occur.

Maintainability

The ability of an item to be retained in or restored to a required state under stated maintenance conditions.

MTBF

Mean time between failures; an average interval between successive failures of a repairable system.

MTTR

Mean time to repair; the average elapsed time required to diagnose, repair, verify and restore a failed item.

Predictive maintenance

A strategy using condition evidence and models to forecast failure or remaining useful life.

Reliability

The ability of an item to perform as required without failure for a specified interval under stated conditions.

References

1. International Electrotechnical Commission. “IEC 60300-1:2003 — Dependability management systems.” 2003. https://webstore.iec.ch/en/publication/14631
2. International Electrotechnical Commission. “IEC 60300-3-10:2025 — Maintainability and maintenance.” 2025. https://webstore.iec.ch/en/publication/65334
3. International Organization for Standardization. “ISO 10218-1:2025 — Robotics — Safety requirements — Industrial robots.” 2025. https://www.iso.org/standard/73933.html
4. International Organization for Standardization. “ISO 10218-2:2025 — Robotics — Safety requirements — Industrial robot applications and robot cells.” 2025. https://www.iso.org/standard/73934.html
5. International Organization for Standardization. “Robotics standards portfolio.” https://www.iso.org/sectors/engineering/robotics
6. National Institute of Standards and Technology. “Performance Assessment Framework for Robotic Systems.” https://www.nist.gov/programs-projects/performance-assessment-framework-robotic-systems
7. National Institute of Standards and Technology. “Robotic Systems for Smart Manufacturing Program.” https://www.nist.gov/programs-projects/robotic-systems-smart-manufacturing-program
8. National Institute of Standards and Technology. “Measurement Science for Robotics and Autonomous Systems Program.” https://www.nist.gov/programs-projects/measurement-science-robotics-and-autonomous-systems-program
9. Infineon Technologies. “System diagnostics and analytics.” https://www.infineon.com/applications/solutions/system-diagnostics-and-analytics
10. Infineon Technologies. “Improving Uptime in Industrial Robotic Systems.” 2018. https://www.infineon.com/dgdl/Infineon-Improving_Uptime_in_Industrial_Robotic_Systems_EENews-ART-v01_00-EN.pdf?fileId=5546d46266f85d630167081db3c931ee
11. Analog Devices. “Predictive Maintenance Solutions.” https://www.analog.com/en/solutions/industrial-automation/predictive-maintenance.html