search

usdot-jpo-ode / wzdx

The Work Zone Data Exchange (WZDx) Specification aims to make harmonized work zone data provided by infrastructure owners and operators (IOOs) available for third party use, making travel on public roads safer and more efficient through ubiquitous access to data on work zone activity.
Creative Commons Zero v1.0 Universal
89 stars 62 forks source link

Device ON/OFF #289

Closed rdsheckler closed 1 year ago

rdsheckler commented 2 years ago

Field devices should have a data field for ON/OFF

The value of ON/OFF is primarily in recording that the device was specifically turned 'off' at a specific time rather than guessing that the device is off because it hasn't reported recently. It is not uncommon for devices to lose the ability to communicate for a number of reasons but the device may still be in the field operating. Consider an work truck beacon that has been turned on, but drives through a region that has no cell signal. If it was recorded as being on but hasn't communicated for several minutes it can be reasonably considered to still be on until it communicates that it has been turned off. The devices that we build will recognize that they have been turned off and will communicate the definitive 'off' state at the first time a successful message has been passed to the server.

We keep the 'OFF' status in the feed for a period of time (one hour) after the 'OFF' message was recorded. This way it didn't just disappear, the event can be recorded as 'COMPLETE'.

j-d-b commented 2 years ago

I understand the value of being able to specify this information. It is easy to implement, such as by adding an is_on property to the FieldDeviceCoreDetails. One major question before the implementation can be completed is:

What does it mean for a device to be "on"?

The definition is necessary to be able to add the property and clearly describe how to use it.

j-d-b commented 2 years ago

For implementation, perhaps augmenting the FieldDeviceStatus to include off would be better than the is_on property I mentioned in the above comment because it avoid having to conflate the value of is_on with the current device_status. Then we don't need to define "on" either, just "off", which is easier:

The device has been turned off and is no longer in use.

rdsheckler commented 2 years ago

I think it is most important to note that the device has been switched to 'off' which explains why it is not reporting and that the work may be completed.

For instance, the way we wire arrow boards is so that the IoT device is always powered off the 12VDC battery. Nominally it reports location if moved, location every 15 minutes, and data status every 15 minutes. Once the display is powered it is now 'ON' and the display status is reported as is the UP/DOWN status. This is repeated every 5 minutes or when something changes. But, it may be in a bad cell area or it may have a power drop or it may just have the IoT broken so it may not report for a period of minutes or hours. That doesn't mean that the display isn't working and visible by drivers, it just means something in the comm system isn't working. This is different than 'OFF' which means the comm system is working fine but the control of the display has been set to no-display.

As you are trouble shooting large numbers of field devices the distinction between 'OFF' and no report becomes important. And the time-stamp of 'OFF' is rather important.

If the battery power drops (ok we don't have this until the next version) to <6VDC we know the battery is stolen.

j-d-b commented 1 year ago

Co-chairs discussion on 2022-09-22 led to the decision that the Device Feed is intended to represent real time conditions and that we need more examples of consumers using the Device Feed to decide if it is needed.

Please re-open if this becomes relevant again.