SUPPORTING NEW MODES IN MDS

​

August 2021

HOW TO ADD NEW MODES TO MDS?

DESIGN GOALS

DESIGN GOALS

• Flexibility: Design should support a variety of modes, existing and future, even those substantially different from micromobility.
• Legibility: Preserve MDS’s straightforward API and data model that map to real world concepts.
• Single-mode implementations: Minimize implementation burden for those using only one mode, including existing micromobility users.
• Cross-mode analysis: Where plausible, support data analysis across modes with the use of common types and definitions.�

​

WHAT’S DIFFERENT

STATE MACHINE

• Each mode has its own operating / business model�Micromobility is point-to-point. Delivery robots do multi-leg trips. Ridehail trips can be “pooled” with multiple traveling partiers sharing a car some of the time. Car share can have many trips during a single reservation.
• A mode-specific “state machine” is needed�By matching the event_type and reason codes to the specifics of the mode, mode-specific information can be conveyed.

TRIP RELATIONSHIPS

• Mechanism to describe complex trips is needed�For multi-leg or multi-party trips, a single trip record is insufficient to describe the various aspects of the journey.
• Components of a trip differ by mode�A “pooled” ridehail trip may have many passenger groups that combine into a single trip, while a delivery robot trip may have defined phases (pickup, dropoff, return to base).
• A flexible relationship model is needed�Each mode must define the component parts of a trip and the relationship between them in whatever way makes sense.

VEHICLE TYPES

• Modes have their own types of vehicles and relevant vehicle characteristics�A delivery robot is not a scooter is not a car. Within each mode, different vehicle attributes will be salient for reporting. E.x. accessibility features, cargo capacity, make/model.
• Each mode should have its own set of vehicle types�Rather than attempt a vehicle taxonomy that encompasses all modes and the relevant vehicle characteristics, vehicle types should be defined on a mode-by-mode basis to align with what’s relevant to policymakers.

POLICIES

• The Policy API is optimized for micromobility�The current set of rule types allowed in Policy is tailored to micromobility regulations (caps, speed, no parking, etc). It needs to be made extensible for mode-specific regulations.
• Even where rule types are similar, each mode will have its own rules�Cities are unlikely to use the same regulatory framework for different modes, so it must be possible to specify a mode-specific rule set.

PROPOSED CHANGES

GLOBAL STATES, MODE-SPECIFIC STATE MACHINE

• All possible states and events defined in a single list in /modes/event_types.md and /modes/vehicle_states.md�A global list of event types and vehicles states makes it possible to analyze data across modes. New event types and states can be added to the global list where needed, but reuse is encouraged.
• Each mode will have its own defined rules for state transitions�MDS currently defines what state transitions are allowed, but only for micromobility. For example :

​

on_trip ➡ available

event_type: trip_end

✅ ALLOWED

on_trip ➡ available

event_type: maintenance

❌ NOT ALLOWED

VEHICLE ATTRIBUTES

• Global vehicle_type and propulsion_type will remain�Because cross-modal analysis may wish to unpack broad patterns in mobility, having a global taxonomy for vehicles and propulsion is valuable. Both fields will likely need to be extended with new options.
• New vehicle_attributes field allows for mode-specific data�Because the policy-relevant characteristics of a vehicle differ by mode, each mode will be able to define its own with a set of key/value pairs.�For example (taxi):

​

GLOBAL FIELDS

vehicle_type: car

propulsion_type: plug_in_hybrid

MODE-SPECIFIC ATTRIBUTES

”passenger_capacity”: 3,

”wheelchair_accessible”: false,

”make”: ”Toyota”,

”model”: ”Prius Prime”,

”model_year”: ”2020”

​

​

RELATED TRIPS

• Every trip record or trip-related event can optionally specify a related_trip_id and a trip_type field�Flexible mechanism for creating relationships and hierarchy within and between trip records. Can be used to link multiple legs within a single journey, or to connect multiple journeys togethers.
• Meaning of related_trip_id and allowable trip_type values are specified on a per mode basis�Each mode can define how to use these fields based on the needs and characteristics of the mode. While the syntax of these fields is global, the semantics are mode-specific and therefore not suitable for cross-mode analysis.�

​

RELATED TRIPS EXAMPLES

RELATED TRIPS EXAMPLES CONT’D

POLICY API

• Establish a mode filter for policies�Each mode will have its own set of policies which will exist in a domain fully-separate from the policies for other modes. The mechanism for specifying which mode a given Policy API request is for is still to be determined.
• New policy rule types�Although the list of possible policy rule types will be defined globally, new modes may require the addition of new rule types. Reuse of existing rule types is encouraged, where appropriate. For example, delivery robots may require a new rule type to specify what part of the sidewalk they are expected to travel on.

​

​

/MODES DIRECTORY

This top-level directory will be added to the MDS repository and will contain all mode-specific definitions.

OPEN QUESTIONS

FOUNDATIONAL QUESTIONS

1. How do we define a mode?�Does the concept of a “mode” represent a category of vehicle, a business model, or a regulatory designation? Are scooters, e-bikes, and pedal bikes all one mode? Are station-based, free-floating, and peer-to-peer car share all the same mode?
2. What do we call a “mode?”�Is “mode” the right term to capture the answer to the question above? Alternatives could be: service, service model, mode category, modality, regulatory model, mobility type, program, etc.

IMPLEMENTATION QUESTIONS

1. Does the related_trip_id approach make sense? Or, should we formally encode different trip types/elements in the data model?�While the related_trip_id/trip_type approach is highly flexible, it is not particularly legible. Understanding the relationship between trip records requires consulting external documentation and possibly reconstructing a hierarchy that is not explicit in the data model. Alternative approaches would be to elevate concepts like “trip leg” or “driver session” to be globally defined entities, or use a parent_trip_id, sibling_trip_id, child_trip_id structure to make hierarchy more explicit. The various options represent a trade-off between legibility of relationships and the addition of more mode-specific fields in global data structures.

​

IMPLEMENTATION QUESTIONS CONT’D

• How are modes specified when interacting with APIs and data?�We could add a mode field to individual records or as a request parameter. We could also designate separate URLs for specific modes or link mode to a provider_id.
• Do we need a mechanism to support more mode-specific data?�Some fields in MDS today, such as parking_verification_url, may only be relevant in micromobilty. Conversely, there may be other mode-specific data fields we may want to add for new modes. Should we have a flexible, mode-specific trip_attributes or event_attributes field (similar to the proposed vehicle_attributes) to allow for these data elements to be appended where appropriate?

LEAVING FEEDBACK

Places to have discussions and leave feedback.

• Document - The Extending MDS to New Modes document
• Share suggested edits
• Discussion - #652 “Mode Specification Framework in MDS”
• General thoughts and detailed discussions

​

​