Sponsoring partner: French Ministry of Transport (DTT/SAE)

Telematics Application Programme, sponsored by the European Union (EC DG XIII) Transmodel Based Integration of Transport Applications and Normalisation Contents of the TITAN Project The project TITAN concerns validation and further development of the European Reference data model for Public Transport operations (Transmodel), which was designed with the support of the European Union during previous research and development programs. The main objectives of TITAN can be summarised as follows: - to validate the existing kernel of Transmodel through its implementation in pilot demonstration, and to amend it if necessary; - to extend the kernel model to other domains of Public Transport operations; - to enlarge the contents of Transmodel according to the evolution of telematics and communication; - to disseminate the contents of Transmodel (conceptual data model) and the principles of the open and inter-operable Transmodel architecture; - to support the standardisation process regarding Transmodel; - to encourage a dynamic market penetration for Transmodel-based solutions. TITAN Partners TITAN 1: Project co-ordinator: SMM/ISIS (F); Partners: üstra (D), OASA (GR), RATP (F), SLTC (F), Salzburger Stadtwerke AG (A), TransExpert (F) - Project manager, TransTeC (D), Synergy (GR). TITAN 2: TRUST EEIG (D) Sponsoring partner: French Ministry of Transport (DTT/SAE) Project co-ordinator: SMM (Jacques Tribout): Phone: 33 4-91-23-25-26, Fax: 33 4-91-23-25-00, e-mail: dg/com-smm@dial.oleane.com Project manager: TransExpert (Kasia Bouree): Phone: 33 442-38-18-67, Fax: 33-442-38-18-73, e-mail: kbouree@pacwan.mm-soft.fr

2 Deliverable 6.1. Transmodel Based Integration of Transport Applications and Normalisation Telematics Application Project n TR 1058 (TR) Description of Pilot Site Implementations Deliverable 6.1. (Version 1.1) Authors and Contributors Work package 6 Distribution level : PU Nature : report Contractual delivery date : August 1997 Actual delivery date : September 1997 This report has been prepared by Dirk BLEIDORN (TransTeC), based on internal TITAN reports prepared by the pilot test sites: Bruno BERT and Olivier Brévaux (SLTC, Lyon), Dirk BLEIDORN and Lutz STAUB (TransTeC), Torsten LEHMANN and Georg EBBING (üstra, Hanover), Roland BERNER and Wilfried PFITZER (SSTW, Salzburg). A peer review was realised by Hans-Joachim Kreutzkamm (GVC, Hamburg (D)) and Andrew Blackburn (St.Herblain (F)). Abstract Keywords Editor The TITAN/1 project concerns validation and further development of Transmodel, the European Reference Data Model for public transport. Demonstrators are implemented in three pilot sites, aiming at the integration of different software applications by means of a relational database defined in accordance with the Transmodel principles and architecture. This report summarises the descriptions of the implementation of the demonstrator of the Transmodel based information systems at the three pilot test sites. It focuses on the presentation of the physical architecture and the communication architecture of the demonstrators and gives a brief outline of the implementation plan followed by the three pilot sites. Database management system, hardware, network, implementation, information management, data modelling, conceptual data model, logical data model, optimized data model, Transmodel, public transport operators. This report is distributed by SMM. 19/09/97 Project n TR 1058 Public Document

Deliverable 6.1. 3 Table of Contents EXECUTIVE SUMMARY... 7 1. INTRODUCTION... 8 1.1. TRANSMODEL AND TITAN...8 1.2. IMPLEMENTATION OF DEMONSTRATORS IN PILOT SITES...8 1.3. OBJECTIVES OF THE REPORT...8 1.4. OVERVIEW OF THE DEMONSTRATORS TO BE REALISED...10 1.4.1. General Remarks...10 1.4.2. The Demonstrator at the Pilot Site üstra (Hanover)...10...10 1.4.2.2. Objective of the TITAN Implementation at üstra...11 1.4.2.3. Functional Areas Considered...12 1.4.2.4. Application Systems Comprised...12 1.4.2.5. Architecture of the Integrated Information System...13 1.4.3. The Demonstrator at the Pilot Site Salzburger Stadtwerke...16 1.4.3.1. The Salzburg Pilot Site...16 1.4.3.2. Objective of the TITAN implementation at Salzburger Stadtwerke...16 1.4.3.3. Considered functional areas...17 1.4.3.4. Comprised application systems...17 1.4.3.5. Architecture of the Integrated Information System...17 1.4.4. The Demonstrator at the Pilot Site SLTC (Lyon)...18 1.4.4.1. The Lyon Pilot Site...18 1.4.4.2. Objectives of the Project...19 1.4.4.3. Considered Functional Areas...20 1.4.4.4. Related Software Applications...21 1.4.4.5. Info Centre...22 1.4.4.6. General Architecture...23 1.5. STATUS OF THE WORK IN THE PILOT SITES...24 1.5.1. Status of the Work in the Pilot Site üstra...24 1.5.2. Status of the Work in the Pilot Site Salzburger Stadtwerke...25 1.5.3. Status of the Work in the Pilot Site SLTC...25 2. PHYSICAL ARCHITECTURE OF THE DEMONSTRATORS...27 2.1. GENERAL PRINCIPLES AND DESCRIPTIONS...27 2.1.1. Common Approach for the Physical Architecture...27 2.1.2. Principles of Optimization...28 2.1.3. Database Objects...28 2.2. PHYSICAL ARCHITECTURE OF THE DEMONSTRATOR AT ÜSTRA...30 2.2.1. Hardware Platforms...30 2.2.2. Software Applications and Interfaces...32 2.2.2.1. The Database...32 2.2.2.2. Access Control...32 2.2.2.3. The Interfaces between the Application Systems and the TITAN-Database...33 2.2.3. Database Schemas...34 2.2.3.1. The Different User Schemas in the Database...34 2.2.3.2. The Optimized Logical Data Model...36 2.2.3.3. The Physical Database Schema...37 Public document Project n TR 1058 19/09/97

4 Deliverable 6.1. 2.3. PHYSICAL ARCHITECTURE OF THE DEMONSTRATOR AT SALZBURGER STADTWERKE...39 2.3.1. Hardware Platforms... 39 2.3.2. Software Applications and Interfaces... 40 2.3.2.1. The Database...41 2.3.2.2. Existing Applications...41 2.3.2.3. Types of Interfaces and Data Access...41 2.3.2.4. Database Application...42 2.3.2.5. Access Control...42 2.3.3. Database Schemas... 43 2.3.3.1. Different User Schemas...43 2.3.3.2. The Optimized Logical Data Model...43 2.3.3.3. Physical Database Structure...44 2.4. PHYSICAL ARCHITECTURE OF THE DEMONSTRATOR AT SLTC...44 2.4.1. Hardware Platforms... 44 2.4.1.1. Servers...45 2.4.1.2. Client Units...46 2.4.2. Software Applications and Interfaces... 47 2.4.2.1. Software Applications...47 2.4.2.2. Types of Interfaces...48 2.4.2.3. Access Control...48 2.4.3. Database Schemas... 50 2.4.3.1. Database structure at SLTC...50 2.4.3.2. Types of Data...50 2.4.3.3. Optimisations Realised on the Logical Model...51 2.4.3.4. Physical Structure of the Database...52 3. COMMUNICATION ARCHITECTURE OF THE DEMONSTRATORS... 54 3.1. PRINCIPLES OF INTEGRATION...54 3.2. COMMUNICATION ARCHITECTURE OF THE DEMONSTRATOR AT ÜSTRA...55 3.2.1. Networking Concepts... 55 3.2.1.1. Communication Layers between the Interfaced Applications and the Database...55 3.2.1.2. Networking Organisation...55 3.2.1.2.1. General Rules for Management of the Networking...55 3.2.1.2.2. Management of the Interfaced Components...56 3.2.1.3. Network Architecture...57 3.2.2. Data Transfer Processes... 59 3.3. COMMUNICATION ARCHITECTURE OF THE DEMONSTRATOR AT STADTWERKE SALZBURG...62 3.3.1. Networks... 62 3.3.2. Data Transfer Processes... 62 3.4. COMMUNICATION ARCHITECTURE OF THE DEMONSTRATOR AT SLTC...66 3.4.1. Networking Concepts... 66 3.4.1.1. Management of Interfaced Components...66 3.4.1.2. Physical Network...67 3.4.2. Data Transfer Processes... 69 4. IMPLEMENTATION PLAN... 71 4.1. IMPLEMENTATION PLAN AT ÜSTRA...71 4.1.1. Installation of the Database... 71 4.1.2. Implementation of the Interfaces... 71 4.1.3. Data Conversion and Entering... 72 4.1.4. Database Evolution... 72 4.1.5. Accompanying Measures... 73 4.2. IMPLEMENTATION PLAN AT SALZBURGER STADTWERKE...73 19/09/97 Project n TR 1058 Public Document

Deliverable 6.1. 5 4.2.1. Installation of the database...73 4.2.2. Implementation of the Interfaces...73 4.2.3. Data Entry and Conversion...74 4.2.4. Database Evolution...74 4.2.5. Accompanying Measures...76 4.3. IMPLEMENTATION PLAN AT SLTC...76 4.3.1. Database Creation...76 4.3.2. Database Optimisation...77 4.3.3. Data Conversion and Entering...78 4.3.4. Database Evolution...78 4.3.5. Accompanying Measures...79 5. CONCLUSION...80 BIBLIOGRAPHY...81 LIST OF ABBREVIATIONS...82 Public document Project n TR 1058 19/09/97

6 Deliverable 6.1. List of Figures Figure 1: Overview of the Covered Functional Areas 10 Figure 2: Functional Areas & Applications 13 Figure 3: Architecture of the Integrated Information System at üstra 15 Figure 4: Integrated Transportation Database in Salzburg 18 Figure 5: Main Aspects of the Lyon Information System 22 Figure 6: The Common Physical Architecture Approach 27 Figure 7: General Hardware Architecture, Connection of Servers 31 Figure 8: User Access Control 33 Figure 9: Interfaces & Applications 34 Figure 10: Distribution of Database Tablespaces and Files 38 Figure 11: Hardware Components for Installation of the TITAN Demonstrator 40 Figure 12: Architecture of the Hardware at SLTC 46 Figure 13: The Physical Database Architecture 53 Figure 14: Level 1 Cable Connections 58 Figure 15: Level 1 and Level 2 Cable 58 Figure 16: Data Import Process of the TITAN Database 61 Figure 17: Data Transfer between the GIS and the Public Transport Applications 63 Figure 18: Data Transfer between the City Department of Works and the City Authorities 65 Figure 19: Data Transfer between the City Department of Works and External Partners 66 Figure 20: First Level of the SLTC Network 67 Figure 21: Second Level of the SLTC Network 68 Figure 22: Possible future extensions of the TITAN demonstrator in Salzburg 75 19/09/97 Project n TR 1058 Public Document

Deliverable 6.1. 7 Executive Summary The TITAN/1 project concerns validation and further development of Transmodel, the European Reference Data Model for public transport. Demonstrators are implemented in three pilot sites, aiming at the integration of different software applications by means of a relational database defined in accordance with the Transmodel principles and architecture. Three pilot sites are currently developing integrated solutions for their information management based on Transmodel. Two of them (üstra Hanover and SLTC Lyon) are public transport operators and the third site (Salzburger Stadtwerke) is a municipal enterprise which not only provides public transport services, but is also in charge of energy and water supply and maintaining the corresponding networks. This report summarises the descriptions of the implementation of the demonstrator of the Transmodel based information systems at the three pilot test sites. It focuses on the presentation of the physical architecture and the communication architecture of the demonstrators and gives a brief outline of the implementation plan followed by the three pilot sites. In the first chapter a short introduction to the TITAN project is presented together with the objectives of this deliverable, an overview of the three demonstrators and the status of the work. The second chapter presents the physical architecture of the demonstrators by describing the central databases, the interfaced applications, the interfaces and the various hardware platforms used by these components of the integrated system. The communication architecture is decribed in the third chapter. This description comprises the management of the interfaced components, the physical network and details of the data transfer process. The fourth chapter comprises the implementation plans of the three pilot sites. The focus is on implementation of the database and the interfaces as well as entry and conversion of the (test) data. The last chapter of this deliverable contains the conclusion for the implementation planned and in progress. Public document Project n TR 1058 19/09/97

8 Deliverable 6.1. 1. Introduction 1.1. Transmodel and TITAN Transmodel is a conceptual data model 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 they require to run their businesses. It was developed with support from the European Commission in the DRIVE II project "EUROBUS", and is now promoted for dissemination, standardisation and validation in the "TITAN" project of the Fourth Framework Programme. The TITAN/1 project part aims at the demonstration of the practical value of Transmodel for the implementation of integrated information systems coupling together applications produced by different software suppliers, by means of a central database for the exchange and dissemination of data between applications, and between business processes in general. This practical validation also aims to support the acceptance and market penetration of Transmodel, which would encourage the supplier industry to provide compatible products needed by the PT networks to facilitate the implementation of integrated information systems in the near future. 1.2. Implementation of Demonstrators in Pilot Sites Three pilot sites are currently developing integrated solutions for their information management based on Transmodel. Two of them (üstra Hanover and SLTC Lyon) are public transport operators, who mainly want to couple existing applications supporting various functional areas via a central database, in order to improve the data flows and to increase the quality of their information base. The third site (Salzburger Stadtwerke) is a municipal enterprise which not only provides public transport services, but is also in charge of energy and water supply and maintaining the corresponding networks. In this site, the realisation of the integrated system focuses on the connection of transport data with overall planning data used by the City authorities, and with a geographical information system used to represent the various networks. 1.3. Objectives of the Report This report aims at the documentation of general findings and detailed results of the implementation stage of the development process carried out in the three pilot sites. This stage comprises the implementation of the database and the interfaces as well as the 19/09/97 Project n TR 1058 Public Document

Deliverable 6.1. 9 modification of existing software packages 1, to be realised for the integrated information systems forming the TITAN demonstrators. The development of the demonstrators in the TITAN project will be documented according to the system architecture guidelines given by the CORD project [JESTY 1997]. These guidelines recommend to describe the architecture of a telematics application separately for the aspects of - the functional architecture, - the control architecture, - the information architecture, - the management architecture, - the physical architecture, and - the communication architecture. The functional architecture and the control architecture are not within the scope of the TITAN project, which aims at the integration of different existing applications (and thus an improved utilisation and more efficient use of the existing information base), rather than the develoment of completely new applications providing additional technical funtionality. These architectures are only briefly referred to in the description of functional areas covered by the demonstrators to be developed, but are not presented in detail. The information architecture and the management architecture are described extensively in the previous deliverable 5.1, with the main focus on the data models forming the core of the information architecture, based on the current version 4.1 of Transmodel, the European Reference Data Model for Public Transport [HARPIST 1996]. The physical architecture as well as the communication architecture are described in this deliverable 6.1. It should be stressed that the Transmodel approach does not mandate any particular choice as regards the physical implementation of information systems as described in the present Deliverable 6.1. It only proposes standard structures and methods to design the logical contents of the systems, which can be implemented in very various ways (on various platforms, using different database management systems, with different network architectures, etc.). Therefore, the reader should not expect from this Deliverable a comparative analysis between the choices made as regards the implementation in the three Titan pilot sites described in the coming sections. On the contrary, the aim of the report is to illustrate, domain by domain, how from a common approach different choices may have been made, each addressing specific requirements of the concerned site. Of course, many aspects are common to several or all sites, such as the choice of market standard products (e.g. server hardware, database management system and design tool, network protocols, etc.), but many differences appear, as regards the details of implementation, etc. This shows that the common Transmodel approach is compatible, as far as the implementation aspects are concerned, with a variety of site-specific requirements. The reader would benefit from consulting the previous project Deliverables (public documents mentioned in the bibliography). Most input of these reports is detailed in site-specific internal reports (not mentioned in the bibliography, available on request). 1 These modifications refer to functional enhancements rather than to the internal data structures of the applications concerned. Public document Project n TR 1058 19/09/97

10 Deliverable 6.1. 1.4. Overview of the Demonstrators to be Realised 1.4.1. General Remarks In the initial project plan it was intended that this deliverable 6.1 should present the intermediate results of the pilot sites (together with the previous deliverables 4.1 "Overall Requirements of the Pilots" and 5.1 "Description of Pilot Sites Specifications" about the pilot sites) at the end of the first contract before the applications are integrated to form the TITAN demonstrators. Since the initial plan was very optimistic concerning the work progress and some unforeseen problems (e.g. withdrawal of a pilot site and replacement by another pilot site) occured, it is too early to present final results of the implementations. At all three pilot sites the implementation is still in progress (see section 1.5. "Status of the Work in the Pilot Sites"), therefore this deliverable comprises the descriptions of finalised as well as unfinalised parts of the implementation. This implies that some parts may be changed till the implementation is finalised at all pilot sites. Before each demonstrator is presented in a condensed way in the next three sections, the following figure summarises the functional areas covered by Transmodel V.4.1.1 and the demonstrators at üstra, Salzburger Stadtwerke (SSTW) and SLTC. Functional Areas (FAs)FAs covered by Transmodel FAs covered at üstra FAs covered at SSTW FAs covered at SLTC Vehicle Scheduling covered covered covered covered Driver Scheduling covered covered future extension covered Personnel Disposition covered covered future extension covered Autom. Vehicle Monitoring covered covered covered Passenger Information covered covered partly covered partly covered Statistics/MIS covered covered covered covered Operational Analysis covered future extension covered Graphical Evaluations covered Transportation Planning covered Network & Service covered Definition Fare Collection covered future extension Manage Vehicles future extension Figure 1: Overview of the Covered Functional Areas 1.4.2. The Demonstrator at the Pilot Site üstra (Hanover) 1.4.2.1. The Hanover Pilot Site üstra 19/09/97 Project n TR 1058 Public Document

Deliverable 6.1. 11 The project TITAN, supported by the European Union, concerns validation and further development of the European Reference data model for Public Transport (Transmodel). For this purpose, the implementation of demonstrators in pilot sites is of central importance for the total project. During the implementation, deficiencies of the Transmodel-kernel may be discovered, and experiences from practical solutions can be used to enhance and refine the reference model. The feasibility and usefulness of Transmodel for practical realizations of an integrated information system will be validated. Also at each pilot site, which are typical kinds of PT operators, the needs of extensions of the Transmodel-kernel on other domains of PT operations are determined and transmitted to the model administrator to complete the Transmodel. The completion is a condition for the European standardization of Transmodel. The practical suitability of Transmodel will be demonstrated by the implementation. Through this, important guidelines and experiences will be collected. This will reduce costs and risks of further implementations and encourage dissemination of Transmodel. Additional support for dissemination is expected by standardization, because PT operators will take Transmodel into account for future call for tenders. üstra, supported by the subsidiary TransTeC, is responsible for implementation of a demonstrator at the pilot site in Hanover. üstra represent a large, multi-modal PT operator and operates 260 light rail vehicles and 200 busses at present. üstra is involved in the regional transport association, called GVH (Greater Hanover region transport). Miscellaneous, unlinked systems are used to support planning, monitoring and controlling of operations. These systems support data exchange only in an insufficient way, which results in needless costs. The creation of a Transmodel-based integrated information system is supposed to be a condition, to improve quality and efficiency of company operations. 1.4.2.2. Objective of the TITAN Implementation at üstra The main objectives of the implementation of the TITAN-database at üstra is to 1. simplify and improve the data exchange process between transport operation application systems, 2. increase the availability of data for several applications and users, 3. allow flexible data access and evaluations. Ad 1) Principally the TITAN-database will be developed to exchange long- or mediumterm planned data between the interfaced transport operation application systems. In addition some data from the operating day are stored also in the TITAN-database, i.e. missed interchanges and schedule deviations. Ad 2) Data saved in the TITAN-database should be available for each application and user, who needs the data for specific purposes any time. At present the data exchange procedure does not allow access on data at any time, because the data cannot be accessed from a database 2, and tapes or floppy disks are not available. The data of the different applications have to be brought together in an expensive process. After the realization of TITAN all data needed by interfaced applications and the MIS are centralized in the TITAN-database. 2 Except the duty and driver management data stored in the personnel disposition system application PERDIS. Public document Project n TR 1058 19/09/97

12 Deliverable 6.1. Ad 3) Data access should be more flexible than it is now. Standard software like MS- Excel, something like Business Objects or Oracle Discoverer/2000 or Intranetapplications will be used to access the data in the TITAN-database. For certain users only preformulated evaluations will be accessible while others are enabled to generate own statistics. 1.4.2.3. Functional Areas Considered In the TITAN-project at üstra several functional areas of transport operation are taken into consideration 3. For üstra the data exchange between the following functional areas is covered (numbers and names of corresponding functional areas of Transmodel are given in brackets (see Reference Data Model for Public Transport, Draft V.4.1, November 1995, Annex B4, Page 14-44) (For mapping to numbers of corresponding CORDsubfunctions see ATT System Architecture Developments: the Public Transport (PT) Area, Deliverable No AC 13 - PT 4, December 1994, Page 60-62)): Vehicle and driver scheduling: (Area 2: (Re-)Design the network; Area 5: Plan detailed journeys; Area 6: Schedule vehicle blocks; Area 7: Schedule driver duties; Area 8: Prepare driver rosters) Personal disposition (Area 9: Manage driving personnel) Automatic vehicle monitoring /AVM (Area 11: Perform and control the driving process) Passenger Information (Area 13: Provide passenger information on the planned services) - Display of passive information on actual service at important stations - Interactive passenger information on planned services - Publishing of timetables and timetable booklets - On-board stop announcements Statistics and MIS (Area 25: Manage statistical results) In the Passenger Information domain, Functional Area 14 (Provide passenger information on the actual service) will also be partly covered, as far as the data supply for the system providing information about actual departures (estimated passing times) at important stops is concerned. The timetable data needed for this system will be supplied by the central TITAN database. 1.4.2.4. Application Systems Comprised In the functional areas considered at üstra, several application systems are used (see Figure 2). At present they are either completely separated or linked only partly to each other. These systems were programmed by üstra and different suppliers. Most of these systems manage their data in their own file systems. Normally only primitive or especially programmed functions are provided for data export. Means of data import are 3 The term functional area is used in a functional way, not organizational. This means a functional area is a set of coherent operational functions, which is not necessarily assigned to one single organizational unit. This point of view minimises the influence of possible reorganizations in the PT area for the project results (temporal stability). This also enhances the transferability of the results to other sites with different organizational structure. 19/09/97 Project n TR 1058 Public Document

Deliverable 6.1. 13 either insufficient, or do not exist at all. The objective of the TITAN-project is to couple these systems to the TITAN database for the data exchange procedure. At present, the Automatic Vehicle Monitoring (AVM) system BON is being checked to determine if the existing system will be further used, if it will be upgraded to a current version of BON, or if it will be replaced by another AVM system. Since there is no current decision of the future AVM system, only a rough specification of the corresponding interface has been formulated. The specification will be completed when the decision process is finalised and the data requirements of the system will be analyzed. 4 The following table summarises information concerning about the application systems comprised. Functional Area Application Storage Application Description Vehicle + Driver Scheduling EPON File + DB Planning of timetables, journeys and duties. Personnel Disposition PERDIS DB Assignment of real drivers to planned duties Autom. Vehicle Monitoring BON (or other) File Typical AVM application Passenger Information MOBILE Appl. DB On-board stop announcements FGI-Z File Displays passive information on actual service at important stations RVAS (at GVH) File Publishing of timetables and booklets EFA File Interactive PI on planned services Statistics/MIS to be developed DB statistics applications Figure 2: Functional Areas & Applications 1.4.2.5. Architecture of the Integrated Information System Figure 3 illustrates the description that follows. The central component of the integrated information system is the TITAN database which contains the data structures for data exchange between the interfaced applications. The TITAN-database will run on a computer with DEC-Alpha processor. As database management system an ORACLE7 Server will be installed. The applications will connect to the TITAN-database by using their interface-program to export data from their application-specific database or files into the TITAN-database or vice versa. No application will work directly on the TITAN-database, they will process on their application specific database or files. An exception will be given by the statistical applications (MIS), because the evaluation of data will be performed directly on the TITAN-database. Generally, only the vehicle and driver scheduling application EPON will write planned data to the TITAN-database, since as planning tool it is the first part of the process chain at üstra. All other systems in the process chain, which will 4 üstra plans to make the decision in September 1997 and a demonstrator of the new AVM system will installed in October or November. So it will be possible to add the AVM-part to the TITAN demonstrator in the first quarter of 1998. Public document Project n TR 1058 19/09/97

14 Deliverable 6.1. be integrated and which use the same data, follow after EPON 5 in the logical working process. The AVM system will store selected real-time data (schedule deviations, missed interchanges) in the TITAN-database for statistical and quality management purposes. Real-time data will not be exchanged between the AVM system and passenger information by using the TITAN database. Instead, data will be delivered directly over the existing network. This is a stable and well tested procedure, so there will be no depedencies on the availability of the TITAN-database. The vehicle and driver scheduling program EPON delivers nearly all of the data which are used by other systems. Application specific data which are used in one and only one application other than EPON and which are not of common interest will neither be maintained in EPON nor stored in the TITAN-database. There are some data objects which will be additionally maintained in EPON and which requires expansions of the EPON-functionalities. As example the topological data are mentioned at this point. As result of the analysis phase, it has been shown, that under the given circumstances it is the most applicable method for üstra, to maintain the topologigical data within one and only one system (EPON). Since the standard version of EPON is not designed to maintain all possible components of the network topology (e.g. traffic lights, beacon points, etc.), appropriate extensions have to be integrated in EPON to fulfill the needs of other systems. Figure 3 represents the Architecture of the planned integrated information system. Only PERDIS (personnel disposition, ORACLE), MOBILE (passenger information, PROGRESS) and the new release of BON (AVM, ORACLE) (at present not in use at üstra but possibly in the near future) store their working data within a database management system. Regularly, the other applications use flat files to store their data. 5 The personal disposition system processes duties, planned by the vehicle and driver scheduling system. The AVM can only monitor vehicles driving on journey patterns planned by the vehicle and driver scheduling system, just as the the passenger information systems needs the planned arrival times from the vehicle and driver scheduling system. 19/09/97 Project n TR 1058 Public Document

Deliverable 6.1. 15 Scheduling Driver Management Automatic Vehicle Monitoring (AVM) Progr. Interf. Progr. Interf. Progr. Interf. Data EPON Data PERDIS Data BON On-board Stop Announcement Progr. Interf. Data MOBILE TITAN DB (Oracle) Statistical Evaluations Progr. MIS User- Interf. Progr. Interf. Progr. Interf. Progr. Interf. Data EFA Interactive Timetable Information Data FGI-Z Actual Departure Time Information Data RVAS Timetable Printing Figure 3: Architecture of the Integrated Information System at üstra Public document Project n TR 1058 19/09/97

16 Deliverable 6.1. 1.4.3. The Demonstrator at the Pilot Site Salzburger Stadtwerke 1.4.3.1. The Salzburg Pilot Site The Salzburger Stadtwerke AG (City Department of Works) is a compound enterprise owned by the City of Salzburg, consisting of the company departments Public Transport, Electricity supply, Gas, Water, and Heat supply. Central departments provide joint services, such as accountancy and administration of the computer systems and networks. Approx. 1500 employees contribute to the performance of the City Department of Works, 600 of which are working for the public transport branch. The public transport department operates the bus and the trolleybus network in the city of Salzburg and the surrounding region. The system is used by approx. 50 million passengers per year. To improve its market position and to increase the number of passengers, the City Department of Works aims at a better quality of the public transport supply and a higher level of passenger information. This objective is to be supported by the possibilities of a Geographical Information System (GIS) already installed at the City Department of Works, but without any public transport data and references before the start of the TITAN project. The decision to introduce a Geographical Information System (GIS) in the City Department of Works was a consequence of the strategic vision to develop a companywide data model as a basis of an integrated information management system, aiming at the construction and common utilisation of an extensive pool of information made up of customer and consumer data, data describing technical means and facilities, and data from the various commercial domains. 1.4.3.2. Objective of the TITAN implementation at Salzburger Stadtwerke The Transmodel-based implementation of a demonstrator in Salzburg aims at the realisation of an information system which couples information about the public transport network and timetable, and demographic and other structural and statistical data available from the city authorities, with geographical data maintained by the Geographical Information System. In particular, the planning of the public transport network and services needs to be put on an improved basis, using constantly updated empirical data describing the real transportation demand. Geographical and demographic data available at the City Department of Works and in the City authorities, are therefore necessary to improve the planning and decision process regarding the structure of the public transport network. This implies a strong involvement of the City authorities in the project work. The concept for the future information management at the Salzburg site starts from the objective to establish a connection between the various domains of information, up to now locked in the different computer applications working completely separated from each other, and to allow the exchange and dissemination of information across the borders of genuine computer systems and of company departments, and even to include other authorities in an integrated network of data communication. Transmodel is used as the reference for defining a central database as a communication platform, as far as the public transport domain is concerned. Additional structures have been implemented to cover geographical information and data needs for the traffic and transportation planning process. 19/09/97 Project n TR 1058 Public Document

Deliverable 6.1. 17 1.4.3.3. Considered functional areas The demonstrator of a Transmodel-based integrated system in Salzburg covers the functional domains of - transportation planning, - design of the PT network, - definition of the service offer, - vehicle and driver scheduling, - passenger information on the timetable, - run time and other operational analysis, - graphical and statistical evaluations. The exchange of information between programs, and the dissemination of information to end-users working in the various organisational units considered, will be realised by means of a central Oracle database, and corresponding interfaces allowing for data transmission between the database and the software applications in question. 1.4.3.4. Comprised application systems The demonstrator to be realised in Salzburg aims at the integration of data in one overall data management system. Types of data included in this integrated data management system do not only include data currently maintained within existing software applications, but also data files originating from various sources in different formats, which are collected from internal and external organisations and bodies by the authorities of the City of Salzburg. The following software applications will be integrated in the future information system: - the vehicle and driver scheduling system which also provides passenger information; - a run time analysis and passenger counting system; - the geographical information system; - a new database application supporting statistical evaluations. Apart from that, in the short-term or mid-term, the integration of a personnel disposition system and of an AVM system is possible. These systems are currently in the phase of test and introduction. A GDF-based interface allowing the exchange of geographical information between the GIS installed in Salzburg and external partners and sources or customers will also be integrated as a part of the demonstrator. The demographical and statistical data referring to the traffic planning domain will be integrated by agreed conventions of the corresponding data definitions and formats, rather than by integrating the applications which create these data, as these applications are out of the scope of the TITAN project partners from Salzburg. 1.4.3.5. Architecture of the Integrated Information System The following Figure 4 illustrates the generic architecture of the integrated system to be implemented in Salzburg. The functions and applications to be coupled to the central TITAN database are presented in rough terms of functional areas, together with the associated organisational units in charge of them and the intended structure of data flows to be realised in the future integrated system. Public document Project n TR 1058 19/09/97

18 Deliverable 6.1. Public Transport department City Department of Works Data Processing department City of Salzburg Scheduling Passenger Counting Run Time Analysis Passenger Information PT network timetable PT network Passenger load PT network, timetable Run times, Stop times Timetable Geographic Data TITAN database GDF interface GIS PT network Operational data Traffic Planning data Graphical representations Statistical evaluations Traffic Planning Demographical data Structural data Traffic Count data Road Accident data External Partners Figure 4: Integrated Transportation Database in Salzburg Regarding the physical realisation, the principle followed for the implementation of the demonstrator in Salzburg is to keep the changes of hard- and software and of organisational processes to the necessary minimum, as far as the "customers" of the system are concerned. This means, the data processing department in charge of maintaining the GIS and the central TITAN database acts as a service provider, and undertakes to introduce the new system components, whereas the local systems already in use in the Public Transport department and in the various departments of the City of Salzburg itself (e.g. the traffic planning unit) will as far as possible not be affected by the introduction of the demonstrator. The public transport applications and traffic planning processes will therefore further on be maintained on dedicated servers located at the premises of the corresponding organisational units. The department in charge of graphical data processing has introduced a new Unix server with a special version of the GIS ("SICAD Open") which uses an Oracle database for storing of the geographical information, and which holds a selected subset of all geographical data available at the City Department of Works. The TITAN database is implemented on the RDBMS installed on this new Unix server, together with the SICAD Open database. The organisational concept of the new information management system is based on the possibilities of an improved and automated data exchange between applications and departments via network, where the responsibilities for data acquisition and maintenance remains in the organisational units already in charge of running the corresponding applications today. 1.4.4. The Demonstrator at the Pilot Site SLTC (Lyon) 1.4.4.1. The Lyon Pilot Site 19/09/97 Project n TR 1058 Public Document

Deliverable 6.1. 19 The Lyon Pilot Site of the TITAN project concerns the PT network of the Greater Lyon area, operated by the Société Lyonnaise des Transports en Commun (SLTC). The demonstration in Lyon will consist of the implementation of a fully integrated information system on operations based on Transmodel V4.1. This system will relate a range of applications with a database, to be implemented in compliance with the Transmodel data structures. SLTC is a daughter-company of the VIA-GTI group (120 operators in France) and operates the urban PT network of the Greater Lyon area, under the authority of the Syndicat mixte des transports pour le Rhône et l agglomération lyonnaise (SYTRAL). The SLTC network includes 4 metro lines, 100 surface transport lines and 2 funicular lines, providing a supply of 45 Mkm (commercial) per year, used by 255 Mpassengers. The surface network is operated by 1,000 vehicles. 3,500 persons are employed by the SLTC, of which 2,000 drivers. Operations management is broken down in 12 decentralised Transport Units (TU), of which 3 for the metro. The contract with the authority is at the operator s risks, resulting in tight budgetary constraints and close monitoring of supply and service quality. The implementation of a Transmodel-based integrated information system will support the SLTC to reach these objectives. 1.4.4.2. Objectives of the Project The Lyon project is mainly concerned with the re-engineering of the existing operational information system ( OIS ), which provides computer support for departments directly in charge of operations. This covers mainly the company areas dealing with transportation (tactical planning, operations and statistics), passenger information (operations) and personnel management (tactical planning, operations and statistics). The system comprises several applications and data stores distributed among the various sites involved: 12 Transport Units and the headquarters, the latter notably including the central Operation Methods ( OM ) and Computer departments. All sites are linked by a company data network. An important part of the data is concerned with the bus network, whereas some metro applications are worked independently. The system has been developed between 1988 and 1993 and generally satisfies the user s (operational departments) needs. However, the emergence of new needs and the necessity to replace some old applications has led the SLTC to consider a complete reengineering of the OIS in a more open and modular way, while maintaining performance standards. The TITAN Lyon development strategy is focused on the most sensitive data for the company, i.e. the operational production data. The re-engineering of the operational information system is planned in accordance with the following principles: - all applications supporting operational functions will be interfaced to a central database storing all the data shared by several applications or of interest for the management; - the design of the TITAN system should be based on solid data structures, therefore a company-specific conceptual data model will be developed, based on Transmodel; - the new system should include a data access system able to make the data treatment by the end-users easy and flexible; Public document Project n TR 1058 19/09/97

20 Deliverable 6.1. - the first step of the system to be implemented within TITAN will cover as many functions as possible related to the operation of lines. The future addition of functions in other domains will follow the same principles; - the opportunity will be taken to integrate some metro and bus functions which are currently operated separately; - the conceptual design will be supported by software and hardware capable of maintaining the existing levels of performance and security; - the new system should be presented in a user-friendly way to its end-users (user interface, education and training). The new system will be built around a "Production" database, storing all data collected referring to the operational production plan and the actual results. All connected applications will be interfaced with this database. Some applications will use working tables of which the structures will be, when possible, similar to the TITAN structures. The working data will be logically separated from the TITAN data, of which the record should remain unchanged within the same version, once in production. The main data flows between the applications and the production database are the following: - Typing data (types of lines, journey types...); - Stop point characteristics (location, equipment...); - Network description (points, links, lines...); - Elementary times (run, wait, layover times...); - Vehicle schedules (including evaluation); - Schedule assignments (according to various calendars); - Contractual driver schedules (including evaluation); - Variant driver schedules; - Operated changes in the supply (e.g. control actions and effects); - Survey data (e.g. quality of service, consumption, ticket validations); - Results of the personnel disposition process (assignment, work done...). 1.4.4.3. Considered Functional Areas According to the strategy chosen, the functional areas to be connected to the new system in the TITAN time scale, classified by Functional Area (FA) with reference to the Transmodel functional breakdown, will be following: - Plan Detailed Journeys (FA5) and Schedule Vehicle Blocks (FA6) - Schedule Driver Duties (FA7) - Manage Driving Personnel (FA 9) - Perform and Control the Driving Process (FA11) - Provide Passenger Information on the Planned Service (FA13) - Manage Statistical Results (FA25) - Manage Personnel (FA26) Further provision of other functional domains is planned in the short- or mid-term, especially: - Manage Vehicles (FA10) - Provide Passenger Information on Actual Service (FA14) - Fare Collection (FAs 21/24) 19/09/97 Project n TR 1058 Public Document

Deliverable 6.1. 21 1.4.4.4. Related Software Applications Figure 5 overleaf illustrates the description that follows. The main software applications to be related to the Lyon database are the following: - application aimed at managing general network data (list of lines, types of vehicles, etc.): this will be a new in-house development, with a direct client-server interface to the database; - application for the management of points (mainly the stop points and their equipment) and the description of the network (journey patterns, distances...): this will be a new development, subcontracted, with a direct client-server interface to the database, while the application will have own working tables; - vehicle and driver scheduling tool: implementation of a new commercial software; the interfaces will involve processes building tables or views of the databases (respectively of the application and TITAN), to be read by the other part; - conversion of existing schedules and other existing data to the TITAN format: interface to be in-house developed, directly writing in the tables through SQL statements; - evaluation of schedules: this will be a new development, with a direct client-server interface to the database; - applications providing various documents and files from the schedules: this will be a new development, with a direct client-server interface to the database; - management of calendar of operations: this will be a new in-house development, with a direct client-server interface to the database; - control of the schedules put in production: this is a new development, with a direct client-server access to the database, and involving interfaces with other applications (scheduling, contractual kilometric supply follow-up, display of timetables); - follow-up of the contractual kilometric supply: this will be a new in-house development, with a direct client-server interface to the database; - follow-up of the budget: this will be a new development, probably largely using the info-centre described below; - personnel disposition application: this recent application developed in-house, uses its own database; the interfaces will involve a direct dialog between the databases, using the required views; - follow-up of the actual supply (on-line modifications): this is a new subcontracted development; - follow-up of service quality: this will be a new development, with a direct clientserver interface to the database; - client information applications (telematic server, automatic displays, etc.): the existing applications will be interfaced to the databases through specific processes; - management information statistics: this will be a new development, probably largely based on the info-centre described below. Public document Project n TR 1058 19/09/97

22 Deliverable 6.1. General Data Management Points and Patterns Management Calendar Management lines, depots... schedule headers Scheduling (Vehicle + Driver) points, journey patterns calendars Supply Control TITAN calendars, schedule data Scheduling Data Base journey patterns vehicle schedules driver schedules Transmodelcompliant Operational Data Base Personnel Disposition Exploitation of Schedules (client info., documents, evaluation) schedule data any data driver schedules, calendars Personnel Disposition Data Base Data Access System (Info-Centre) Figure 5: Main Aspects of the Lyon Information System 1.4.4.5. Info Centre A data access system, easy to handle by the end-users, is necessary for all unexpected data queries, or queries customised by a user. The Info-Centre tool Business Objects, already used by SLTC, will be used to develop a dialogue environment adapted to the user requirements. This tool is interfaced with Oracle 7 databases, using SQL*Net to communicate with them. It brings a logical layer between the physical structure of data and the views of it a user may have. The user is hence allowed to dynamically query the database in an autonomous way, without using SQL or programme languages. From the functional environment defined by the data administrator, the user will access the base without any support from the computer department. 19/09/97 Project n TR 1058 Public Document