Choosing the Right Data Type for Equipment Projects Variable or Attribute
A maintenance project can fail before the first chart is drawn if the team collects the wrong kind of data. The question may be sound, the equipment may be critical, and the people may be skilled, but the data type decides what can be measured, compared, graphed, and controlled later.
Equipment projects often start with a practical question:
Why does this pump keep tripping?
Are bearing temperatures getting worse?
How often are belts breaking?
Which failure mode causes the most downtime?
Did the restart procedure work?
Each question points to a different type of data. Some answers need a measured value, such as temperature or vibration. Others need a count, a category, or a simple yes or no.
The useful rule is simple: select the data based on the question the project must answer. Do not start with the chart. Start with the decision the project needs to support.
The question decides the data type
The best data type is the one that gives a clear answer to the project question. If the question asks “how much,” the project likely needs variable data. If it asks “how many,” “which kind,” or “did it happen,” attribute data may be the better fit.
For example, suppose a conveyor drive has repeated bearing failures. Several useful questions could be asked:
How hot does the bearing run during normal operation?
How much vibration appears at operating speed?
How many bearing failures occurred this quarter?
Which failure mode was recorded during teardown?
Did the bearing pass inspection after replacement?
These are all valid questions, but they do not use the same data. Bearing temperature and vibration are measured quantities. Failure count is a count. Failure mode is a classification. Pass or fail is binary.
Mixing these together without care leads to weak analysis. A trend line of failure mode categories makes little sense. A pie chart of vibration readings usually hides useful detail. A pass or fail result will not show whether a machine is slowly drifting toward trouble unless the inspection rule is designed to catch that drift.
Good data selection protects the project from that confusion.
Variable data measures how much
Variable data is a measured quantity on a continuum. In principle, it can take any value within a range, depending on the instrument and the process being measured.
Common equipment examples include:
Bearing temperature
Vibration amplitude
Lubrication pressure
Motor current
Shaft runout
Repair duration
Time between failures
Flow rate
Torque
Speed
Variable data is useful when the size, level, or amount matters. If a bearing is getting warmer month by month, the exact temperature readings matter. If pump vibration is increasing, the amplitude and frequency details matter. If repair time varies widely between shifts or asset types, the actual repair duration helps show the pattern.
Variable data usually gives more detail than attribute data. A result of “pass” may say that a motor is acceptable today. A winding temperature of 178 degrees Fahrenheit gives more context, especially when compared with past readings, load conditions, and inspection limits.
That detail supports better graphs and better decisions. With variable data, teams can often use:
Run charts
Histograms
Scatter plots
Box plots
Individual and moving range charts
X-bar and R charts when subgrouping makes sense
Variable data also helps detect small changes early. A bearing may still be below an alarm limit, but a steady upward temperature trend can signal lubrication loss, misalignment, or a change in load.
The tradeoff is effort. Variable data needs a defined measurement method. The team must decide where to measure, when to measure, what instrument to use, and how to handle conditions such as start-up, shutdown, and load changes.
If two technicians measure vibration at different points on the same housing, their readings may not match. If temperature is measured sometimes after start-up and sometimes after four hours of operation, the trend may reflect timing rather than equipment health.
For variable data to work well, define the method before collecting it.
Attribute data counts or sorts what happened
Attribute data is discrete. It records counts, classifications, or two-outcome results. It does not measure how much on a continuous scale.
That does not make it weaker. In many equipment projects, attribute data is the most practical and direct way to understand the problem.
Attribute data works well when the project question asks:
How many events occurred?
What type of defect was found?
Which failure mode was assigned?
Did the item pass inspection?
Was the restart successful?
Attribute data is often easier to collect during inspections, repairs, start-ups, and shift rounds. It can also be less expensive than continuous measurement when instruments are limited or when the project is still in an early screening phase.
There are three common forms of attribute data in equipment work.
Attribute count data records how many
Count data records the number of occurrences, defects, events, or findings.
Examples include:
Number of belt breaks per month
Number of leaks found during an inspection
Number of nuisance trips on a compressor
Number of missing guards found during an audit
Number of failed seals on similar pumps
Number of late preventive maintenance tasks
Count data is useful for ranking problems and tracking frequency over time. If one production line has far more belt breaks than others, that count points attention in the right direction. If leak counts drop after a gasket change, the project can show improvement.
Count data often pairs well with bar charts, Pareto charts, run charts, and count-based control charts. Common control-chart choices include c charts and u charts, depending on whether the area of opportunity stays constant.
A key question for count data is whether the inspection opportunity is the same each time. Counting leaks found in one machine room is different from counting leaks across an entire plant. Counting defects on 10 inspected motors is different from counting defects on 200 inspected motors.
If the opportunity changes, record the denominator. For example, “leaks per 100 inspection points” gives better context than “leaks found.”
Attribute classification data records which kind
Classification data assigns an item or event to a category.
Examples include:
Failure mode coded as misalignment
Failure mode coded as lubrication issue
Failure mode coded as electrical fault
Failure mode coded as unknown
Defect type coded as crack, corrosion, wear, or contamination
Work order cause coded as operator report, inspection finding, or alarm
Classification data helps show patterns in cause and type. It answers “what kind of problem is this?” rather than “how much did it measure?”
This data supports Pareto charts, stacked bar charts, and summary tables. It can quickly show whether most failures come from one dominant cause or whether several problems need separate responses.
The risk is unclear category definitions. If one technician codes “lubrication issue” and another codes the same event as “bearing failure,” the data becomes hard to trust.
Good classification data needs:
A short set of clear categories
A rule for selecting the primary category
An `unknown` or `not determined` option
Periodic review of how people apply the codes
Do not create too many categories at the start. A long list may look precise, but it often creates noise. Start with categories that the team can identify consistently.
Attribute binary data records one of two outcomes
Binary data has only two outcomes.
Examples include:
Restart successful, yes or no
Inspection result, pass or fail
Leak present, yes or no
Alarm cleared, yes or no
Safety interlock functional, yes or no
Correct lubricant used, yes or no
Binary data is simple and powerful when the decision is also simple. If a restart either succeeds or fails, binary data matches the reality of the task.
It is also useful for compliance checks and standard work audits. A guard is installed or it is not. A filter was replaced or it was not. The inspection passed or failed.
Binary data can be summarized with percentages and proportions. For control charts, p charts and np charts are common choices, depending on whether the sample size changes.
The weakness of binary data is that it can hide severity. A pass or fail inspection tells whether a limit was crossed, but it may not show how close the result was to failing. If that detail matters, collect the measured value as variable data along with the pass or fail result.
How common equipment questions map to data types
The table below shows how the project question should guide the data selection.
Project question | Best data type | Example data | Useful display |
How hot is the bearing during operation? | Variable | Bearing temperature in degrees Fahrenheit | Run chart or control chart |
Is vibration rising over time? | Variable | Vibration amplitude | Trend chart or scatter plot |
How many belt breaks happened this month? | Attribute count | Belt breaks per month | Bar chart or run chart |
Which failure mode is most common? | Attribute classification | Misalignment, lubrication issue, electrical fault, unknown | Pareto chart |
Did the restart work after the repair? | Attribute binary | Yes or no | Proportion chart |
How long do repairs take? | Variable | Repair duration in hours | Histogram or box plot |
How many leaks were found per inspection route? | Attribute count | Leak count per route | Run chart or u chart |
Did the inspection pass? | Attribute binary | Pass or fail | Pass rate trend |
This is the heart of Choosing the Right Data Type for Equipment Projects Variable or Attribute. The form of the data should match the form of the question.
Variable and attribute data can work together
Many equipment projects benefit from both data types. The key is to avoid forcing one type to do the work of the other.
A pump reliability project might collect:
Vibration amplitude as variable data
Seal leaks per month as count data
Failure mode as classification data
Post-repair restart success as binary data
Each field says something different. Vibration amplitude shows condition. Leak count shows frequency. Failure mode shows pattern. Restart success shows immediate repair outcome.
Together, they give a fuller picture.
A useful project form might include both a measurement and a category. For example:
Field | Data type | Why it helps |
Bearing temperature | Variable | Shows whether heat is increasing |
Vibration amplitude | Variable | Shows mechanical condition |
Leak count | Attribute count | Tracks visible seal or gasket problems |
Failure mode | Attribute classification | Groups events by likely cause |
Restart successful | Attribute binary | Confirms immediate repair result |
This mix supports better decisions than any single field alone. If vibration rises before each seal leak, the project may point toward alignment or looseness. If most failures are coded as lubrication issues, the next step may be to review grease type, interval, storage, and application method.
Pick the graph after the data type is clear
Graphs should not drive data collection. They should help make the chosen data understandable.
For variable data, use graphs that preserve the measured values. A run chart of bearing temperature over time can show drift. A histogram of repair duration can show spread. A scatter plot can compare vibration against load.
For count data, use graphs that show frequency. A Pareto chart can reveal the most common defects. A run chart can show whether monthly belt breaks are changing.
For classification data, use charts that compare categories. A bar chart of failure modes is often clearer than a pie chart, especially when category names are long.
For binary data, use proportions. A pass rate over time can show whether a new inspection method is holding. A restart success rate can show whether a repair procedure is improving.
Control charts also depend on data type. Variable measurements often lead to individual charts or subgroup charts. Counts and proportions lead to different chart families. Choosing the data type early makes later chart selection much easier.
Define the data before the first reading
A good data plan does not need to be long. It does need to be clear. Before collecting data, define these items:
The project question
Write the question in plain language. For example, “Is bearing temperature increasing after the lubrication change?”
The data type
State whether the data is variable, count, classification, or binary.
The operational definition
Define exactly what will be recorded. For vibration, name the measurement location and unit. For leaks, define what qualifies as a leak. For failure mode, define the category rules.
The collection point
Record where and when the data will be taken. Equipment readings can change with load, speed, ambient conditions, and operating stage.
The sample or opportunity
For count and binary data, record the number inspected or the opportunity for defects. This prevents misleading comparisons.
The recording method
Use consistent labels. For binary data, choose `yes` and `no`, or `pass` and `fail`. Do not let people mix `Y`, `yes`, `OK`, and `good` in the same field.
The review rhythm
Decide how often the data will be reviewed. Daily, weekly, or monthly may all be valid, depending on the equipment and the failure pattern.
Clear definitions reduce rework. They also make the data easier to explain to people who were not involved in the collection.
Common mistakes when choosing equipment data
Most data problems are avoidable. They usually come from rushing into collection before the project question is clear.
One common mistake is turning variable data into attribute data too early. For example, recording only pass or fail for bearing temperature may hide a warming trend. If the actual temperature is available, record it.
Another mistake is collecting variable data without a stable method. A vibration reading has limited value if the measurement point changes each time. The same issue appears with temperature readings taken under different load conditions.
A third mistake is using vague categories. “Mechanical problem” may be true, but it may not help. Better categories separate useful causes, such as misalignment, looseness, lubrication issue, contamination, wear, electrical fault, and unknown.
Teams also run into trouble when they compare counts without context. Ten leaks may be serious on a small route and normal on a much larger route. Counts need an opportunity base when the inspected area changes.
The final mistake is collecting data that no one plans to use. Every field should support a decision, a chart, a comparison, or a follow-up question. If it does none of those things, remove it.
A simple selection guide
Use this quick guide when planning an equipment project.
If the question asks | Use this data type | Example |
How much or how long? | Variable | Repair duration |
How many? | Attribute count | Number of belt breaks |
Which kind? | Attribute classification | Failure mode |
Did it happen? | Attribute binary | Restart successful |
Did it pass a defined rule? | Attribute binary, with variable data if severity matters | Inspection pass or fail plus measured clearance |
Is the condition drifting? | Variable | Bearing temperature trend |
Which problem should be tackled first? | Attribute count or classification | Defects by type |
When in doubt, write the sentence the project must answer. The grammar often reveals the data type. “How hot” calls for a measurement. “How many” calls for a count. “Which cause” calls for a category. “Did it work” calls for a binary outcome.
The practical takeaway
Equipment data is useful only when it fits the decision. Variable data measures how much. Attribute count data records how many. Attribute classification data records which kind. Attribute binary data records one of two outcomes.
None of these types is automatically better than the others. A bearing temperature trend can warn of a developing problem. A failure mode category can show where to focus maintenance work. A count of belt breaks can prove whether a change reduced events. A yes or no restart result can confirm whether a repair process works in the field.
Start with the project question. Define the data type. Set the collection rules. Then choose the graph and control chart that match the data.
That order keeps the project grounded in the equipment, not in the spreadsheet.
Comments