[Description] [Detailed presentation] [On-line consultation] [Download the documentation] [Glossary]


TRANSMODEL is a description of the data of interest to a company in designing an Integrated Information System.

TRANSMODEL is a conceptual model and does not mandate any particular implementation at the logical or physical level.

Therefore, TRANSMODEL can be implemented on several different platforms.

What are the requirements for such a reference data model :

TRANSMODEL increases the efficiency of transport operations by underpinning them with more secure and reliable Information Systems. TRANSMODEL is also expected to open the market by allowing integration of complementary software products from different suppliers.

The present version of TRANSMODEL (V5.0) uses an Entity-Relationship modelling approach and covers the following domains :

It mainly concerns bus operations.

TRANSMODEL is being developed by a European team within which various levels of end users are represented. It has been presented at many conferences and discussed within seminars open to transport and information modelling experts. It has received, and still receives feedback from a wide audience. It is continually evolving to incorporate a variety of new points of view.

TRANSMODEL is now on the path to becoming a European standard reference.


For More information concerning TRANSMODEL>>


© transmodel - 1999

[Description] [Detailed presentation] [On-line consultation] [Download the documentation] [Glossary]




SITP project

The document describing the reference data model for public transport has been prepared by the project SITP (Système d'Information Transport Public) sponsored by the French Ministry of Transport (Direction des Transports Terrestres - DTT) under the cooperation of the companies: · Gemplus (France), · Setec ITS (France), · Transmodel Users' Support Team EEIG (France & Germany).

SITP is a direct continuation of previous results obtained at European level. In particular, it is based on · the prestandard ENV 12896 (issued May 1997), · the results of the EC - project TITAN (1996-1998) · the remarks of the CEN TC278 WG3 experts.

SITP has produced the requested extensions of the ENV 12896 that have been validated by CEN experts in the period 1999-2000. The extensions have then been integrated with ENV 12896. The present document shows the final results of this process (see also informative Appendix: "Modifications to ENV 12896").

The prestandard ENV 12896

The prestandard ENV 12896 was prepared by the work area Transmodel of the EuroBus project (1992-1994) and by the DRIVE II task force Harpist (1995). The EuroBus/Transmodel and Harpist kernel team was considered as a subgroup of Working Group 3 of CEN TC278. The results of these projects were based upon earlier results reached within the Drive I Cassiope project and the ÖPNV data model for public transport, a German national standard. They have been approved by Topic Group 6 (TG6, entitled "Public Transport Data Models") of the EC Drive II programme and by two validation seminars open to participants in various Drive II projects, to European public transport operators and to other public transport experts. The prestandard reflected the contents of deliverable C1 of the HARPIST task force, published in May 1995, with modifications resulting from the discussion process in CEN TC278/WG3 between May and October 1995.

The different organisations that have technically contributed to the preparation of the prestandard ENV 12896 were the partners of EuroBus/Transmodel and the Harpist task force: Beachcroft Systems (UK), CETE-méditerranée (F), CTA Systems (NL), Ingénieur Conseil Bruno Bert (F), Koninklijk Nederlands Vervoer (NL), Leeds University (UK), Régie des Transports de Marseille (F), SNV Studiengesellschaft Verkehr (D), Stuttgarter Strassenbahnen AG (D), TransExpert (F), TransTeC (D), VSN Groep (NL). The sponsors of the project were: · European Communities (EC, DG XIII, F/5, Drive Programme, 1992-94), · French Ministry of Transportation, · Dutch Ministry of Transportation, · German Federal Ministry of Research and Technology.

Titan project results

The EC project Titan concerned validation and further development of ENV 12896. The main objectives of Titan can be summarised as follows: · to validate the existing kernel of ENV 12896 through its implementation in pilot demonstrations in Lyon (France), Hanover (Germany) & Salzburg (Austria) and to amend it if necessary; · to extend the kernel model to other domains of public transport operations; · to enlarge the contents of ENV 12896 according to the evolution of telematics and communication; · to disseminate the contents of ENV 12896 and the principles of the open and inter-operable information system architecture based on the ENV 12896; · to support the standardisation process regarding the ENV 12896; · to encourage the market penetration for the ENV 12896-based solutions.

The different organisations that have technically contributed to the Titan project were: CETE-méditerranée (F), üstra (D), OASA (GR), RATP (F), SLTC (F), Salzburger Stadtwerke AG (A), TransExpert (F), TransTeC (D), Synergy (GR), TRUST EEIG (D).

The sponsoring partner, was the French Ministry of Transport (DTT/SAE). The project was co-funded by the European Communities and some of the partners, in particular the pilot sites



2. Structure of the standard

The document describing the standard is composed of two parts:

The main document presents:

The normative appendix contains:

The informative appendix is composed of the following parts:



3. How to obtain a copy of the standard

The Reference Data Model For Public Transport, ENV12896 revised, june 2001 is available in the bibliography section as :

[CEN01] CEN TC278, Reference Data Model For Public Transport, ENV12896 revised, june 2001.



4. Rationale of the Data Modeling Approach

4.1 Rationale of the standard reference data model

4.2 Data modeling approach


4.1 Rationale of the standard reference data model

An efficient public transport (PT) operation and operations management, as well as attractive and accurate passenger information, are the main objectives sought by public transport companies. The solution to reach this goal goes through the integrated approach, i.e. the possibility of integrating more easily application systems developed by different suppliers into one system (interoperability). The need for the integration of systems and the benefit that emanates from the interoperability of applications were the starting points of the research in the field of data modelling for public transport.

The integrated approach enables, for instance, a reliable exchange of information between different software products. This approach has at the same time to allow the choice of the most adapted software for each company, without being bound to one single supplier. The experience shows, however, that software products of different suppliers are often incompatible or difficult to integrate. The operators and authorities are therefore either forced to run several products separately, or to rely on one specific supplier and its range of products, that may not be well adapted as a whole to a given company.

The standard presented in this document is dedicated to provide a solution to operators, authorities and software suppliers that now want to proceed towards an integrated system. Its aim is also to be a support for future developments.

The standard is a conceptual data model, reference data model for public transport, that provides a sound architectural framework for understanding the information needs of a PT company and for constructing an integrated information system to service end users with the information.



4.2 Data modeling approach
Information architecture

An information architecture refers to the interfaces between different components of a system that enable these components to operate together. It provides a means by which the end user can access information easily and efficiently, often across complex networks made up of many different computers and software products (operating systems, database systems, application systems, etc.).

Setting up an information architecture requires careful planning and must be based on a thorough analysis and modelling of business needs. One of the goals of model-based development is the construction of software models that represent the structure and operations of a business, so that a range of solutions to problems can be investigated before getting committed to a particular implementation. The reference data model presented in the main document is one such model and is particularly suitable for designing databases and interfaces with applications.

A PT company may have one set of data in a central or distributed database, based on the reference data model, to be used by all applications. Applications may use standard interface tools provided with a DBMS (database management system) to provide direct access to the database. Alternatively, applications may continue to use their own databases, but exchange data via the database using specially written interfaces. In both cases, the reference data model can be used to design the interfaces.

A well planned information architecture offers many benefits to a PT company over and above better understanding and access to its valuable information resources.

It can be an open architecture. Hardware and software products from different suppliers can be successfully mixed. The PT company has more choice and is no longer locked into one computer supplier to have any chance of integrating modules serving different functions within the company. Bridges can be built between separate islands of information. Information produced in one area of the company and needed in other areas does not have to rely on error prone, time consuming and costly manual transfers. Incompatibilities between subsystems can be addressed.

Incompatibilities over time can be tackled in the same way. Inevitably, in periods of rapid change, hardware and software becomes obsolete and needs replacing, but not necessarily at the same time. Well defined interfaces can obviate the need for rewriting software whenever hardware upgrades are introduced, and vice versa. An extensible information architecture makes it possible for the PT company to cope with changing requirements and technological advances, without premature phasing out of past investments.

Applications need no longer be dependent on one specific operating system or hardware platform. An application can be moved to another common platform without requiring costly adaptations each time the company updates its physical and operating system infrastructure. Portability of tools is a key component of an information architecture.

Role of the reference data model

The interface between an application system and a database based on the reference data model will isolate the application from the actual storage method and location of the data. The latter can be changed without disrupting the working of the application. Implementing the reference data model with a powerful database management system will make available a collection of integrated tools to provide transparent access to data. In other words, the end user can concentrate on the task s(he) has to perform without concern for the mechanics of data access. Popular word-processing and spreadsheet software can be interfaced to the database to support this end user analysis of data.

An information architecture made up of independent modules with well defined interfaces is easier to maintain. A malfunctioning module can be taken out of service or completely replaced without disrupting the rest of the system. This is particularly beneficial for on-line or safety critical systems. The modules can also be more easily reconfigured on to hardware located elsewhere on the network to fit in with changes in organisational arrangements for managing the business and data administration processes. Training staff to manage modular systems is easier than for huge monolithic packages where faults are hard to contain and quickly propagate to other parts of the system. Modularity reduces the complexity of a system and makes it easier to understand.

The information architecture itself must be evaluated from time to time to make sure that it is still meeting the needs of the company. Technological changes in communications and computing are continuously bringing forward new opportunities for evolving the systems supporting the business. An information architecture may itself require upgrading, but one of its benefits is the fact that it forms a firm basis on which to effect that change. Unplanned and piecemeal computer systems that do not work together as a coherent whole have become almost impossible to adapt to these new opportunities.

A company that has successfully established an information architecture can much more readily interface with external systems providing (or supplying) information about the environment in which the business operates.

Constructing complex user-friendly software systems that genuinely help to support management decision making is a very difficult and costly exercise and not practical to undertake for individual companies. Economies of scale can be realised if the framework or information architecture embodies some standards that transcend the requirements of any one company. This will help suppliers of software by increasing the size of their market. It will also benefit the PT companies because they will be able to acquire and install modules tested elsewhere and share the development costs.


5. An Overview of the Data Model

The European reference data model for public transport is an offer to public transport companies and other providers of services related to the process of passenger transportation and information, to suppliers of software products supporting these processes, and to consultants and other experts acting in the field of public transport in the widest sense.

The reference data model can support the development of software applications, their interaction or combination in an integrated information system, and the systems organisation and information management which rules the utilisation of the existing telematics environment in a company (or group of companies) running computer applications supporting various different functional areas of public transport.

Although primarily designed to document the information needs of a public transport company in a well defined and structured way, the reference data model can also serve as a starting point and reference for the definition of a database schema needed for the physical implementation of data storage systems to be used by applications directly, or for exchange of data between applications via interfaces. Apart from that, such a database will often additionally be used as a source of information for the company management and/or as an information pool for all employees who may need access to the information basis of the company.

The data model describes elementary data needed for:

5.1 Network description

5.2 Versions management

that are used in several functional domains as basic concepts.

The data model describes the information needs related to the following functional domains:

5.3 Tactical planning (vehicle scheduling, driver scheduling, rostering),

5.4 Personnel (driver) disposition,

5.5 Operations monitoring and control,

5.6 Passenger information,

5.7 Fare collection,

5.8 Management information and statistics.

The standard takes into account the:

5.9 Multi-modal public transport operation,

5.10 Multiple operators environment.


5.1 Network description

The reference data model includes entity definitions for different types of points and links as the building elements of the topological network. Stop points, timing points and route points, for instance, reflect the different roles one point may have in the network definition: whether it is used for the definition of (topological or geographical) routes, as a point served by vehicles when operating on a line, or as a location against which timing information like departure or passing times, or wait times, is stored, in order to construct the timetables.

The line network is the fundamental infrastructure for the service offer, to be provided in form of vehicle journeys which passengers may use for their trips. The main entities describing the line network in the reference data model are the line, the route and the journey pattern, which refer to the concepts of an identified service offer to the public, the possible variants of itineraries vehicles would follow when serving the line, and the (possibly different) successions of stop points served by the vehicles when operating on the route.

The functional views of the network are described as layers. A projection is a mechanism enabling the description of the correspondence between the different layers. This mapping between the layers is particularly useful when spatial data from different environments (sources, functional domains) have to be combined. An example of such a situation is the mapping of the public transport network on the road network.

The Geographical Data Files (GDF) standard includes a data model for the geographical description of road networks. It provides a basic network description upon which various layers describing specific aspects of the use of the infrastructure network may be placed. Public transport companies or providers of other associated services may want to couple their applications and information basis to geographical information. In this case, the exchange of data between a Geographical Information System and the public transport applications concerned will become necessary. For this purpose, an interface between the GDF data model and the relevant part of the topological network representation in the reference data model for public transport has been defined.



5.2 Versions, validity and layers

This part of the standard describes a way to handle data versions, i.e. data modifications, such as modifications of the planned service.

A mechanism to handle parallel hierarchies of elementary data groups (e.g. schedules) and the way to represent relationships between the different hierarchy levels is described, using the concept of validity conditions.

This part of the model shall be considered as a user guide for system design.



5.3 Tactical planning: Vehicle-Driver Scheduling and Rostering

The tactical planning (or scheduling) domain of the reference data model describes all the information that is necessary to define the vehicle journeys to be provided as a part of the public transport service, and to schedule (logical) vehicles and drivers to work the blocks and duties necessary to provide the defined service offer to the passengers.

The work of the vehicles necessary to provide the service offer advertised to the public consists of service journeys and dead runs (unproductive journeys necessary to transfer vehicles where they are needed, mainly from the depot into service and vice versa). Vehicle journeys are defined for day types rather than individual operating days. A day type is a classification of all operating days for which the same service offer has been planned. The whole tactical planning process is seen on the level of day types in the reference data model, with all entities necessary to develop schedules. These include a series of entities describing different types of run times and wait times, scheduled interchanges, turnaround times etc.

Chaining vehicle journeys into blocks of vehicle operations, and cutting driver duties from the vehicle blocks, are parts of the main functions of vehicle scheduling and driver scheduling, respectively. The corresponding entities and relationships included in the reference data model allow a comprehensive description of the data needs associated with this functionality, independently of the particular methods and algorithms applied by the different software systems.

The process of ordering driver duties into sequences in order to obtain a balanced work share among the driving personnel over the planning period, and to keep the resulting work time in harmonisation with legal regulations and internal agreements between drivers and the company management, is known as rostering. The reference data model offers a model part covering the information needs associated with some widely used, classical rostering methods in European countries. There may, however, be other (particularly more advanced, dynamic) methods applied in some cases, which would probably need additional, or other entities than described in the rostering part of the reference data model. This part of the model is therefore informative.



5.4 Personnel disposition

The personnel disposition domain of the reference data model covers the data needs of the relevant driver management functions with respect to the two major tasks of

The assignment of drivers for the actual operating day to the duty plan set up for the whole planning period is usually done in a staged procedure. The assignment will mostly start from a default assignments for the whole period in question, which can be continuously overridden by changes and adjustments due to regular absences of drivers from work, changes initiated by drivers according to their preferences or by the control staff according to operational needs. Short-term adjustments may become necessary to balance unplanned absences and other circumstances principally not known in advance.

Records to document the actual driver activities are usually taken to control the driver performance and compare it with the original plan, and to prepare these data in a suitable way for wage accounting. This mainly refers to the specification of the time worked by each driver on the individual day for each type of activity, and some additional classifications which may result in appropriate modifications of the amount to be paid for the recorded activity in question.

This part of the model is informative.



5.5 Operations monitoring and control

The domain of operations monitoring and control concerns all activities related to the actual transportation process. It is also known as real-time control, or operations management.

The supply basis for each operating day is known as a production plan, composed of the planned work of each available resource (e.g. vehicles and drivers). It includes for instance all dated journeys planned on the considered day, including occasional services.

The transportation control process supposes a frequent detection of the operating resources (in particular vehicle identification and location tracking). Such collected information is compared to the planned data (e.g. work plan for a vehicle or a driver), thus providing a monitoring of these resources.

The monitored data is used for:

Other aspects, such as communication between actors, are taken into account.



5.6 Passenger information

In its passenger information model part, the reference data model does not only describe the data which are needed for applications providing passengers with the relevant information on the planned as well as on the actual service, but also the data resulting from the planning and control processes which may result in service modifications possibly to be made known to the public. Consequently, the passenger information data model includes data descriptions which go far beyond the planned timetable, which is the main source for the classical timetable information, but does not take into account any dynamic issues.

These additional concepts refer to

Basically, all types of passenger information generally use many elements of the topological network definition, the lines and journeys which form the service offer, the definition of run and wait times, and other fundamental definitions. Geographical information may possibly be provided in some cases, if corresponding application systems are available. Specific types of passenger queries may be related to fares, where the relevant information elements are included in the fare collection sub-model of the reference data model.

Thus, the information basis for passenger information systems is widely spread over the whole reference data model, and the genuine passenger information data model covers only those elements which cannot be derived from, and are not explicitly included in other parts of the model.



5.7 Fare collection

The fare collection data model aims at a most generic description of the data objects and elements needed to support functions like definition of the fare structure and its parameters, operating sales, validating the consumption and charging customers. These functions and their underlying data structures are handled differently between European countries, and even between the public transport operators within one country. This situation leads to a considerable complexity of the concepts to be taken into account in the attempt to define one single fare collection data model, which aims at covering as many existing solutions and practices as possible.

In order to cope with this complexity, the fare collection data model concentrates on the abstract, generic concepts that form the core of any fare system, independently of how these abstract concepts are implemented by a set of concrete fare products (e.g. tickets or passes) offered for sale to the public. The starting point for the description of these fundamental concepts is the definition of theoretical access rights. These can be combined to immaterial fare products, which are linked to travel documents in order to form sales packages to be sold to passengers. Controls may be applied to these travel documents to validate the utilisation of the public transport system. Prices components are linked to the access rights, fare products and sales packages; they are used to calculate the price to be paid by a customer for a specific consumption (e.g. sale on a vending machine, debiting a value card, post-payment).



5.8 Management information

The data model part supporting management information and statistics provides some additional data descriptions which may be needed apart from the information elements already included in the scheduling, operations management and control, passenger information and fare collection sub-models. Statistical information may of course be provided for any object of interest that is included in the company's specific data model and for which information is recorded in a database, whether for the company management or for other organisational units.

However, some additional information needs and sources are necessary, which cannot be derived from the model parts mentioned above and are specifically related to the evaluation of the operational process, especially to the evaluation of the current timetable and the comparison between the scheduled performance and actual performance. These include:



5.9 Multi-modal operation

The multi-modal public transport domain is the co-operation of different public transport modes. The present standard addresses the needs of the following public transport modes:

Specific requirements of other transport modes are taken into account whenever possible.

The most significant needs addressed by the data model are dealing with

Numerous aspects of multi-modal operation refer to general data structures developed in the other parts of the present standard. They are recalled therefore with the reference to the corresponding data model part. However, specific characteristics, such as restrictions (in meeting or overtaking) or vehicle coupling for rail operation, are detailed in this section.



5.10 Multiple operators' environment

The standard takes into account the situation where several operators are present in one geographical area. This leads to solve problems related to the management of the different responsibilities for resources and services, between authorities and operators (and their organisational units). Problems related to the provision of information to passengers when the timetable data comes from different sources are also solved (merged timetables). The problem of interchanges in this situation is also described.

As regards the fare collection aspects, the reference data model for fare collection is developed in the way to associate data from different operators, using various transport modes or even providing other services. It is therefore designed to meet requirements of an integrated fare collection system.



6. Transmodel Current Status

6.1 Standardisation Issues

6.2. Transmodel-Based Implementations

6.3. Data Model Extensions

6.4. Expected Impact and Benefits

6.5 The Data Model Management Group



6.1 Standardisation Issues

By the end of 1995 Transmodel V.4 was mature enough to be presented as a pre-standard to the CEN Technical Committee 278 Working Group 3 (Public Transport). A range of comments expressed by this group has been taken into account and version 4.1 of the Reference Data Model for Public Transport has been published by the CEN in 1996 and accepted as an experimental standard ENV 12896 in August 1997.

Several further remarks have then been considered within the project team SITP, discussed within CEN TC 278 WG3 and the revised version of the ENV 12896 has been published by June 2001. This version is also known as Transmodel V5.



6.2. Transmodel-Based Implementations

Within the Telematics Applications Programme of DGXIII (1996-1998), the project TITAN aimed at full scale implementations of Transmodel V.4.1 - based information systems in Lyon (France), Hanover (Germany) and in Salzburg (Austria).
The figure below illustrates the general concept of a Transmodel-based implementation. The applications dedicated to the different domains (scheduling, passenger information, management information, automatic vehicle monitoring, personnel disposition and fare collection) are exchanging data through the Transmodel - compliant data base.

As regards the functional requirements in the case of TITAN sites, Lyon and Hanover have implemented applications that concern the domains :

The Salzburg site experimented the integration of the domains:

One of the objectives of the pilot implementations has been to establish the company specific Transmodel-based conceptual model that wouldtake into account company-specific rules and to prepare the conditions for its successful evolution and maintenance in the future. Transmodel has played here the role of a solid and well defined reference basis against which possible differences and adaptations could be expressed.
The reference data base schema contains at least all the data that are exchanged between the different application systems and is based on a logical data model, derived from Transmodel.



6.3. Data Model Extensions

Simultaneously to the standardisation process and to the pilot implementations, the conceptual work on further extensions of Transmodel V4.1 to cover new domains has been continued. New operational domains are considered, in particular :

The data model refinements resulting from the pilot implementations and extensions have been intergared into Transmodel V.5, elaborated by the end 2000 and documented in June 2001.



6.4. Expected Impact and Benefits

The dissemination and the discussion of Transmodel at European level and the Transmodel-based implementations, aim at the validation of the data model as regards its adequacy to comply with the needs of the operators throughout Europe.
In particular, the operators involved in TITAN have demonstrated through the implementation and documentation of their integrated information systems how they follow the strategic plans of their companies aiming at

It is expected that a better knowledge of Transmodel and its use as a basis for real size implementations shall widen its global acceptance by public transport organisations who shall see the usefulness of the approach becoming more tangible through the field demonstrations.



6.5 The Data Model Management Group

In order to manage data model evolution, dissemination and to assist public transport operators in Transmodel-based implementations, Transmodel Users Support Team (TRUST) has been created. This European Economic Interest Group is in charge of ·

data model administration,

information dissemination,

data model promotion and

technical support to companies involved in implementation of information systems based on the reference data model for public transport.

TRUST is acting as the kernel team of the European Data Management Group, federating European expertise in the field of data modelling for public transport.



contacts: For more information concerning Transmodel



© transmodel - 2001