Monitor state, quality and context
A remote monitoring point is operationally useful only when its meaning, unit, update rule, timestamp and alarm response are defined. Collecting a large register list without context can produce a busy dashboard that still cannot distinguish a real field fault from stale communications.
Organize the data dictionary
| Group | Typical points | Operator question |
|---|---|---|
| Operating state | Current mode, plan, stage/phase and transition state | What is the controller commanding now? |
| Time and schedule | Controller clock, synchronization status, active calendar | Is the correct plan running at the correct time? |
| Inputs and outputs | Detector states, calls, output feedback and configured channels | Is field demand and response plausible? |
| Faults | Conflict, output/lamp, power, cabinet and restart events | What needs immediate action? |
| Communications | Last contact, latency, retries, signal level and data age | Can the status be trusted? |
| Maintenance | Firmware, configuration checksum, serial number and service notes | Which asset and release are affected? |
Make stale data visible
Store both the controller event time and the platform receipt time. Define a freshness threshold for each point type and show an explicit stale or unknown state after communications loss. Repeating the last known value without a quality flag can mislead an operator into believing the intersection is currently normal.
Design alarms for action
Each alarm needs priority, onset condition, clear condition, suppression rule, operator text and recommended response. Deduplicate repeated events and link the alarm to the controller identity, location, active plan, firmware version and recent communications quality.
Keep commands separate from monitoring
Read-only visibility and control authority should be separate roles. Record every remote command with user or system identity, requested value, controller acknowledgement, effective result and time. Monitoring should show whether the commanded state was actually reached.
Frequently asked questions
What is the most important remote monitoring field?
Data freshness is one of the most important fields because every displayed state depends on it. Show when the controller generated the value, when the platform received it and whether the value is current, stale or unknown before an operator relies on the dashboard.
Should every controller event create an operator alarm?
No. Separate diagnostic events from actionable alarms. An alarm should have a defined priority, clear condition and response. Repeated low-value notifications create alarm fatigue and can hide the smaller number of events that require immediate field or traffic-management action.
How should remote commands be audited?
Record the requester, role, controller identity, command, parameters, request time, acknowledgement, effective result and failure reason. Keep this history with the controller and central-system versions so later reviews can distinguish operator action from autonomous control or communications recovery.