Web conference notes, 2026.02.12 (MDS Working Group)
- Monthly on Thursday at 9am PT, 12pm ET, 5/6pm CET - open to the public
-
Zoom Registration and Join Link: https://us02web.zoom.us/meeting/register/tZAscOmhpjIuHNakPx6CNbACpjUjw1Gsucr4
- One tap mobile: +19294362866,,84170989462#,,,,*612987# US (New York)
- Signup to the Mailing List for emails and calendar invites
Vehicle Hardware and Software Properties and Maintenance
Agenda
- Intro and announcements (10 min)
- Vehicle Hardware and Software Properties and Maintenance #705 (45 mins)
- Draft changes in Pull Request #969
WGSC Meeting Organizers
- Host: Michael Schnuerle, OMF
- Facilitator: Michael Schnuerle, OMF
- Preparation: Michael Schnuerle, OMF
- Outreach: Michael Schnuerle, OMF
- Note taker: Michael Schnuerle, OMF
- 35 Attendees
- OMF Slides
-
Recording - Passcode:
04Qq@KJB
Michael: We've moved the timeline of the MDS 2.1 release back about a month, maybe two, because in March we really want to have a European focus and time for feedback from the European audience. OMF will be going to Europe. The staff will be going for inter-traffic, an event there. We will be presenting at European Polis online webinar and education session about MDS. We did one for CDS. And the next working group meeting, is going to be European focused. So we'll actually shift the date and the time to align better with European timeframes. And so we really want to drive that focus for Europe. And so before we release it, we want to make sure everything aligns. The release draft may be ready March or April, depending on how that feedback goes. And the final release approved sometime April or May timeframe.
Andrew OMF: We have an opportunity to bring some really exciting new features into MDS from crash and incident data to the expansion of delivery fields. Very relevant to cities and stakeholders in Europe. And so in partnership with Polis, the European NAPDO, if you will, were able to bring some of this work front and center and be able to engage the community in Europe and make sure that what we're doing really aligns with their needs and interests as well. So it's an exciting chance to have both virtual sessions, but also be on the ground and really promote the benefits of open source data specifications like MDS and CDS that are widely used across Europe, but are not officially endorsed specifications by the European government.
Andrew: Opportunity to respond to a request for information USDOT on their development of a digital infrastructure strategy a national digital infrastructure strategy several of you have have mentioned this brought it to our attention asked whether we were planning to respond so we wanted to make sure that we took minute or two here on the working group to highlight this opportunity to provide some insight back to USDOT on the work that the OMF and all of you are doing in this space around the digital tools like MDS and CDS as well. So you can see very high level here, they're asking, they ask a series of questions in the RFI seeking responses in these four key areas: research development and deployment, system architecture, interoperability and standards, artificial intelligence and automation, and data governance, privacy and cybersecurity. So you can see some of these topic areas are more directly relevant to the work we do and some of them a little bit less so. But we do plan on putting together a response and making sure that we're able to explain to USDOT as much as we can the work that we're doing and the relevance of digital standards like MDS and CDS.
Link to RFI - Due March 6
And we know that that U.S. DOT and specifically under the Federal Highways Administration, the ITS Joint Programs Office is very interested in the work we do and interested in getting more involved in supporting our standards development work. So we want to make sure with an opportunity like this that we are able to reinforce the importance of the work you're all doing and how this co-creation of open source standards like MDS is important as a component of a broader kind of multifaceted national digital infrastructure strategy.
Michael: vehicle properties and maintenance of vehicles in MDS
MDS may need a way to capture things like vehicle hardware generation or model. When we talk about a vehicle, it could be anything that MDS supports: scooters, bikes, sidewalk delivery robots, taxis, for hire AVs, car share, fleet vehicles, anything that is a vehicle or a device in the MDS world. And so you can think about this in a lot of different ways. The original issue is open because of this specific field wanting to know like a model number of a vehicle like a scooter, but it can apply to every mode.
The next thing is the main part of the vehicle software version. If you're driving a regular car or let's focus on a Waymo maybe, they have a certain software version that the main car is running. Scooters as well, these things get updated either over the air or when they're taken in for maintenance. We already have this field in delivery robots right now as part of the conversations. It's something that cities were requiring in permits for delivery robots.
We have in events now when maintenance happens. There's an event where you can say maintenance has happened, whether it's on the street or it's been removed from the right of way, put into a shop and some maintenance has performed and now maintenance is over and it goes back. We have a date time of maintenance events, but no details about them. We don't really know what happened during those maintenance events. We don't know what was the maintenance for, was it new tires on a car or was it fixing a seat on a seated scooter? Was it some software or hardware fix that was needed to be done on a delivery robot, etc.
Why does my city and or as a city vendor and or as a operator, why would I need these pieces of data for one reason or another?
Vladimir here from LADOT. I think I'll just start it off because we had this discussion. This is something that's been going on in the city of LA. We use MDS to manage so many different things. As I always say, it's the backbone to just how we even have programs at LADOT. In the micro mobility space, we're starting to see, let's just say one company sometimes have multiple different types of vehicles in their fleet.
And as these new technologies are being introduced in the public space, there's multiple questions that pop up from them. How are they doing? Is it a scooter? Is it a bicycle? Is it something that you just sit on and there's no pedal assist? Is it this or that in the different form factors? And we want innovation. We want new things being brought to all our customer base and all our residents.
Because people want different types of technology, right? But how do we measure that, right? We don't know. So sometimes that's why we need to know what model the vehicle is. And is it the latest model? Was it updated? Now these fleets and these companies are having maybe two or three different versions of a vehicle. And how can we track them? What can we learn from them? How do we let council offices know, like, oh, these new vehicles are non-pedal vehicles or something are doing this or that. So there's that. We want to know that. It's important to know that.
And also with, for example, robot delivery, there's different versions also that are popping up from these different vehicles. So like a city, we need to know all these different things and we need to say, are they running what version of softwares and things like that? And did they do it update maintenance? It's helpful also to have this kind information.
Even insurance and maintenance stuff is also very important, because that is something that for managing car fleets, which we're trying to get all our city cars within our department also on this. So there's just multiple, multiple cases that we're trying to learn about. We really want to hear everybody else's experience on this or even possibilities of this.
Michael: I think the city fleets is a great example of why you might want to know maintenance and of course all the other modes you talked about too.
Pierre from Blue Systems. So essentially, I so 100% concur with what Vlad just said about the vehicle hardware and software versions. Most importantly about the hardware version, because it's true that for existing providers, one of the challenges that we have is like dealing with different generations of devices. And so being able to get the generation model would really be useful even for operators themselves who are trying to, you know, make the case that such new generation of devices is more useful.
I mean, I don't know, is safer or such and such, you know, being able to differentiate it in the data so that we build the metrics to prove those points and for them to be able to prove those points, I think is really valuable. For the software, I get what Vlad is saying. I see like there is a potential use case in the future, but I don't have like it's super fleshed out just yet. But while we're at it, and since it's optional, it only adds possibilities and removes nothing from anyone. So I'm happy with that.
Everything around the maintenance events is something that we already actually pretty much. Well, it's something that we already use with New York City DOT. We have a use case where we help New York City DOT track for their e-scooter program the frequency of maintenance for devices. And for e-scooters in two different ways because right now, while you're absolutely correct, the maintenance events do not allow us to know what happened during the maintenance. We're still able to tell apart on-street maintenance from warehouse or workshop maintenance. And so we're already able to help cities monitor frequency of maintenance events. I mean frequency both from like a time perspective, meaning every week, every month, every quarter, whatever, but also from a vehicle miles traveled perspective. So for example, this vehicle, this type of vehicle should go into maintenance every say a hundred miles, 200 miles traveled. Right. And so these are policies and things that we already have implemented, and that have already been running for quite some time in New York City. So that's where I think this idea of leaning more on the maintenance events than adding a last maintenance date at the end at the vehicle level stemmed from.
I'm happy to, you know, generally speaking, I'm happy to add any fields that are optional to add some data to the standard and to the data structure. If there's a use case that's well-defined by a city, and that seems to be the case now, and it's not breaking or problematic for anyone else. I'm all for it, generally speaking.
Michael: I see two operator participants at the moment from Bird and Zoox. Do you all have any questions? Are you maybe already wanting to share this or sharing this in some other way, like a manual report about maintenance and maybe be good to have it in MDS?
Zoox: Not that I'm aware of, Michael. I don't want to speak out of turn.
Michael Schwartz from INRIX. So we've gotten stuff a little bit like this, but I think probably even more so something we've been trying to do is clean up and get a consistency around vehicle type and propulsion type, just because there's now particularly a micromobility, such a wide variety where there's like a pedal assist bike versus a throttle only bike. And I think each operator is mostly following something similar but there's a little bit of a difference and it gets at some of these same use cases of really being able to distinguish what is a very particular vehicle type making but I could see where building on those same questions where like having a generation could also be interesting too where we're starting to see okay what is how many vehicles in our fleet are of a certain generation and how are they performing versus other ones are people you know looking at uh you know if they see two bikes right next to each other one looks completely newer um are they using those differently.
Matt at Populus - We had a case where like a a city and an operator were in negotiations where the city wanted them to deploy a new vehicle, around sidewalk detections, so the operator was under pressure to deploy new generation of vehicles, and the city wanted that info flowing into our platform so they could monitor whether or not the operator was doing that deployment of new vehicles. Came up with a non-standard way to include model number in payload.
Michael: You sort of had to find a field that wasn't necessarily meant for that. And whereas this, you would be able to capture it more clearly.
Opened by Vianova, another vendor for cities mostly focused in Europe. Do these 3 optional new fields meet the needs of the use cases that you have, and does anyone have any recommended updates or changes to this draft?
Does not affect the Events and States state machine diagram. Just one new field in Vehicles, and one new field in Events, plus a description field in Events.
Support expressed by Blue Systems ("Fully support this"), LADOT ("I think it would solve the questions that we get all the time." Council asks LADOT if the city is taking care of maintenance of operator vehicles, and with this now they can say they are and will have data.), SFMTA supports.
Future version of this in MDS could make hardware and software versions as defined values, instead of open text, but good start for now. Simple solution now, and not over engineered.
The next meeting is planned for March 12, a month from now, four weeks from now. But we will probably have it at an earlier time to accommodate Europe. So it'll be a European-focused public working group meeting, maybe on March 25th or 26th at an earlier time. You'll get an email about it on the mailing list. But because it's focused on Europe, it'll probably be half a recap of what is going to be in MDS 2.1 and the other half available for feedback from anyone who's participating in the meeting. So if you're interested in that, maybe as an operator or even a city that's interested in learning about MDS or learning about what's happening in Europe or feedback they might have, you can come to that meeting, look at the agenda when we send it out, decide if you want to attend or not.
Hope that members will take advantage of this learning opportunity.
Aylene: OMF Academy is a really great new tool, especially if I don't doubt that anyone on this call really doesn't understand MDS, this is for your colleagues who you keep trying to explain MDS to. It is very introductory. We're going to really build some foundational understanding of why standards and specifications are not just critical to digital infrastructure, but like why they're really normal and also very standard in industries, in the growth of that industry and how that helps that industry scale. And this is meant to give everyone a foundational understanding of these, to help with some talking points. We're going to do some storytelling. And so it's really going to be ideal to have your colleagues that don't understand what you do, help them understand what you do. For our public sector employees, I think this session is going to be ideal if you need to convince some of your elected officials and their staff why to invest in this.
Maybe some of our commercial partners, if you are dealing with a similar situation with an OMF member customer, it might be great to make sure they head on over to these sessions. So they're duplicate sessions on March 4th and March 19th at a little bit different times.
If for whatever reason you can't attend these and we get a really great interest, I'm actually already very pleased with how many members have registered. We are absolutely going to be doing some more in the future.
If this is too elementary for you, don't worry. We're going to have MDS and CDS 101 in April and May. And then we'll have some more implementation-oriented sessions later on in the year. And then from that, we're going to take your feedback from the community on what sessions we need to expand upon and build. And then preview, we have some funding proposals out to request an infusion, a big chunk of money to scale the implementation of this program. It's so far successful in those. You can see some like really exciting plans for this, maybe like a certification or in-person sessions or cohort experience. So I will also give a shout out to Passport for underwriting this initial program portion of the Academy. And we have a suite of advisors, our OMF Academy advisory group that is helping to give us feedback to help grow this program. Great. Thank you, Aileen, for that. We're excited about the Academy. I think it's going to be really great.
So please register if you are an OMF member.
-
What is the main purpose of the proposed additions to the Mobility Data Specification (MDS)?
- The main purpose is to add fields that capture hardware model and software version information for vehicles, as well as a description field for events, to improve tracking and monitoring of vehicle types, software updates, and maintenance activities.
-
Which three new fields are proposed to be added to MDS?
- The three proposed fields are: 1) hardware model added to the vehicle object, 2) software version added to events, and 3) a description field added to events.
-
Why is the hardware model field added to the vehicle object rather than events?
- Because the hardware model is a more static attribute that does not change often, so it fits better as a property of the vehicle object rather than being attached to individual events.
-
How is the software version field intended to be used in events?
- The software version field can be optionally included with any event to indicate the software version of the vehicle at the time of that event, such as during maintenance or software updates.
-
What is the purpose of the description field in events?
- The description field provides an optional textual explanation or reason for the event, such as details about maintenance performed, software upgrades, system suspensions, or inspections.
-
What challenges are mentioned regarding standardizing hardware and software version fields?
- Currently, these fields are open text strings because different operators use different naming conventions. Standardizing these fields is challenging due to the variety of vehicle types and modes, and it may be considered in future versions after gathering initial data.
-
How does the proposed solution address the needs of cities and operators?
- It provides a flexible way to capture detailed vehicle information and event descriptions, enabling cities to monitor deployments, maintenance, and software updates more effectively without imposing heavy implementation burdens on operators.
-
What feedback did participants give about the proposed changes?
- Participants generally supported the proposal, noting it solves common questions about maintenance and vehicle details, and appreciated the flexibility of optional fields. They also emphasized starting simple and avoiding over-engineering.
-
What is the significance of the upcoming OMF Academy sessions mentioned in the meeting?
- The OMF Academy sessions are designed to educate members and their colleagues about MDS, standards, and specifications to build foundational understanding, support adoption, and facilitate better communication about digital infrastructure in mobility.
-
When is the next public working group meeting planned, and what will it focus on?
- The next meeting is planned for late March (around March 25th or 26th), focused on Europe, with a recap of MDS 2.1 developments and an opportunity for feedback from participants.
Attendees from LADOT, Blue Systems, SFMTA, OMF, Populus, Zoox, Bird, INRIX, IPS Group, Serve Robotics, DRCOG, King County, Coco Delivery, Oslo, Omaha, and others.
- 00:09:03 Andrew Glass Hastings (OMF): Hello everyone! Thanks for joining. Great to see you here today. If you haven’t done so already please be sure to change your name to add your agency, company, org. Thanks!
- 00:11:03 Andrew Glass Hastings (OMF): USDOT Digital Infrastructure RFI:
- https://www.federalregister.gov/documents/2026/02/04/2026-02236/office-of-the-assistant-secretary-for-research-and-technology-request-for-information-research-to
- 00:13:23 Michael Schnuerle (OMF): Please introduce yourself in the chat if you’d like!
- 00:20:50 Kim Ramkishun (IATR): Kim Ramkishun, Executive Director, International Association of Transportation Regulators (IATR)
- 00:21:03 Andrew Glass Hastings (OMF): Reacted to "Kim Ramkishun, Execu..." with 👋
- 00:25:13 Remi Kuti Founder & CEO (UrbarnShield): Hi everyone — I’m Remi Kuti, Founder of UrbanShield (UK).
- We’re building shared helmet safety infrastructure for micromobility fleets, integrating crash detection, emergency ID, and fleet safety data to support operators and city reporting.
- Great to be here and looking forward to the discussion.
- 00:28:28 Andrew Glass Hastings (OMF): Reacted to "Hi everyone — I’m Re..." with 👋
- 00:29:45 Matt Davis (Populus/IPS): We had a use case once where the city wanted to see that the operator was deploying an updated generation of vehicles (for safety reasons) via our platform. I don’t remember exactly how we handled it.
- 00:35:38 Michael Schnuerle (OMF): Issue https://github.com/openmobilityfoundation/mobility-data-specification/issues/705
- 00:42:11 Michael Schnuerle (OMF): For those wanting to see the details, here is the draft pull request. https://github.com/openmobilityfoundation/mobility-data-specification/pull/969
- 00:52:01 Aylene McCallum (OMF): Just want to remind all of the OMF Members on the call that we are hosting our first OMF Academy session on March 4th and March 19th (duplicate sessions)
- 00:52:16 Aylene McCallum (OMF): If you did not receive the registration link, feel free to email me: aylene@openmobilityfoundation.org
- 00:52:37 Aylene McCallum (OMF): These sessions are limited to OMF Members only so if your organizations is curious about joining - please also reach out.
