TIDES-transit
📄🚀 – Add device_status table for tracking device maintenance and availability
Issue Summary
This proposal suggests creating a new device_status table to track device maintenance activities, offline periods, and operational status changes. This emerged as one of the related recommendations considered during the September 2025 TIDES Contributors Group's discussion of the WMATA-proposed spec modification to modify the passenger_events table to accommodate station-based events. It was identified during that discovery and proposal creation process that agencies would benefit from a standardized way to track when and why devices are unavailable for data collection.
Identified Need
During the [September Contributors Group meeting discussion of fare gate events], it was noted that WMATA has extensive maintenance data for their fare gates that doesn't fit into any current TIDES tables. While agencies often maintain this information in separate asset management systems, there's value in having device status information available within the TIDES data ecosystem for several reasons:
- Data quality analysis: Understanding why data is missing from specific devices during certain periods
- Operational reporting: Tracking device availability and reliability metrics
- Maintenance coordination: Identifying patterns in device failures or maintenance needs
- Service analysis: Distinguishing between "no passengers" and "device offline" scenarios
Addressable Audience
This change would benefit:
- agencies with large device fleets (fare gates, validators, APC units)
- sata analysts needing to validate data completeness
- operations teams tracking equipment reliability
- agencies required to report on equipment availability metrics
- vendors providing maintenance and monitoring services
Proposed Solution
Create a new device_status table to track device operational status, distinct from business events generated by the device.
Proposed Schema
| Field | Data Type | Constraint | Description |
|---|---|---|---|
device_status_id |
string | required | Unique identifier for the status event |
service_date |
date | required | Service date |
event_timestamp |
datetime | required | Timestamp when the status changed |
device_id |
string | required | Identifier for the device |
status_type |
string | required | Type of status (maintenance, offline, error, etc.) |
status_reason |
string | optional | Reason for the status change |
expected_resolution_time |
datetime | optional | Expected time when device will return to normal operation |
actual_resolution_time |
datetime | optional | Actual time when device returned to normal operation |
Implementation Flexibility
This table design represents an ideal state. Agencies would implement fields based on their available data sources. At minimum, tracking device_id, event_timestamp, and status_type would provide value for understanding data gaps. Additional fields like resolution times could be added as agencies develop more sophisticated maintenance tracking systems.
Positioning: Extension vs Core Specification
This proposal could be pursued as either:
Option A: TIDES Extension
- Developed as an optional extension for agencies with device maintenance tracking needs
- Would not affect core TIDES compliance
- Allows for more specialized fields and maintenance-specific requirements
Option B: Core Spec Addition
- Integrated into the main TIDES specification as an optional table
- Provides standardization for a common agency need
- Ensures compatibility with core TIDES tooling and validation
The Contributors Group should determine the most appropriate path based on community needs, the scope of core TIDES, and the vision for TIDES delineated in TCRP Research Report 235.
Rationale
As noted in the September meeting, this separates maintenance and operational status information from business events, making both types of data easier to analyze and manage. It provides a standardized way to track device availability across different device types (fare gates, validators, APC units, etc.) and helps explain gaps in data collection that are due to equipment issues rather than actual service patterns.
Related Context
This proposal emerged alongside the fare gate events proposal (Issue #241 ) but addresses a distinct need that applies to all device types, not just fare gates. It was specifically noted that while agencies often have asset management systems for maintenance data, having device status information within the TIDES ecosystem would be valuable for data quality and completeness analysis.
This proposal could be implemented as either a TIDES extension or core specification modification, pending community input on the most appropriate approach.
After reviewing existing standards beyond TIDES, it seems that current U.S. transit standards (FTA TAM, APTA maintenance standards) focus on asset condition assessment and maintenance tracking but don't provide a standardized format for real-time device availability status.
ISO 55000 provides an asset management framework but doesn't prescribe specific device status schemas.
This gap reinforces the value of including a device_status table in TIDES to provide the transit industry with a standardized approach to tracking device availability. This, of course, is something that CMMS vendors handle in proprietary ways, but it currently lacks industry standardization.
Suggest differentiating the date/time that he record is created from the date/time that the status changed with separate fields. The status might have changed in the past, but the record is only now being created.
I support the proposed changes, but I would make service_date optional.
