Understanding Traffic Log Fields: Complete Guide

Introduction

Every signalized intersection is a data-generating machine. Modern traffic signal controllers record each phase change, detector actuation, and system event as a discrete log entry — producing high-resolution log data at 0.1-second resolution, per FHWA specifications. Seminole County's 387 signals alone generate nearly 9 GB of log data daily, and that scale is becoming routine across state DOT networks.

The challenge isn't data volume — it's interpretation. When engineers can't confidently read what a log field means, they make decisions based on summaries that hide the underlying story. A missed detector actuation looks like low demand. A clock-drifted timestamp looks like a phantom event. A firmware mismatch registers as a false system fault.

This guide covers what you need to work confidently with traffic log data:

  • The major categories of log fields and what they record
  • What the most critical individual fields actually represent
  • How agencies use log data for ATSPM analysis and signal optimization
  • Best practices for managing log data at scale across NTCIP-compliant controllers, Econolite platforms, or mixed networks

Key Takeaways

  • Traffic log fields capture discrete, timestamped events — phase changes, detector actuations, preemption calls, fault states — at sub-second resolution
  • Four field categories matter most: timing/phase, detection/sensor, event/status, and geographic/location identifiers
  • ATSPM measures (split failure rate, arrival on green, pedestrian delay) are derived from raw log records; missing events invalidate them entirely
  • Consistent field naming, accurate timestamps, and validated detector-to-phase mapping are prerequisites for corridor-level analysis
  • Log quality reflects the full equipment ecosystem: hardware, firmware, and field service all affect data integrity

Why Traffic Log Fields Matter More Than Summary Reports

Aggregated reports tell you what happened. Raw log fields tell you why — and when, and in what sequence.

An hourly volume count shows 600 vehicles passed through an intersection. The raw log shows that 340 of those arrived during red — a split failure pattern that repeats every weekday between 7:45 and 8:30 AM. One dataset flags a problem. The other just counts.

FHWA identifies high-resolution phase, timing, and detection data as richer and more meaningful than conventional detector summaries, specifically because they enable proactive fault diagnosis and evaluation of timing changes. The critical point: summaries cannot reproduce sequence, causality, or measures that weren't defined when the data was collected. Raw events can.

Primary use cases that require raw log field data:

  • Automated Traffic Signal Performance Measures (ATSPM) — split failure, arrival on green, pedestrian delay
  • Signal timing plan reviews and retiming audits
  • Incident investigation and after-action analysis
  • Pedestrian signal compliance documentation
  • Grant and compliance reporting to state DOTs and FHWA

As controllers and ITS platforms have grown more capable, the number of logged fields has expanded accordingly. Econolite's Cobalt and 2070 Series platforms, for example, integrate with Centracs® SPM for continuous performance data collection. Agency staff doing meaningful analysis need to understand the structure of those fields.


The Four Categories of Traffic Log Fields

Rather than reviewing dozens of fields in isolation, organizing them by function gives engineers a faster path to the relevant data during analysis.

Four categories of traffic log fields organized by function and data type

Timing and Phase Fields

These fields are the backbone of traffic log data. They record when each signal phase began, ended, was extended, or was recalled — with sub-second precision.

Key timing fields:

  • Phase start time and termination type
  • Green duration, yellow clearance duration, red dwell time
  • Cycle length, offset, and split duration

Timestamp format matters here. NTCIP 1201 defines globalTime in UTC plus StandardTimeZone (the local-standard-time offset from UTC).

For cross-intersection comparison or corridor analysis, retaining UTC, local offset, controller event time, and central ingestion time as separate fields prevents alignment errors that are otherwise nearly impossible to diagnose after the fact.

Phase fields connect directly to timing plan audits: cycle length, offset, and split duration fields let engineers verify the controller is executing the intended plan and identify deviations.

Detection and Sensor Fields

Vehicle detectors — loop, video, radar, lidar — generate the primary demand data in any traffic log system.

Core detection fields:

  • Detector ID and actuation timestamp
  • Presence status (on/off)
  • Vehicle count and occupancy percentage
  • Speed (where detector capability allows)

Advanced radar platforms like the RTMS Sx-300, available through TCC's partnership with Image Sensing Systems, extend this field set to include speed measurement and vehicle classification by type. Standard loop detectors cannot natively generate either of those outputs.

That classification data enriches analysis beyond simple presence detection, particularly for turning movement studies and freight-specific performance work.

Detector field quality underlies every derived measure. FHWA states directly that adaptive signal operation is critically linked to reliable detection — false, missed, locked, or missing calls distort estimated demand and can trigger inappropriate timing responses.

Event and Status Fields

Detection data tells you what vehicles did. Event log fields tell you what the system did — capturing discrete occurrences that aren't directly tied to traffic demand:

  • Controller startup and restart events
  • Communication failures
  • Manual overrides
  • Emergency vehicle preemption and railroad preemption events
  • Pedestrian call registrations

These fields are essential for separating performance issues caused by traffic demand from those caused by equipment or software. A split failure during a preemption event is a very different problem than a split failure during normal operation.

Geographic and Location Identifier Fields

Every log record needs to be anchored to physical infrastructure to be usable at scale:

  • Intersection ID and approach direction
  • Lane number and detector address
  • Controller serial number and firmware version

Consistent, well-maintained location identifiers are a prerequisite for any multi-intersection or corridor-level analysis. Without them, aggregating data across controllers from different manufacturers requires time-consuming manual field-by-field matching.


Critical Traffic Log Fields Explained

Timestamp and Time Reference Fields

Nearly every traffic log record begins with a timestamp, and there are two distinct values that agencies must track separately:

  • Controller event time — when the field device recorded the event
  • Central receive time — when the log was ingested by the central system

The gap between these two values is normal and expected. What's problematic is when controller clocks drift due to lack of synchronization, causing event time to become unreliable. GPS Time Sync hardware (available as a cabinet auxiliary component through distributors like TCC) addresses this at the hardware level. NTP synchronization handles it at the network level.

When reviewing logs, engineers should check sequence numbers for gaps and compare timestamps against known event patterns. An intersection that normally logs 800+ phase events per hour showing 200 in a given period is a clock or communication problem, not a demand drop.

Phase and Ring-Barrier Fields

Understanding the NEMA dual-ring structure is necessary to correctly interpret phase sequence logs. FHWA's foundational assignment places phases 1, 2, 5, and 6 in Barrier 1 and 3, 4, 7, and 8 in Barrier 2, with Ring 1 containing phases 1–4 and Ring 2 phases 5–8.

Fields required for accurate phase interpretation:

  • Phase number (1–8)
  • Ring assignment
  • Barrier group
  • Concurrent phase pairing
  • Controller configuration version

Phase numbers don't carry meaning on their own. At a complex multi-phase intersection, the same phase number can represent different movements depending on controller configuration. Always store ring, barrier, movement assignment, and configuration version alongside the phase number.

Volume, Occupancy, and Speed Fields

Once phase context is established, the next layer of log data describes what detectors are actually measuring. Volume, occupancy, and speed fields reveal both traffic conditions and detector health:

Field Definition What Anomalous Values Indicate
Volume Count of vehicles per interval Near-zero during peak hours → detector fault; sustained high values → demand or stuck detector
Occupancy Percentage of interval time detector sensed presence Persistent 100% → stuck-on fault; consistent 0% during known demand → stuck-off or failed detector
Speed Vehicle speed from advanced detectors Available only from radar/lidar capable systems; outlier values indicate calibration issues

Traffic detector field anomaly indicators for volume occupancy and speed values

FHWA's Watchdog implementation flags phases with fewer than 500 records in 24 hours as a "no data" condition. Use it as a starting point, but define your own service-level thresholds in writing so field staff and data analysts apply them consistently.

Preemption and Priority Fields

Detector anomalies are one data quality concern; preemption events introduce another. As connected vehicle and transit fleet technologies expand, preemption and priority log fields are seeing increased scrutiny. Systems like the Applied Information Glance EVP platform, which TCC distributes across much of the Midwest, generate logs that include preemption request timestamps, served phases, and duration data.

A portable preemption log schema should capture:

  • Request source ID and request class (EVP vs. TSP)
  • Request timestamp and service timestamp
  • Entry phase and return phase
  • Sequence state and exit state
  • Calculated duration

NTCIP 1202 defines preempt control/status objects; NTCIP 1211 handles signal-control priority requests. Neither standard prescribes a single universal historical record format, so agencies building archival schemas need to map native NTCIP objects to their own field definitions explicitly.

Controller Status and Diagnostic Fields

NEMA TS 2 and NTCIP distinguish several distinct flash conditions, but poorly designed schemas routinely collapse them into a single "flash" indicator — discarding operationally critical differences:

  • MMU/fault flash
  • Startup flash
  • Local flash
  • Preempt-related flash
  • System-commanded flash

Each carries a different operational meaning and requires different corrective action.

Annual MMU conflict monitor testing and certification — work TCC's field service team performs on-site — directly validates whether controller output states are accurately reflected in status log fields. A properly certified MMU (using EDI/Reno A&E units like the MMU2-1600G or MMU2-1600GE) ensures that signal state data recorded in event logs reflects actual intersection behavior.

Additional status fields to monitor:

  • Current plan number and operational mode (actuated, time-based, manual)
  • Communication link status
  • Firmware and standard version (essential context for interpreting all other fields)

Using Log Data for Signal Optimization and Safety Analysis

ATSPM Measures and Their Raw Field Dependencies

FHWA's ATSPM framework derives intersection performance scores from raw log records. These measures are only as good as their inputs:

Measure Minimum Raw Inputs Required
Split failure Phase green/red transitions + stop-bar detector on/off events
Arrival on green Advance detector actuation timestamp + phase green/yellow/red state
Pedestrian delay Pedestrian call timestamp + walk indication onset timestamp

ATSPM performance measures and minimum raw log field input dependencies chart

Missing any of these event streams doesn't reduce precision — it invalidates the measure entirely. This is why detector field quality is a dependency, not a side concern.

Lake County, Illinois provides a concrete example of the optimization cycle. Engineers used ATSPM plot data to adjust adaptive settings and increase side-street double service, maintaining approximately 90% arrival on green on the major route while eliminating unused side-street green time.

The Econolite Centracs® SPM platform, which TCC supports across its Midwest service territory, enables this kind of continuous monitoring, replacing the traditional cycle of manual retiming every three to five years.

Safety Analysis and Corridor Coordination

Event log fields surface elevated-risk locations before incidents occur. Each of the following patterns warrants field investigation:

  • Recurring conflict flash events
  • Pedestrian calls that don't result in walk indications
  • Unusually high preemption frequency

For corridor-level offset analysis, timing fields across multiple intersections must share a common time reference and consistent phase numbering. Without validated timestamp alignment, offset calculations produce numbers that look precise but reflect clock drift rather than actual progression conditions.


Best Practices for Traffic Log Data Management

Standardize Field Naming Across Platforms

Different controller manufacturers use different field naming conventions. Aligning them to NTCIP standards — or at minimum to a documented agency schema — eliminates transformation errors that corrupt aggregated datasets.

Note: NTCIP's ASN.1 Management Information Base standardizes managed-object semantics across vendors, but it doesn't prescribe specific database column names. Agencies need to document their own column naming schema.

Structure Your Storage Architecture

High-resolution event logs grow fast. A practical architecture separates:

  • Immutable raw layer — append-only event records with all original fields preserved
  • Derived layer — calculated cycles, splits, performance measures, and alarms in reproducible tables

Two-layer traffic log storage architecture with immutable raw and derived data layers

Index primarily on intersection/controller ID plus event time, with secondary access by event code and detector/phase. This handles most operational queries without full table scans.

On retention: UDOT's published practice targets 24–36 months of readily available high-resolution files, followed by cold storage up to five years. No national mandate exists in FHWA, AASHTO, or NTCIP documentation — agencies should set and document their own retention tiers based on operational needs, legal requirements, and storage costs.

Run Routine Log Quality Audits

A log quality audit process should check:

  • Flag time jumps or backward timestamp sequences that indicate controller clock issues
  • Check phase transition sequences for gaps that suggest missed records
  • Verify detector actuation counts against known traffic patterns to catch hardware faults
  • Watch for repeated MMU flash or communication fault entries — these signal systemic problems needing field attention

Suppress or qualify performance measures whenever required event streams fail validation. Silently treating missing records as zero demand produces misleading results that can trigger incorrect timing changes.


Frequently Asked Questions

What are the three types of traffic logs?

Traffic and ITS systems typically organize logs into three categories: event logs (timestamped occurrences like phase changes or detector actuations), performance logs (aggregated interval data like volume and occupancy), and diagnostic/status logs (controller health and fault records). This is a practical operational schema, not a formal NTCIP classification — the underlying standards use managed objects and event enumerations.

What is the difference between a traffic event log and a traffic log report?

A traffic event log contains raw, timestamped records of individual system events at sub-second resolution — the source data. A traffic log report is a processed summary (hourly volumes, split failure rates) derived from those raw records. The raw log is essential for forensic analysis and for recalculating measures with updated methods; the report is useful for routine monitoring but can't reconstruct what the raw log preserves.

What fields are most important for ATSPM analysis?

The most critical fields are high-resolution event timestamps, phase state codes (call, begin green, end green, begin yellow, end red), detector actuation records, and cycle/split data or enough phase transition events to reconstruct them. Detector-to-phase mapping and configuration effective dates are equally required — without them, the same event code means different things at different intersections.

How long should traffic log data be retained?

No national mandate exists. UDOT targets 24–36 months of readily accessible high-resolution files followed by cold storage up to five years — one of the few explicitly published state practices. Agencies should define retention tiers based on operational needs, legal record requirements, and storage costs, and document those policies formally.

What causes errors in traffic log fields?

The most common sources are controller clock drift (timestamp misalignment), faulty detector hardware (false or missing actuation records), firmware version mismatches (altered field formatting or event code definitions), and communication failures that produce incomplete log records at the central system.

Can traffic log data be shared across different controller platforms?

Interoperability depends on adherence to NTCIP standards and consistent field naming conventions. Without standardization, agencies need transformation scripts or middleware to reconcile field definitions across platforms. Multi-vendor networks should establish a shared event-code enumeration standard — similar to Indiana's high-resolution logger format referenced in FHWA's central system specification — before data collection begins.