Short answer
A CMMS asset hierarchy or equipment register lists what equipment exists, how it nests (site, area, system, component), and its make, model, criticality and status. On its own it is structure, not behavior. Its value is context: linked to work orders, codes and photos, it tells a model which machine a symptom belongs to. Facilities, plants and fleets hold it; customer data and site layouts need redaction.
What the hierarchy adds to other maintenance data
A work order that says "replace sensor" is hard to interpret without knowing which sensor, on which machine, in which system, and what that machine is. The asset register supplies that. It places each piece of equipment in a tree, usually site, area, line or system, equipment, and component, and attaches the attributes that tell equipment apart: manufacturer, model, serial, install date, criticality, status and warranty.
Buyers rarely want the register alone. They want the structure that makes work-order histories, error codes and HMI screens and photos interpretable, and that lets them split data by equipment type for evaluation. This page covers how to source it. It is part of the maintenance cluster in the humanoid data guide.
What a CMMS export contains
| Table or field group | Examples | Use |
|---|---|---|
| Asset hierarchy | Parent-child links, level names, location codes | Grouping; context for tasks |
| Equipment register | Make, model, serial, year, class, status, criticality | Splits by equipment type |
| Bill of materials links | Parts per asset, part numbers | Parts context; see spare parts identification |
| Maintenance plans | Scheduled tasks and intervals per asset | Task frequency; see preventive maintenance checklists |
| Work-order links | Asset ID on each order | Joins to symptoms and fixes |
| Meters and counters | Run hours, cycle counts | Usage context |
| Failure and cause codes | Coded problem, cause, remedy | Labels; quality varies |
Field names and structure differ among maintenance systems, so expect a mapping step. Free-text fields in the export, such as descriptions and notes, share the compressed style described in MaintNet, which provides logbook data from aviation, automotive and facilities domains and supplies abbreviation lists and pre-processing tools (Akhbardeh et al., 2020).
What this data can support
- Context for text and records. Linking orders, codes and notes to asset class and system reduces ambiguity for language models.
- Task frequency and mix. With maintenance plans and orders, a buyer can count which tasks occur on which equipment, relevant to choosing tasks to collect.
- Evaluation splits. Equipment make, model or site can define held-out groups, so a test measures transfer across equipment. See equipment-specific vs transferable skills.
- Environment descriptions. Location levels hint at where a robot would work, such as basement plant rooms or rooftop units.
What this data cannot support
- Any physical skill. An asset tree contains no hand motion, tool use, force or video.
- Geometry. A hierarchy says a pump is in room 114, not whether a robot can reach its bolts. Layout and clearance need drawings or scans.
- Cause and fix on its own. Without order history, a register explains nothing about failures.
- Accuracy. Registers drift. Equipment is replaced, relocated or renamed without updating the system, and hierarchies are often incomplete or duplicated. Treat the export as a claim to verify, not ground truth.
- Cross-site comparability. One organization's "system" may be another's "component". Level names rarely match.
Illustrative asset export
# Illustrative only - synthetic values, not an available dataset
export_id: cmms_exp_09
system_type: generic_cmms
assets:
- asset_id: asset_0001
parent_id: null
level: site
name: site_017
- asset_id: asset_0044
parent_id: asset_0001
level: system
name: chilled_water_loop_1
- asset_id: asset_0207
parent_id: asset_0044
level: equipment
class: centrifugal_pump
make: make_M4
model: model_P220
install_year: 2014
criticality: high
status: active
plan_ids: [pm_0311, pm_0312]
links: {work_orders: wo_export_09, bom: bom_export_09}
redactions: [customer_name, street_address, serial_number]
The shape of an export decides which joins are easy. Ask for stable identifiers in each table, since joins by description text are unreliable.
Preparation before use
- Map the hierarchy. Decide a standard set of levels and map each source into it. Keep the original names.
- Deduplicate equipment. Merge duplicate records; flag retired assets.
- Normalize classes. Map free-text equipment descriptions to a controlled class list.
- Redact. Customer names, site addresses, serial numbers and contract fields often sit in the export. Plan redaction before delivery. Redaction handles disclosure of specific details; it does not by itself establish that the owner may license the data.
- Keep a data card. Record how the export was produced and its known gaps. Dataset documentation formats are useful templates; see Datasheets for Datasets and Data Cards.
Permissions and provenance
Registers contain the customer's equipment, and in some cases a facility's security-relevant layout. A facilities team may hold the data on behalf of an owner, a landlord or a tenant, and the maintenance software vendor's terms may also apply. Ask who owns the records, whether the export includes third-party contractors' data, and whether customer contracts restrict reuse. See licensing terms for robotics training data.
Joins that make an export useful
Most of the value comes from joining the register to other tables, so test the joins before agreeing on a purchase. Ask for a small linked sample and check four things.
- Key stability. Does the same asset ID appear in the register, work orders, plans and any photo metadata, and does it stay the same after a re-numbering or migration?
- Hierarchy depth at the work-order level. Orders are sometimes raised against a site or a system rather than the component, which weakens the link to a failure.
- Time validity. Equipment moves and is replaced. Check whether the register records effective dates, or only the current state.
- Free-text consistency. Compare a model name in the register with the same equipment in notes. Differences in spelling or abbreviation indicate normalization work; the maintenance logbook text page covers this problem.
A register with weak keys can still help as a lookup of equipment classes, but it will not support the per-asset analyses that justify buying it.
Questions to ask suppliers
- Which maintenance system produced the export, and which tables and fields are included?
- How many levels does the hierarchy have, and are level names consistent across sites?
- How complete are make, model and serial fields, and when was the register last audited?
- Do assets carry stable IDs that match the IDs used in work orders and photos?
- Are retired, relocated or replaced assets marked rather than deleted?
- Does the export include maintenance plans and intervals, or only the equipment list?
- What was redacted or removed, and can identifiers still be joined across tables?
- Does the supplier own the data, or hold it for customers whose consent is needed?
- Do any records describe security-sensitive facilities or restricted areas?
Discuss your requirements
If you need asset structure to give context to maintenance data, describe the equipment classes, site types and fields 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. A request does not guarantee a match, and nothing is contracted until a supplier agrees. The catalog entry for maintenance logs describes a related record type.
Explore sourcing and licensing options with SourceX
Sources
- MaintNet: A Collaborative Open-Source Library for Predictive Maintenance Language Resources — Published maintenance logbook language resource across aviation, automotive and facilities domains, showing why equipment context is needed to read technician text.
- Datasheets for Datasets — Proposes datasheets documenting dataset composition and collection process.
- Data Cards: Purposeful and Transparent Dataset Documentation for Responsible AI — Structured summaries of dataset facts for stakeholders across the lifecycle.