BoB - Swedish national Ticket Standard for Public Transport
The National Ticket Standard (BoB) is owned by the public transport sector in Sweden. BoB is financed by the owners of Samtrafiken and is maintained and developed at the request of the board of Samtrafiken. The development has been and still is a common effort performed in a cooperation called BoB-Tech. The BoB-Tech forum is open for anyone that wants to contribute. Changes to the standard is decided by a Change Advisory Board (CAB) with members from the owners of Samtrafiken.
The objective for the standard is to create possibilities for interoperability, not only in-between different ticketing systems but also between different components within a ticket system. The interoperability in-between ticketing systems creates possibilities for combined travels with several operators. The interoperability between components within a ticket system creates possibilities for both established and new actors, both service companies and equipment suppliers, to enter the market with components in a grander solution.
Architecture
The basic architecture of the different parts of a ticket system and it's BoB API's:
The Participant Metadata is in a National database maintained by Samtrafiken. This is a registry of all participant in the BoB community. To be able to communicate through BoB you need to be registered here with your public keys used to identify yourself to another participant. This is part of the security built into the standard.
A Token Publisher is an ID producer that provides IDs that comply to the BoB definition described in MTS7. These IDs are stored in a Proximity Integrated Circuit Card (PICC). When a traveller buys a journey then the right to travel is registered in the local ticketing system with a reference to the travellers ID. When the travellers wants to perform their journey they only have to show their ID and the right to travel will be found in the ticketing system. This produces new possibilities for a more flexible sales procedure and the ID can be stored in a form that is convenient to the traveller (e.g. in a phone or any other wearable accessory).
A Sales Channel can be one of many things such as a re-sellers system, an app, a ticketing vending machine or similar. This funcion is usually the travellers interface through which they buy their journey. In some cases these can also store or deliver a ticket distributed by the Local Back End Ticketing System.
The Local Back End Ticketing System, consisting of the Price & Product which stores data about prices and business rules, Ticket Engine which produces, stores and administers data on digital tickets and, in some cases, a module for On-demand Traffic booking.
The Validation/Inspection handles verification of travel rights. This is usually done through an app or different form of readers (validators) that can interpret BoB tickets or BoB IDs.
The BoB-standard is illustrated by the green boxes.
Other different colours in this picture, with exception of the Participant metadata, illustrates that they are stand-alone functions. They can be operated by one organisation only. However the standard makes it possible for different organisations to operate them. So the Token Publisher can be one organisation, the Sales Channel another and Validation/Inspection a third with a fourth being the one operating the Local Back End Ticketing System. Or any combination there of.
From a near-operation point of view, the public transport players can:
- validate all of their own tickets, including app tickets
- validate tickets sold by other playersthird parties
- sell other operators tickets and combine these with their own
From a technical point of view you can:
- modularize a traditional ticketing system
- maintain several different suppliers of modules
- have different organisations perform different tasks, e.g. sales or validation
Governance
Samtrafiken has the task to govern the BoB-standard and the cooperation created within the public transport sector for this purpose. The governance includes:
- specifications of MTB, Tickle, the BoB-architecture and API’s
- a database containing the BoB participants public keys called the Participant Meta Database
- technical support for the users of the BoB-standard
- support for those who want to implement the BoB-standard
- cooperation with the owners to improve and develop the BoB-standard
On the following pages you can find all information necessary to implement and verify the specifications and API’s needed to fulfil the objectives for the public transport sector.
Contact
For general questions, please contact
Johan Hammar, object owner Standards
For technical questions & contribution to the BoB-community, please contact
For support, please contact