Skip to content

Web conference notes, 2025.04.10 (MDS Working Group)

Jump to bottom
Michael Schnuerle edited this page Apr 28, 2025 · 19 revisions

MDS Working Group

Agenda

Vehicle States and Requirements Updates w/ SFMTA

  1. Intro and announcements (15 min)
    1. New MDS WGSC members
    2. Feedback on Policy real-time updates in PR #928
  2. MDS 2.1 Updates Discussion (40 mins)
    1. Return only relevant geographies in Provider Reports #873, PR #930
    2. Add operations start and end dates to VEHICLES endpoint #899, PR #913

WGSC Meeting Organizers

  • Host: Pierre Bouffort, Blue Systems
  • Facilitator: Michael Schnuerle, OMF
  • Preparation: Michael Schnuerle, OMF
  • Outreach: Michael Schnuerle, OMF
  • Note taker: Michael Schnuerle, OMF

Action Items and Decisions

  1. Feedback is needed on Policy real-time updates in PR #928, closing in one week
  2. Feedback on tracking vehicle property changes PR #913

Key Points for PR 913

  • MDS Vehicles is a real time status of vehicles, not a history
  • Vehicle property change: when part of a vehicle is changed: accessibility, battery, tires, IoT device, license plate, color, etc (custom for each Mode). Useful for knowing use and rides with certain equipment. This is really what SFMTA wants to see (going to rename Issue/PR). Is this history a new data structure in MDS? Or a new event type in Events with descriptive text?
    • Vehicle lifecycle: when a vehicle was added to service, then finally retired. Useful for carbon footprint discussions, lifetime operations, green goals, etc. Events already has decommissioned state for when it's removed from service.
    • Vehicle maintenance: When vehicles have maintenance done on or off street - already covered in MDS with vehicle states in Events. Last inspection date is in Vehicles now. Some public agencies get this in monthly reports, but MDS should be able to handle this instead.
  • Need to hear more from operators, vendors, data aggregators. Comment on GitHub now with challenges or issues.

There are 2 ideas in the description of this issue, vehicle 1) lifecycle and 1) property changes.

Vehicle lifecycle seemed to be less important during discussions, and is tracking of retirement is already in the MDS decommissioned event. Maybe there is only a need for a new event type to track when a vehicle ID is created, like start_of_service? That may be a breaking change. Or currently you could use when the device_id was first seen in the Events feed as a way to know this. Assuming operators are using device_id properly. There was practical and philosophical talk of how to know when to create a new device id. Maybe MDS could be update in 1.1 to clarify this.

Vehicle property changes was the larger discussion and need. It's not clear how to handle this at the moment, so discussion is needed. The issue #899 has been renamed to reflect this need.

Minutes

Notes

Allowed each new MDS steering committee member to introduce themselves

Reminded people that feedback is needed on Policy real-time updates in PR #928 - likely end of April so get your comment in now

Reviewed new idea to return only relevant geographies in Provider Reports. See issue #873 and PR #930

  • SFMTA - motivated by their permittees' feedback. 60 geographies in Policy API, only a subset of 20 are needed for reports
  • Geographies are immutable, so don't get removed later, need to keep them organized
  • See SFTMA's geographies in operation in their requirements file
  • Clarify in description that it's for reports only.
  • Not breaking, will go to dev soon, looking for final feedback

Discussed adding operations start and end dates to VEHICLES endpoint #899, PR #913

  • Talking about when vehicles went into service, and when it left service

  • What makes a new vehicle, IoT device? Ship of Theseus

  • When a device changes, no way to know when one left service or changed, and when a new one went into service?

  • 'service' could be confusing because it could mean maintenance, or servicing. Maybe "lifecycle" may be better

  • New device id when?

  • Device ID from spec:

    • "device_id must remain constant for the device's lifetime of service, regardless of the vehicle components that house the device." (may need to read "that are housed in the device?" Or is the device the IoT device?)

  • when attributes associated with device ID, need to know date when ID changed.

  • History of changes to device, dates of change

  • Vehicles definition:

    • When /vehicles is called without specifying a device ID it should return every vehicle that has been deployed in an agency's Jurisdiction and/or area of agency responsibility in the last 30 days.

  • When the vehicle changes in a significant way, without getting new device id, like accessibility attributes. Audit trail.

  • Environmental element of micromobility. NUMO lifecycle definition. Fire liability. Micro-emission guidebook.

  • State machine diagram has:

    • Decommissioned event, after removed/missing/elsewhere/nonoperational states

  • Is this a new event type? Vehicle property update?

  • Record timestamps of when this happened and complete - tracking attribute changes

  • Do you just need the vehicle property updated date, for when something is changed in vehicle properties?

  • Providers know this better than agency, so provide this to city directly vs tracking it down and calculating it

  • one field that was 'vehicle last change' timestamp in the vehicle object, to know when there was a change?

    • when does this get triggered
    • service term might be daily, what is right term?
    • same vehicle new license plate, battery, accessibility, etc
    • maintenance or change audit trail, array of history of changes
    • note each Mode has its own properties

  • vehicles object and endpoint is just the real time status of vehicles, not their history. Static snapshot of info, vs transactional

  • inspection date field is there

  • Action Item: love to hear move from operators, vendors, data aggregators. Comment on GitHub now

    • challenges or issues from them

  • vehicle_property_change start and end term. Is it any change, what changes, any attribute in MDS?

  • Pierre at Blue Systems will weigh in and support

Thoughts from steering committee discussion:

  • Knowing when properties of vehicles change, like accessibility
  • Identifying what an actual vehicle is - battery, brains, frame, etc?
  • Start and end of lifecycle. Green, carbon footprint, lifetime operations process for a vehicle
  • LA fines vehicles based on condition of vehicle. Tracking of damage and repair. Safe rideable condition
  • Taxi check and inspections
  • NYC dot escooter, don’t track specific components, maintenance frequency on street on regular basis, warehouse maintenance based on distance travelled
  • Already receive monthly maintenance reports in ad hoc format, beneficial to standardize this in MDS instead
  • Happens now in MDS events, street or warehouse, when and how long, but not what
  • Maintenance requests as part of permits and operating agreement are common. Could add vehicle maintenance log to MDS in a new data structure.

Chat

omf-mds-github-footer

MDS Wiki Home

MDS Links

Working Groups

2.1.0 Release

2.0.0 Release Plan

1.2.0 Release Plan

1.1.0 Release Plan

1.0.0 Release Plan

0.4.1 Release Planning Meetings

0.4.0 Release Planning Meetings

0.3.2 and earlier Release Planning Meetings

Clone this wiki locally