Short answer
Pick maintenance tasks for data collection by scoring them on how often they occur, how much they vary, how reachable the equipment is, how risky a failure is, and what data already exists. Work-order records give frequency cheaply. Variability and access need site knowledge. Tasks that are frequent, bounded and well documented usually make a better first collection than rare, high-variance repairs.
The decision this page supports
A maintenance operation performs hundreds of kinds of task. A data program can cover a handful at the depth a model needs. Choosing them badly produces a pile of footage on tasks that are rare, equipment-specific or unsafe for a robot to attempt, while the tasks that dominate the workload remain unsampled.
This guide gives a way to rank tasks before scoping collection. It is part of the maintenance cluster and the humanoid data guide. It does not say which tasks a robot should do; that depends on your platform and risk limits. It helps you turn task candidates into a ranked list you can write into a requirements specification.
Step 1: name the candidate tasks
Start with a common vocabulary. O*NET publishes task statements and detailed work activities, with a file mapping tasks to those activities; statements are retained only if their relevance rating is 25% or higher (O*NET Resource Center). It is an occupational taxonomy rather than a maintenance catalog, but it offers shared names that help compare tasks across employers. For your own sites, the more concrete source is the supplier's maintenance records: planned-maintenance tasks, work-order types and checklists. See preventive maintenance checklists and facility maintenance tasks.
Step 2: measure frequency from records
Counting is usually the cheapest step and one that existing records can often answer. Logbooks and work orders are written as short, abbreviated text, as MaintNet's logbook data and abbreviation lists for aviation, automotive and facilities domains show (Akhbardeh et al., 2020). Normalize them before counting; see work-order histories and normalizing technician shorthand.
Useful counts: orders per task type per year, planned versus reactive share, distinct equipment models per task, and labor hours per task. Frequency alone misleads: a task done 10,000 times a year on 500 different machine models may be less learnable than one done 1,000 times on three.
Step 3: score the criteria
| Criterion | What to estimate | Higher priority when |
|---|---|---|
| Frequency | Occurrences per period across the target sites | The task recurs often |
| Variability | Distinct equipment models, fasteners, layouts, failure modes | Variation is bounded and listable |
| Access | Clearance, height, tool reach, visibility to a body camera | A humanoid-scale body can reach it |
| Contact demand | Force, torque, tactile feedback needed | Low or well characterized |
| Risk | Energy, heat, chemicals, falls, customer impact | Failure is tolerable or controlled |
| Data availability | Existing records, footage, documentation | Some assets exist to build on |
| Labor value | Time and cost per occurrence | Large enough to matter |
Do not accept a single weighted score as an answer. Treat it as a way to expose disagreement between the technical, operations and safety viewpoints, and record the reasons.
Illustrative scoring table
The values below are synthetic and chosen to show the mechanics, not to recommend tasks.
| Task (synthetic) | Frequency | Variability | Access | Contact | Risk | Data exists |
|---|---|---|---|---|---|---|
| Replace air filter on rooftop unit | High | Low | Medium | Low | Low | Records, some photos |
| Reset tripped breaker after check | Medium | Low | High | Low | Medium | Records only |
| Replace belt on conveyor drive | Medium | Medium | Low | High | Medium | Records, no footage |
| Diagnose intermittent sensor fault | Medium | High | Medium | Low | Low | Text only |
| Weld repair of frame crack | Low | High | Low | High | High | None |
On this invented table, the first two tasks would form a reasonable first collection, the third needs force data and a close look at access, and the last is a poor early candidate. A different robot, risk appetite or site would reorder them.
Step 4: decide how to collect
Once tasks are ranked, match each to a route. Existing records and footage suit frequency analysis, language and some perception work. Purpose-built demonstrations, recorded by chosen technicians with chosen viewpoints, sensors, task scripts and labels, suit tasks where you need consistent framing and complete steps; they involve recruiting and briefing demonstrators, a capture plan, calibration, consent, quality checks and annotation. Commissioned recording generally cannot yield robot action spaces unless a robot or handheld capture device is used, and cannot yield contact forces unless the tools or hands are instrumented. See existing assets vs new collection vs specialist providers and instrumented tools.
What this method cannot do
- Predict feasibility. Ranking says nothing about whether a model will learn the task from the collected data. Requirements depend on architecture, task, embodiment and use, and no universal minimum applies.
- Replace site knowledge. Frequency counts do not show the awkward panel, the seized fastener or the customer's rules.
- Cover the long tail. The tasks that make repair hard are rare. Include a deliberate sample; see difficult and failed repairs.
- Settle transfer. A skill learned on one equipment model may not carry to another; see equipment-specific vs transferable skills.
- Remove permission work. Every selected task still needs site access, consent and customer permission.
Reviewing the list with operations and safety
A ranked table is a starting point for discussion with the people who own the work. Take it to maintenance planners, a safety lead and a technician who performs the tasks, and ask each to challenge the scores.
Planners can confirm frequency against the planned-maintenance schedule and check the equipment inventory in the asset hierarchy. Technicians can tell you which tasks hide variation that records do not show, such as corroded fasteners or parts that fit only one way. Safety staff decide which tasks may be recorded at all and under what controls.
Link the final list to time and cost, using labor time standards where available. Record the reasons for each exclusion, since they make a later change of platform or risk limit easier to handle. Then freeze the list for the first collection and leave an explicit slot for exceptions.
Questions to ask suppliers
- Can you provide counts of orders by task type, equipment model and site for the last full year?
- Which planned tasks have checklists or procedures, and are they versioned?
- How many distinct equipment models perform each candidate task at your sites?
- Which tasks cannot be recorded for safety, security or customer reasons?
- Do any candidate tasks already have footage, and from which viewpoints?
- How many technicians typically perform each task, and could some be briefed to demonstrate on a script?
- What labor hours per occurrence do you record, and how are they measured?
- Which tasks require a second person, lockout or special permits, and how would that affect recording?
Discuss your requirements
When you have a ranked list, describe the tasks, modalities and permitted uses to SourceX. SourceX looks for US businesses that hold suitable material, checks the data and the supplier's licensing permissions, and coordinates the license and delivery. If no existing asset fits, SourceX can scope a commissioned collection of new recordings. A request does not guarantee a match, and nothing is contracted until a supplier agrees. See also the catalog entry for field service and maintenance records.
Describe the workplace demonstration data your robotics project needs
Sources
- MaintNet: A Collaborative Open-Source Library for Predictive Maintenance Language Resources — Published maintenance logbook language resource, an example of text records usable for counting task and fault frequency.
- ONET Database (ONET 29.1 per search snapshot): Task Statements and Detailed Work Activities — Task statements and detailed work activities with a mapping file, a public taxonomy for naming tasks.