Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
PD CEN TS 16614 — Public Transport Network and Timetable Exchange (NeTEx) Standard Series
Public Transport — Network and Timetable Exchange (NeTEx)
🚌 PD CEN TS 16614 is the British Standards Institution (BSI) Published Document implementing the European Technical Specification CEN/TS 16614. Its core purpose is to establish a unified, XML-based public transport network and timetable exchange format (NeTEx). Prepared by the UK technical committee EPL/278 “Intelligent transport systems” and classified under ICS 35.240.60 (application of IT in transport), the series enables interoperability across bus, metro, tram, ferry, and rail modes at three levels: network topology, scheduled timetables, and fares information — providing the data foundation for journey planning, fare clearing, multimodal integration, and real-time information services.
💡 The value of NeTEx lies in “model once, reuse many times”: a single network and timetable dataset can simultaneously serve journey-planning portals, mobile apps, multimodal planners, and fare/clearing systems, greatly cutting integration costs between operators and vendors.
1. Series Structure and Overall Framework 📌
The PD CEN TS 16614 series comprises 3 parts, each corresponding to one core view of the NeTEx data model: network topology, scheduled timetables, and fares. All three share a common reference model and transmission framework, together forming a complete public transport information exchange system.
| Part | Year | Title | Core Content |
|---|---|---|---|
| PD CEN/TS 16614-1 | 2014 | Public transport network topology exchange format | Defines the network topology model describing stops, lines, line sections, and operational routes |
| PD CEN/TS 16614-2 | 2014 | Public transport scheduled timetables exchange format | Defines the scheduled timetable model describing service journeys, stop times, and operating calendars |
| PD CEN/TS 16614-3 | 2016 | Public transport fares exchange format | Defines the fares data model describing fare products, charging rules, zones, and sales channels |
The series builds on a common exchange reference model, with each part extending the shared data elements and constraints. Transmission uses XML Schema to define the structure and validation rules of exchange files, so systems from different vendors can serialise and parse data against a common pattern.
⚠️ A CEN/TS is a provisional “Technical Specification”: CEN applies it for a limited period (initially three years) and then evaluates whether to convert it into a European Standard (EN). Always reference the current effective version of PD CEN TS 16614 and monitor subsequent amendments or re-issue.
2. Network Topology: The Part 1 Data Model 🗺️
Part 1 defines the topological structure of public transport networks at both physical and operational levels. The physical level describes infrastructure (stops, platforms, track infrastructure); the operational level describes the lines and line sections on which vehicles actually run. Key data entities include:
- Stop Point / Stop Place: locations where passengers board or alight, with spatial references (longitude/latitude, projected coordinates) and hierarchical stop aggregation.
- Line and Line Section: an abstract representation of an operating line connecting termini and linking the sequence of served stops.
- Route and operational direction: describes the specific path and direction a vehicle follows along a line, linking to the timetable part.
- Transport Mode: classification codes for bus, tram, metro, ferry, rail, etc., enabling multimodal data organisation.
Part 1 also states compatibility requirements with existing standards and recommendations (e.g., Transmodel, IFOPT, SIRI), ensuring the NeTEx data model remains consistent with the European public transport reference model for smooth mapping between systems.
3. Scheduled Timetables: The Part 2 Operational View 🕐
Part 2 defines the scheduled timetable exchange format, describing how public transport services are arranged over time — “which line, in which direction, stopping at which stops, at what times.”
| Data Entity | Description |
|---|---|
| Service Journey | A complete vehicle run, linked to a route, direction, and vehicle type |
| Stop Point in Journey | Arrival and departure time at each stop, and whether boarding/alighting is allowed |
| Operating Day | The set of dates on which a journey applies (e.g., weekdays, holidays, seasonal operation) |
| Frequency / Headway | Service interval and operating period for high-frequency services |
Timetable data is tightly coupled to network topology through references to routes and stops, supporting queries for “the complete journey sequence of a line on a given date” and interfacing with real-time information services (such as the SIRI series) to combine planned and dynamic data.
4. Fares Information: The Part 3 Ticketing View 🎫
Part 3 defines the fares exchange format, structuring complex ticketing rules into exchangeable data. Its content includes:
- Fare Product: descriptions and validity of single tickets, day/month passes, stored-value cards, and through-tickets.
- Fare Structure Element: expression of charging rules by distance, by zone, by time window, or by number of transfers.
- Fare Zone / Tariff Zone: the geographic areas, stop sets, or line sets to which a fare applies.
- Sales channel and payment means: ticket machines, counters, apps, prepaid cards, mobile payment, etc.
Published in 2016, Part 3 is an important complement to Parts 1 and 2, enabling NeTEx to cover the complete “network — timetable — fares” business chain and providing a common basis for multimodal fare calculation, cross-operator clearing, and open-data publishing.
✅ The three parts together form the complete NeTEx chain: topology says “where service runs,” timetables say “when it runs,” and fares say “how it is charged,” with cross-references binding them into one organic whole.
5. Application Scenarios and Implementation Notes 🛠️
- 🔍 Journey planning and multimodal transport: NeTEx data can feed journey-planning engines to compute bus—metro—rail interchange paths.
- 🔧 Fare clearing and open data: structured fare products and charging rules ease cross-operator clearing and open-data publication.
- 📊 Integration with real-time data: planned timetables can work with SIRI real-time interfaces to provide arrival predictions and delay alerts.
- 📋 Data quality and compliance: always reference the current BSI version, validate data against the XML Schema, and ensure consistency with the Transmodel reference model.
6. Frequently Asked Questions ❓
❓ Q: What is the relationship between NeTEx and Transmodel?
A: NeTEx is a concrete implementation of the Transmodel reference model at the data-exchange level; its data model remains consistent with Transmodel for easy mapping and integration between systems.
A: NeTEx is a concrete implementation of the Transmodel reference model at the data-exchange level; its data model remains consistent with Transmodel for easy mapping and integration between systems.
❓ Q: How does PD CEN TS 16614 differ from real-time information (SIRI)?
A: NeTEx targets planned data (network, timetables, fares) while SIRI targets real-time data (vehicle position, arrival predictions). They are complementary — planned data underpins real-time services.
A: NeTEx targets planned data (network, timetables, fares) while SIRI targets real-time data (vehicle position, arrival predictions). They are complementary — planned data underpins real-time services.
❓ Q: Can the three parts be used independently?
A: Yes. Each part can exchange its corresponding view independently, but complete multimodal and ticketing applications usually need all three, sharing the common reference model.
A: Yes. Each part can exchange its corresponding view independently, but complete multimodal and ticketing applications usually need all three, sharing the common reference model.
🔍 Q: Why is this series published as PD rather than an EN?
A: Because it is the UK implementation of a CEN/TS technical specification of provisional application, subject to evaluation before promotion; BSI adopts and publishes it as a Published Document.
A: Because it is the UK implementation of a CEN/TS technical specification of provisional application, subject to evaluation before promotion; BSI adopts and publishes it as a Published Document.