How Arc Flash Data Collection Works in the Field

Data collection is the part of an arc flash study that slows everything down. Not the engineering analysis, not the software. The field work. Somebody has to walk the facility, photograph or record nameplate data from every significant piece of electrical equipment, and get that data into the analysis software accurately. On a large industrial site, that alone can take several days.

This page explains what data has to be collected, why it matters, how the traditional process works, where errors creep in, and how modern tools change the equation.

Why data collection is the bottleneck

An arc flash analysis is only as accurate as the data behind it. The power system analysis software, whether SKM PowerTools, ETAP, or EasyPower, builds a model of the electrical system. Every component in that model requires real nameplate values. Estimated or assumed data produces results that may not reflect actual hazard levels.

The math is sensitive. A transformer impedance value that is off by half a percent changes the available fault current at every downstream bus. A breaker setting recorded incorrectly changes the clearing time. Clearing time directly affects incident energy. Wrong input data means wrong labels on the equipment, and wrong labels mean workers are either under-protected or over-protected.

NFPA 70E 2027 requires an arc flash risk assessment before energized work at 50 volts or above. That assessment has to reflect actual system conditions. A study built on guessed or transcribed-wrong data does not satisfy that requirement in any meaningful sense.

What has to be collected

The data collection scope for an arc flash study covers every significant element in the power distribution system, from the utility service entrance down to the branch circuit level. The further downstream you go, the less impact individual elements have on upstream equipment, but every element needs data for its own label.

Utility source data

The utility provides available fault current at the point of delivery, usually expressed as short circuit MVA or available symmetrical fault current in amps. This is the starting point for all fault calculations. Without it, everything downstream is an assumption. Engineers typically get this from the serving utility in writing.

Transformer data

Transformers are among the most important elements in the model. The key data points: kVA rating, primary and secondary voltage, impedance percentage (from the nameplate, not standard tables), X/R ratio, winding connection type (delta, wye, with or without grounding), and manufacturer. The nameplate impedance is critical. Transformers often differ from the standard impedance for their kVA class, and that difference affects fault current calculations at every bus the transformer feeds.

Circuit breaker data

For every circuit breaker in the system, you need manufacturer, model number, frame size, trip rating, and actual settings. Breakers with electronic trip units have adjustable settings for long-time, short-time, and instantaneous functions. Those settings have to be recorded as-found, not as the settings chart says they should be. The actual clearing time matters for the arc flash calculation, not the nominal setting.

Fuse data

Fuses require type (current-limiting, time-delay, fast-acting), ampere rating, voltage rating, interrupting rating, and manufacturer. Different fuse types with the same ampere rating have very different time-current characteristics. Using a generic fuse curve instead of the actual fuse type can significantly affect the calculated incident energy.

Cable and conductor data

Cable impedance affects available fault current at downstream buses. The key data: conductor size in AWG or kcmil, conductor material (copper or aluminum), insulation type, number of conductors per phase, and length. Length is the most frequently missed or estimated field. Long cable runs add meaningful impedance. Getting cable length wrong by 30% can shift the fault current enough to affect the arc flash result.

Switchgear and MCC data

For switchgear and motor control centers, record the bus rating in amps, nominal voltage, manufacturer, section identification (typically a section letter or number on the equipment), and the protective device for each circuit. The individual circuit breaker or fuse data follows the same requirements above. Bus ID naming needs to match what you will use in the one-line diagram and in the analysis software.

Panelboard data

Panel data includes main breaker rating, bus rating, nominal voltage, phase configuration (single-phase or three-phase), and panel name or designator. The panel name needs to tie to the one-line. If the facility has informal panel naming that differs from what the drawings show, document both.

Motor data

Motors that are large enough contribute to available fault current during a fault event. For motors that will be modeled as fault contributors, collect horsepower or kW rating, nameplate voltage, and full load amperes. Code letter from the nameplate is also useful. In practice, motors below about 50 HP are often lumped together at the MCC bus level rather than modeled individually.

Equipment types and key data points

The table below summarizes the primary data points for each equipment category. Download the free arc flash field data collection checklist for a complete field-ready format with checkboxes for each data point by equipment type.

The traditional data collection method

The traditional process is manual and sequential. A technician or engineer walks the facility with a clipboard, camera, and paper forms. At each piece of equipment, they photograph the nameplate and write down the data values. At an MCC with 40 buckets, that means 40 sets of breaker or starter data recorded by hand.

Back in the office, the engineer opens SKM, ETAP, or EasyPower and starts building the model. The nameplate data from the field forms gets re-keyed into the software element by element. If the handwriting is unclear or the photograph of the nameplate is too dark to read, someone has to go back to the field or make a judgment call.

This approach has been the industry standard for decades. It works. It is also slow, and it introduces multiple opportunities for error.

Where errors enter the process

Three failure points account for most data quality issues in arc flash studies.

Illegible nameplates

Electrical equipment lives in harsh environments. Paint, corrosion, paint overspray, decades of grime, and heat damage all degrade nameplates. A transformer impedance that was stamped clearly in 1989 may be nearly impossible to read today. Technicians either estimate, skip the field, or rely on the original purchase order, which may not match what was actually shipped.

Transcription errors

Every time data moves from one medium to another, the error rate rises. From nameplate to clipboard to software entry is three transfers. A transformer impedance of 5.75% transcribed as 5.57% changes the fault current calculation. The error may not be detectable by reviewing the model unless you have the nameplate photograph to compare against.

Missing or undocumented changes

Electrical systems change over time. A breaker gets replaced with a different model. A transformer is swapped for a higher kVA unit during a capacity upgrade. A new feeder is added that does not appear on the drawings. Unless those changes were documented and the one-line updated, the field technician is collecting data from actual equipment that differs from the engineering records. The study model may miss those changes entirely.

Where to find data when nameplates are missing

Missing nameplate data is a common field problem. The options, roughly in order of reliability:

• Original equipment submittals from the construction project. Often kept in the facility's engineering files or with the owner's project records.
• Manufacturer test reports. Transformers in particular often have certified test reports that include the actual measured impedance, which may differ slightly from the nameplate value.
• As-built electrical drawings. Not always current, but a starting point. Cross-reference against what is physically installed.
• Manufacturer technical support. Many manufacturers can look up specifications by serial number. Useful for circuit breakers where the model number is legible but other data is worn.
• Purchase orders or material records. Procurement records sometimes have equipment specs that were not captured in as-built drawings.

When none of these options produce the data, engineers typically use conservative assumptions and flag the affected equipment in the study report. The arc flash analysis can assign conservative incident energy values to equipment with uncertain input data, but this approach should be documented and the data should be verified in a future update.

Field tips for cleaner data collection

Experienced field technicians develop habits that reduce data quality problems. These are the ones that matter most.

Photograph the nameplate and its context

A close-up of a nameplate is useful. A photo that also shows where the equipment is located, what panel or MCC section it belongs to, and what is connected to it is far more useful. When something is unclear in review, the context photograph often resolves it without a return trip to the field.

Record bus IDs before you start

Walk the facility first and establish a naming convention for every bus, panel, and MCC section before collecting equipment data. If the facility has informal names that differ from drawing labels, document both. Consistent naming prevents equipment from being orphaned in the model because a bus ID does not match between the field data and the one-line.

Record feeder numbers and circuit identifiers

Every circuit should be traceable to its source. The feeder number, circuit breaker pole number, or section letter ties the field data to a specific location in the one-line diagram. Without it, data may be collected correctly but assigned to the wrong element in the model.

Note as-found breaker settings immediately

Electronic trip breakers often have settings that differ from what the coordination study or schedule specifies. Record what is actually set on the breaker, not what should be set. Discrepancies should be flagged in the field notes, but the as-found value is what the arc flash analysis needs.

Document anything that differs from the drawings

Whenever field conditions do not match the one-line or equipment schedule, write it down. Equipment that was replaced, circuits that were added, breakers that were changed. These discrepancies need to be resolved before the study can be finalized. The engineer would rather know about them during data review than discover them after the model is built.

How 70Ez changes the data collection process

70Ez replaces the clipboard and the manual transcription step. Field technicians use the app to photograph equipment nameplates directly. The AI reads the nameplate image and populates the data fields for that equipment type: transformer kVA, impedance, voltage ratings, serial number, manufacturer. The technician reviews the extracted values against the nameplate image and confirms or corrects them on the spot.

The data is organized by project, by equipment type, and by location. When the field work is done, the engineer exports the structured data in formats designed to work with SKM PowerTools, ETAP, or EasyPower. The manual re-keying step between field collection and software entry is removed.

This matters most on large facilities. A plant with 20 MCCs, each with 30 to 40 buckets, means hundreds of breaker and starter records. Under the traditional method, all of that data passes through at least two transcription steps. With 70Ez, the technician reviews AI-extracted data in the field and the engineer receives structured, exportable records. One transfer instead of three.

The arc flash risk assessment still requires an engineer. The coordination study and arc flash study still require analysis software. What 70Ez addresses is the data collection step upstream of all of that, where most of the field time is spent and where most of the errors originate.