Discovering OSDM: A Comprehensive Guide to Understanding and Implementing Data Standards

9 minutes read
05 July 2024

The mobility of the future will face new challenges driven by a confluence of factors, necessitating innovative solutions. At the heart of this transformation are consumer needs, which will redefine the very concept of mobility.

In the rapidly evolving world of urban transportation, efficient and reliable systems are crucial for modern cities. When developing a MaaS application, data serves as a crucial asset. It is essential for facilitating interaction and exchange among various mobility stakeholders. This is where standardized data formats come into play.

In this article, we will introduce one of these standards for exchanging data in the Mobility and Transportation industry: the Open Sales and Distribution Model (OSDM). We will see its specifications, its benefits, the differences with other standards, and how it works.

Introduction to OSDM

In the evolving landscape of transit ticketing, efficiency, interoperability, and customer-centric approaches are paramount. The Open Sales and Distribution Model (OSDM) emerges as a transformative framework designed to standardize and streamline the complex processes of transportation booking and fulfillment. This model, backed by the International Union of Railways (UIC), facilitates seamless integration across various mobility service providers, enhancing the user experience and operational efficiency.

OSDM is a comprehensive specification that addresses the end-to-end processes involved in the sales and distribution of transit tickets. It replaces the legacy interfaces with a modern, unified system that caters to the needs of today’s digital economy. By offering standardized communication protocols and data formats, OSDM ensures compatibility and cooperation among different mobility operators and distribution channels.

Key Specifications of OSDM

Here are the main specifications that characterize OSDM:

  • Standardized Data Formats: OSDM utilizes standardized data formats based on JSON and XML, ensuring interoperability and ease of integration across various platforms.
  • Open APIs: The model supports a set of open APIs that facilitate the exchange of booking and ticketing information between different systems, allowing for real-time data sharing.
  • Modular Architecture: OSDM’s modular design allows for the flexible implementation of its components, enabling operators to adopt specific modules according to their needs.
  • Security and Compliance: The model includes robust security features to protect sensitive data and ensures compliance with international standards such as GDPR.
  • Extensibility: OSDM is designed to accommodate future enhancements and expansions, making it a future-proof solution for ticketing.

Benefits of OSDM

Why is OSDM important? Why should it be adopted? The main benefits it ensures are:

  • Enhanced Interoperability: OSDM’s standardized approach ensures that different operators and third-party distribution channels can seamlessly interact, providing a unified experience to customers.
  • Improved Efficiency: Automation of booking and ticketing processes reduces manual intervention, leading to faster and more accurate operations.
  • Better Customer Experience: With real-time information sharing and consistent data formats, customers enjoy a smoother and more reliable ticketing experience.
  • Cost Savings: By adopting a standardized model, mobility operators can significantly reduce the costs associated with maintaining multiple, disparate systems.
  • Future-Proofing: The extensibility of OSDM allows for easy adaptation to new technologies and market demands, ensuring long-term relevance.

Differences between GTFS, NeTEx, and OSDM

The Mobility and Transportation industry already has several standards for exchanging data. We dedicated a blog post and a website page to help you navigate between them.

In this paragraph, we will highlight the main differences between OSDM and two of the most important standards: GTFS and NeTEx.

  • OSDM: standard developed to unify and optimize transport ticket sales and distribution. It is ideal for standardizing the sale and distribution of transportation tickets internationally, improving interoperability between different companies.
  • GTFS: standard developed by Google to represent timetables and information about public transportation stops in an easy-to-handle format based on CSV files. Perfect for representing public transport timetables and stops in a simple and widely adopted format, useful for navigation and journey planning applications. It is mainly used in Google Maps to show this information to the users, and it can reused in other applications.
  • NeTEx: European standard developed by the European Committee for Standardization (CEN), for data exchange about public transportation. Since it is based on XML files, it is perfect for exchanging complex public transport data on a national or regional level, supporting a wide range of detailed and complex information.

OSDM

GTFS

NeTEx

Focus

Sale and distribution of train tickets

Public transport timetables and stops

Exchange of complex public transport data

Data Format

XML, JSON

CSV, GTFS-realtime

XML

Geographical Adoption

International

Global

Europe

Area of Use

Transit companies and sales platforms

Public transport agencies and navigation apps

Public transport agencies and national systems

Application Example

Sale of international tickets

Google Maps integration

Integrated national travel planning

Interoperability

High (between different transit companies)

Medium (local public transport)

High (between different transport agencies)

Actor Models in OSDM

In the OSDM standard, actors represent entities interacting with a subject through signals and data exchanges. Human users, external hardware, or other entities could be all actors. It’s important to note that an actor represents a role or facet of an entity relevant to its use cases, not necessarily a specific entity itself.

Following is a list of every Actor in the OSDM standard with a brief description of their capabilities:

  • Distributor: focused on creating and providing ticket content:
    • Manages the lifecycle of sold products (travel contracts);
    • Exchanges information with retailers, carriers, and TCOs;
    • Provides ticket fulfillment data (e.g. PDFs) and modifies ticket status;
  • Carrier: provides transport services, either directly or through a substitute:
    • Establishes a contract with the traveler;
    • Includes railway undertakings, bus companies, and maritime companies;
    • Owns fares unless managed by an intermediate fare provider;
  • Customer: purchases travel contracts for one or more travelers:
    • Entitled to receive refund payments;
  • Retailer: sells tickets provided and managed by the distributor to customers;
  • Fare Provider: manages fares on behalf of a carrier or a local transport authority;
  • Local Transport Authority: setups local transportation and defines fare structures for local transport, applied by all included carriers;
  • Passenger: the individual traveling under a travel contract:
    • The customer and passenger can be different individuals, such as a parent buying a ticket for a child;
  • Ticket Controller: responsible for checking tickets, either as train staff or automated machines:
    • Part of a Ticket Controlling Organization acting on behalf of the carrier.

Key Data Models in OSDM

The OSDM (Open Sales and Distribution Model) framework provides a representation of the data models underlying its API specifications to help understand the API and its concepts.

Different data models are at play, each describing a different aspect of the sales and distribution process.

The figure above highlights the key data models, which are:

Passengers: Represent passengers for whom offers are proposed. Attributes include birth date, disability status, and reductions.

Bookings: Represents bookings offers, with attributes like booking status, confirmation time limit, and prices.

Offers: Offers contain fare elements. Offers have a minimal price, service class, and flexibility, and usually a limited lifetime (e.g., 30 minutes).

Fulfillments: Fulfillments in OSDM represent the completion of booked offers, akin to traditional tickets. They serve as references for after-sales operations, linking to specific offer parts, and include identifiers like Ticket Control Numbers for tracking purposes. Additionally, they may contain links to documents or security features for managing fulfillment status.

Products: Represent the actual products offered, containing conditions and attributes.

Trips: Represents a trip from departure to destination. A trip consists of one or more tripLegs, which can be TimedLeg (public transport schedule), TransferLeg (links between legs), or ContinuousLeg (e.g., scooters, taxis). Trips can be in states like planned, confirmed, changed, or canceled.

Places: Represents specific locations in a trip, such as departure, origin, intermediate stop, or other. Types of places include Address, PointOfInterest, StopPlace, GeoCoordinate, and FareConnectionPoint.

Each data model also has a corresponding state model, which describes the status of the data object. For example, the status of a fulfillment object (e.g. tickets) can be one of the following: CONFIRMED, FULFILLED, REFUNDED, EXCHANGED, CHECKEDIN, where the state model of these statuses is as described below.

OSDM APIs

OSDM (Open Sales and Distribution Model) defines an API to enable and simplify the sale of transport products. The API allows retailers to access transport products provided by distributors. It also allows distributors to access transport product bricks provided by carriers or fare providers to build combined transport products. The aim of OSDM is to provide a simple API to access required information online; however, OSDM also provides an offline data exchange of fares.

OSDM with Mia-Platform

To rapidly adopt the OSDM standard, you need a component of the architecture that can convert the proprietary interfaces to ensure that every system can speak the same language as the standard proposed, instead of updating every single system.

Mia-Platform can become the architecture component that can take ownership of the conversion without duplicating the logic of translating formats in every system.

Thanks to Mia-Platform Marketplace, developers can access a range of pre-built or custom solutions to craft the conversion layer between various systems respecting the rules of the standard. Also, the Marketplace can make these components reusable across different business processes to avoid replicating code and maximize the time-to-market of new OSDM-ready interfaces.

Also thanks to the Integration Portal, companies can simplify the onboarding process of new developers and system integrators by providing them with clear documentation of every API available and allowing them to try them before adopting them into their business logic.

Conclusion

The Open Sales and Distribution Model (OSDM) is a groundbreaking initiative that brings much-needed standardization to transporation ticketing. By addressing the complexities of booking and fulfillment through a robust state model and a set of open, interoperable specifications, OSDM sets the stage for a more efficient, customer-centric, and future-ready transportation ecosystem. As mobility operators and technology providers continue to adopt this model, the benefits will extend beyond operational efficiencies to a more seamless and satisfying travel experience for passengers around the globe.

You can leverage Mia-Platform’s Suite capabilities to rapidly adopt the OSDM standard, giving developers a tool to accelerate the development of adapters and reuse them in every needed scenario, boosting the time-to-market of new features that are built around OSDM communications.

New call-to-action
Back to start ↑
TABLE OF CONTENT
Introduction to OSDM
Key Specifications of OSDM
Benefits of OSDM
Differences between GTFS, NeTEx, and OSDM
Actor Models in OSDM
Key Data Models in OSDM
OSDM APIs
OSDM with Mia-Platform
Conclusion