MDS Crash and Incident Report Data in trips and status changes

[tybaltspark]

Is your feature request related to a problem? Please describe.

Several cities are inquiring about crash data. We have been supporting them in linking this data with street usage and existing infrastructure. Crash data are today issued from manual reporting at hospitals. It provides timestamp, location and type of vehicles. This data however is not of high quality, and it is difficult to make meaningful statistics out of it and hence support decision-making on infrastructure or policies.

Describe the solution you'd like

I believe it could be valuable to add this to the /status_changes endpoint. For example, I would see a transition from on_trip to unavailable with event_type = accident/crash. I don't know to which extent providers can obtain this information "live". Clearly a survey just after a crash is difficult. Some providers have reporting process through the website. I wonder whether the (next generation) vehicles are (will be) able to detect crash with accelerometer & speed data. A good question to operators. Ideally this would be part of the /status_changes endpoint. However we could also imagine a separate reporting but it may add complexity.

Today, this would be very useful as historical data to get analytics on crash for shared micro-mobility and link it to street segment. However, tomorrow, in a broader context, I believe this is a great step for connected vehicles to report 'live' crash to roadway authorities and emergency services.

Is this a breaking change

I don't believe this is breaking.

Impacted Spec

Provider

Describe alternatives you've considered

An alternative could again be separate monthly reporting in csv by providers where we would see the number of crashes. However this would be left to goodwill reporting by users & providers.

[joshuaandrewjohnson1]

Currently operators rely on users to self-report crashes, with users providing varying levels of detail and accuracy, so reliability of this data can be questionable. Many cities already require us to provide this through a monthly report.

[marie-x]

This would apply to Agency as well

[schnuerle]

As @joshuaandrewjohnson1 says many cities do ask for this as part of a monthly report from providers. So this could be added to the Provider Reports part of the spec. Though in this scenario the result would be in aggregate counts, and not tied to specific trips. Though like mentioned it may not be possible to attach crash info to a trip or status changes in real time - though maybe they could be added a month later so they'd show up in historic data pulls?

[tybaltspark]

@schnuerle could this be discussed at the next working group? ideally with operators I'd like to understand what is possible technically today and... tomorrow. And how we can serve this objective today with technical constraints and available endpoints. Provider Reports could be a good middle-ground if we can't get this data live at first

[bhandzo]

We (Bird) would not be able to provide crash data via a provider type endpoint, now, or in the future, for a variety of reasons. We do provide this as monthly reporting to many cities.

What constitutes a "crash" is very poorly defined, and there are significant legal requirements about when and how we share information about crashes. We currently rely on riders to report their crashes to us, however even if we had vehicle diagnostics that indicated some sort of collision, that wouldn't be something that could be reported as a "crash" because we would need to know the specifics of what happened (person fell off, scooter fell over when parked, etc.). For all these reasons it wouldn't make sense to add this to provider.

Adding this to a monthly reporting standard makes sense as we are currently reporting it, and it would be helpful for OMF to help standardize the definition of what constitutes a "crash".

[joshuaandrewjohnson1]

Happy to have further discussion, but would like to add a couple considerations on the idea of getting "live" crash data:

• Aside from the question of what can operators actually record from sensor data, as Ben mentioned above, what are we considering to be indicative of a crash? Taking sudden deceleration as an example, this could produce a lot of false positives where a crash didn't actually occur.

• What actions or use cases would a city have with that "live" data? There is a privacy risk with that location data being shared with other departments or agencies if the intention is for some sort of immediate response, in addition to the question of whether or not a crash actually occurred. If it would be used for planning purposes, realistically any actions taken would be based on historical data.

[tybaltspark]

Thanks @bhandzo & @joshuaandrewjohnson1 for the insight. Today I don't have use case expressed by cities for live data, to be clear. Historical reporting would be enough for the planning and statistics needs asked by authorities. (Live data was an idea for a future need for emergency response)

For the cities we support, we get the "crash" data from the hospitals which label e-scooters, the street location and the date/time. The main goal is to map the crash data with current infrastructure and car traffic data, to get a crash risk analysis and drive investment. The other objective is also to relate that to the actual number of trips vs sometimes misinformed headlines in the press.
--> Monthly reporting is good for these purposes

[tybaltspark]

@schnuerle could this be discussed in the our next calls ? When would be good ?

[schnuerle]

I'll ask the Working Group Steering Committee if it can be a topic for next week's meeting. We can focus on the idea of this in monthly reporting (vs real-time) based on the feedback above from providers.

[tybaltspark]

Sure sounds good with next week's meeting

[schnuerle]

Ok let's talk about this on tomorrow's WG call.

[andrearjona]

It would be useful to cities to obtain acceleration data to inform a host of potential issues (e.g. high pedestrian volume and lack of bikeway infrastructure, and/or a potential barrier or crash). Most cities already obtain higher quality crash reports from other sources- it is the minor collisions that we do not know about because typically these are not reported to companies and/or cities.

[schnuerle]

From the WG Call yesterday:

• Accident info for cities. Knowing where the crashes occur can be acted on.
• Already requested from many cities in different ways, and received from providers.
  • Some ask for nature of crash, types of vehicles, location/date/time, alcohol.
  • SF takes in self reported data knowing it has data quality issues. Pulling in other sources, try to link incident at hospital with where/it happens.
  • Use cases: infrastructure and public communication of issues/fixes, Europe press/issues with intoxication
  • San Jose gets collision data. Including if someone was under influence.
  • Minneapolis used it for quick build opportunities
• Agree it could be monthly but needs to have more granular data
  • to be useful, at least lat/lon where it happened and time of day. Date in the month is not as important.
• What is a crash, need to define what it is
• Could add injury to capture more data
• Agree it should be aggregate for sure, not on individual trips
• Maybe give exact location and hour, but not day would be possible?
• Police reports are sometimes public record. But other injuries may not be reported for a specific reason by the rider.
• Does it save providers any work? Not if it loses data cities get now, and cities still ask for the more detailed reports. Could help replace requests from new/some cities.
• Quality of data is an issue, since crashes are self reported.
• Could add more data with everything that could be a crash, eg, ‘sudden deceleration’, so there are lots of data points to mask real crash incidents, but provide a novel, useful data stream.
• Deceleration events - providers on call say their hardware doesn't have this yet.

Three main ways this crash data idea could go now:

1. Detailed location info for crashes. Privacy a concern. But cities may get this internally and probably more reliably already when there are injuries through police reports
2. Aggregated Provider Reports, useful for some cities
3. Sudden deceleration data - may not have this info, maybe for future
   • Spin and Superpedestrian on the call don't do/have this.
   • Note from time at Zipcar it's a hard problem.

@dirkdk @bhandzo and other providers: would like feedback with your thoughts on what could be useful to you, how you gather crash data, and if you have sudden deceleration hardware/data.

[dirkdk]

Using accelerometer data for crash detection would be flawed. Too many false positives I would guess I'm not aware of Spin's current vehicles being able to detect deceleration or any plans to work on this.

Crash data for us is human reported and hence fairly delayed. If we would want to include this in MDS, monthly aggregated reports would be my suggestion.

[joshuaandrewjohnson1]

Given the significant challenges that are agreed upon among providers as noted in previous comments, and prior to proceeding further down this road, I'd be interested to hear from cities on current use cases and policy relevance for accelerometer data specifically. Based on the working group discussion, it seems that aggregated monthly data shared by providers satisfies current needs.

[schnuerle]

The City and Provider Working Group Steering Committees met last week for the Midway Checkpoint for the 1.2.0 proposed release. The Checkpoint let them review feature proposals, align current work to goals, and ensure the release features and work is on track. 

For this work, we have created a new rubric to help guide the evaluation, looking at feature utility, stakeholder adoption, implementation simplicity, direction consensus, and work completed as part of the evaluation criteria. The outcomes and actions from these discussions are summarized here:

This proposal needs work across the board, since currently 3 options are proposed, and there is not agreement on implementation or how it would work, within MDS or from equipment/data available from providers. Agencies certainly would like this data, but people self report and it's not real time so data is minimal. What city would use the sensor data in a meaningful way and rely on it?

Actions: Create a clear proposal based on discussions and see if it's possible and multiple orgs can commit to it.

[mschwartzie]

Even if the consensus is to continue monthly reporting, some standardization of what/how data is collected would be useful. I recommend consulting with entities like Pedestrian and Bicycle Information Center and/or Vision Zero Network research leads as part of this effort.

[bhandzo]

I'm still quite strongly opposed to this. Not because we aren't willing to share information about crashes, but because the definitions here are not nearly well enough defined for this to work.

Sending through raw accelerometer data, or an indication of "sudden decelerations" is not going to be useful to cities, as every provider will define this differently, uses different hardware, and will process this data differently.

[marie-x]

Having come from Zipcar and been hip-deep in telematics, I agree with @bhandzo. IMHO there is no way to make consistent sense of accelerometer data.

[schnuerle]

Elevating this issue again because it has come up numerous times recently in conversations around the MDS passenger services mode, specifically autonomous vehicles and robotaxis where they are equipped with sensors and remote monitoring to pretty accurately know both in real time and historically if a crash occurred. Also applicable to taxis with human drivers. So adding information about if a trip or status_change had a crash and some info about that crash is very possible in these cases, so they could be made optional fields for use in this mode.

[schnuerle]

Per our Working Group meeting last week, there was discussion about this again in the context of road safety.

OMF member Vianova is looking into this with their Road Safety Survey, and this issue is relevant.

[schnuerle]

Creating a data standard within MDS around crash data would be helpful in general, as there is no standard for crash data now.

This crash data could be applicable directly to 3 of our modes (Passenger Services, Car Share, and Delivery Robots) and possibly some Micromobility (though the other modes have more sensors around this).

[schnuerle]

What data would you like to see reported? At minimum it would be a yes flag on a new field like crash_occurred just to say that a crash did occur on a certain vehicle and/or trip, with the date time, vehicle id and info, and the location as part of the existing data. Is flag this enough?

Or do cities also need to know severity of crash, if there was an injury, number of vehicles involved, if there was a fatality, vehicle speed, etc? All of these additional data points seem useful, but will be harder and harder to report on in real time or even historically.

I think we want data that is achievable to provide for most modes (Passenger Services taxi/AVs, Car Share, and Delivery Robots) for at least a few operators, and not suggest fields that are out of the realm of the possible now. But on the other hand, all these fields will be marked as optional, so operators will only provide what they can.

[schnuerle]

In MDS 2.0 (which no longer has /status_changes) which of the following endpoints does this crash_occurred flag and possible data get added to:

• /vehicles/status - real time to flag when the crash occurred, and on which vehicle
• /telemetry - real time when not on a trip, or historic when a trip is completed, to know the location (lat/lon) where the crash occurred
• /trips - historic and high level, to flag when there was a crash on a trip

And/or does it get added as a new kind of Event in the vehicle state, where the vehicle transitions from a state like on_trip or available into a new event type and state like crash.

• /events/recent
• /events/historical/

I personally think it should not be an event transition, but instead be info added to thee vehicles, telemetry, or trips endpoints and have the events operate independently of when a crash occurs.

[schnuerle]

From WG meeting July 11:

Instead of boolean value, maybe type of incident, categorizing with near miss, crash, vandalism, etc? Including things not in police reports, like info from customer to operator that doesn't always get to the city/police.

NHTSA is developing a definition for AV near misses. ADS crashes are reported to NHTSA/ and those that occur in CA, are also reported to DMV and CPUC. https://www.nhtsa.gov/sites/nhtsa.gov/files/documents/dot_hs_811_382.pdf

Look at how this is structured for airplanes or other modes, to not reinvent how this works. Use an existing familiar method for this, like statewide standardized crash reporting. Jarvis from LADOT may have ideas from Feb/Mar presentation.

The more we can contextualize the incidents the better, depending on the vehicle. Many on the market now do this very well right now. Lime is categorizing incidents well based on history of the driver/rider in the UK.

LADOT example of delivery robot crashing with AV car. Would be good to track strollers, pedestrians, vandalism, etc incidents with robots. Good to have the data point to have the discussion.

Note that crash reports are not available to cities in California below a certain threshold. Crash definitions across orgs are not always apples to apples. Austin has a public dashboards of near misses and other reported crashes. https://www.austintexas.gov/page/autonomous-vehicles

LADOT MDS for taxi work and policy. https://ladot.lacity.gov/sites/default/files/documents/ladot-taxi-and-fhv-final-report-draft-for-distribution_0.pdf

[PazAlex]

To do a bit more synthesis of our current perspective at Vianova:

• This should be a component of telemetry, over trips or events.

-An "incident" should be defined, but with a range of fields to include non-collision occurrences (for example, when a tele-operator takes control of an AV)

-An incident should have optional fields which describe additional relevant information (damage to property, injury, etc)

-Regulating agencies should make the decision about which incidents need to be reported as permit conditions

-The array of available incidents should be addressed based on mode? That would prevent mis-categorization.

-I think we need to be able to allow for both historic reporting of incidents but should preference the automated reporting.

We're excited to get cracking on this topic. Perhaps the best thing to do is to start on a list of incident types by mode, which we can begin to polish up?