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

Transcription

1 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: , Fax: , dg/[email protected] Project manager: TransExpert (Kasia Bouree): Phone: , Fax: , [email protected]

2 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

3 Deliverable Table of Contents EXECUTIVE SUMMARY INTRODUCTION TRANSMODEL AND TITAN IMPLEMENTATION OF DEMONSTRATORS IN PILOT SITES OBJECTIVES OF THE REPORT OVERVIEW OF THE DEMONSTRATORS TO BE REALISED General Remarks The Demonstrator at the Pilot Site üstra (Hanover) Objective of the TITAN Implementation at üstra Functional Areas Considered Application Systems Comprised Architecture of the Integrated Information System The Demonstrator at the Pilot Site Salzburger Stadtwerke The Salzburg Pilot Site Objective of the TITAN implementation at Salzburger Stadtwerke Considered functional areas Comprised application systems Architecture of the Integrated Information System The Demonstrator at the Pilot Site SLTC (Lyon) The Lyon Pilot Site Objectives of the Project Considered Functional Areas Related Software Applications Info Centre General Architecture STATUS OF THE WORK IN THE PILOT SITES Status of the Work in the Pilot Site üstra Status of the Work in the Pilot Site Salzburger Stadtwerke Status of the Work in the Pilot Site SLTC PHYSICAL ARCHITECTURE OF THE DEMONSTRATORS GENERAL PRINCIPLES AND DESCRIPTIONS Common Approach for the Physical Architecture Principles of Optimization Database Objects PHYSICAL ARCHITECTURE OF THE DEMONSTRATOR AT ÜSTRA Hardware Platforms Software Applications and Interfaces The Database Access Control The Interfaces between the Application Systems and the TITAN-Database Database Schemas The Different User Schemas in the Database The Optimized Logical Data Model The Physical Database Schema...37 Public document Project n TR /09/97

4 4 Deliverable PHYSICAL ARCHITECTURE OF THE DEMONSTRATOR AT SALZBURGER STADTWERKE Hardware Platforms Software Applications and Interfaces The Database Existing Applications Types of Interfaces and Data Access Database Application Access Control Database Schemas Different User Schemas The Optimized Logical Data Model Physical Database Structure PHYSICAL ARCHITECTURE OF THE DEMONSTRATOR AT SLTC Hardware Platforms Servers Client Units Software Applications and Interfaces Software Applications Types of Interfaces Access Control Database Schemas Database structure at SLTC Types of Data Optimisations Realised on the Logical Model Physical Structure of the Database COMMUNICATION ARCHITECTURE OF THE DEMONSTRATORS PRINCIPLES OF INTEGRATION COMMUNICATION ARCHITECTURE OF THE DEMONSTRATOR AT ÜSTRA Networking Concepts Communication Layers between the Interfaced Applications and the Database Networking Organisation General Rules for Management of the Networking Management of the Interfaced Components Network Architecture Data Transfer Processes COMMUNICATION ARCHITECTURE OF THE DEMONSTRATOR AT STADTWERKE SALZBURG Networks Data Transfer Processes COMMUNICATION ARCHITECTURE OF THE DEMONSTRATOR AT SLTC Networking Concepts Management of Interfaced Components Physical Network Data Transfer Processes IMPLEMENTATION PLAN IMPLEMENTATION PLAN AT ÜSTRA Installation of the Database Implementation of the Interfaces Data Conversion and Entering Database Evolution Accompanying Measures IMPLEMENTATION PLAN AT SALZBURGER STADTWERKE /09/97 Project n TR 1058 Public Document

5 Deliverable Installation of the database Implementation of the Interfaces Data Entry and Conversion Database Evolution Accompanying Measures IMPLEMENTATION PLAN AT SLTC Database Creation Database Optimisation Data Conversion and Entering Database Evolution Accompanying Measures CONCLUSION...80 BIBLIOGRAPHY...81 LIST OF ABBREVIATIONS...82 Public document Project n TR /09/97

6 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

7 Deliverable 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 /09/97

8 8 Deliverable 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 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 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

9 Deliverable 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 /09/97

10 10 Deliverable Overview of the Demonstrators to be Realised 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 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 The Demonstrator at the Pilot Site üstra (Hanover) The Hanover Pilot Site üstra 19/09/97 Project n TR 1058 Public Document

11 Deliverable 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 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 /09/97

12 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 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 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

13 Deliverable 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 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 Public document Project n TR /09/97

14 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

15 Deliverable 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 /09/97

16 16 Deliverable The Demonstrator at the Pilot Site Salzburger Stadtwerke 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 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 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

17 Deliverable 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 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 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 /09/97

18 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 The Demonstrator at the Pilot Site SLTC (Lyon) The Lyon Pilot Site 19/09/97 Project n TR 1058 Public Document

19 Deliverable 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 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 /09/97

20 20 Deliverable 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...) 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

21 Deliverable 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 /09/97

22 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 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

23 Deliverable General Architecture The architecture of the new operational information system in SLTC is based on the client-server technique. Data of interest for the company is stored in databases implemented on specific hardware servers, distributed to client users through a data network linking all computers and accessible by graphical software applications. Servers are multi-task and multi-users machines (department mini computers) while client units are personal computers (PC) linked by a network. No data is stored on the client computers, on which the interactive applications access the databases implemented on the servers. Within the TITAN project in Lyon, the database structured from Transmodel is installed on a server located in the company headquarters. The client computers, operated under Windows, are mainly based in the 12 Transport Units (TU). Local networks (LAN) link the computers of each TU and of the headquarters, and are connected by a long-distance network (WAN) using specific lines, in a transparent way for the users. The TITAN production database will co-exist on these servers with other databases (e.g. maintenance, scheduling or personnel disposition applications, etc.). This architecture offers a high independence of the various components, hence a good flexibility for implementation and evolution and less dependence from the suppliers. Most of the applications connected at the present stage are specific to SLTC, either developed in-house or by subcontractors. Due to the characteristics of the new system, most of these applications are re-engineered within or in parallel to the project. This offers the opportunity to develop interfaces with direct client-server accesses to the production database, or with exchanges of data between specific databases and the production database. However, the most important connected application is the scheduling tool, which is a standard commercial product (Hastus V5) requiring a specific interface to be developed. Most of these applications will have instances implemented on the client units. Public document Project n TR /09/97

24 24 Deliverable Status of the Work in the Pilot Sites Status of the Work in the Pilot Site üstra The work plan developed for the realisation of the demonstrator in Hanover follows the Five Phases Model proposed by the European Commission, which means to - analyse the user needs, - develop the specifications, - build the demonstrator, - validate the implementation, and - demonstrate and evaluate the pilot system. The analysis of the user needs was completed in the first phase of the project and is documented in the corresponding internal report AP41, and in the project deliverable 4.1. The specification stage is also finalised and documented in the internal reports AP51 and AP54, as well as in the deliverable 5.1. The implementation of TITAN-database (AP61), which is the central part of the demonstrator in Hanover, is nearly finalised. The core of the database, including the table definitions, has already been finalised and implemented. Additional database objects, like indexes, triggers and stored procedures, which are needed to ensure the integrity and consistency of the information stored in the database, were specified and implemented, too. At this point in time, more than 100 SQL scripts, which create all the static and dynamic components of the database, are under an exhaustive test. Regarding the interface programs between the TITAN-database and the application systems, which will only partly be developed in-house by üstra itself, most of them are ordered from the software suppliers after long and difficult negotiations. This experience shows, that an open standard is urgently needed to reduce the dependencies of the PT operators from software suppliers of their installed application systems. The final in-depth specification of the interface between the AVM system and the TITAN-database and further negotiations with the sofware supplier were postponed after the decision for the new system is made. 6 This will not delay the integration process of the other application systems because each application system could be integrated separately after the delivery of its interface (see section 4.1 "Implementation Plan at üstra") and no application system needs information from the AVM system, except the management information system (MIS). The steps of defining the necessary tests and validation methods (AP63) and of data entry and conversion into the specified formats (AP62) are currently being prepared. The implementation of the applications (i.e. the interface modules and the new MIS application) has already been started (AP64), as far as the programming phase of the interface for the scheduling application is concerned. This will be the main source for delivering data into the TITAN database, and therefore is a prerequisite for testing all the other interfaces. 6 It should be noticed, that the replacement of the old AVM system is a result of the in-depth analysis done in the TITAN project. 19/09/97 Project n TR 1058 Public Document

25 Deliverable Status of the Work in the Pilot Site Salzburger Stadtwerke The first phase of the project was dedicated to the identification and analysis of the user needs and of the current systems and processes related to the functional areas selected for implementation of the planned integrated system. This phase was finalised in 1996 and is documented in the internal report 41 and in the project deliverable 4.1. The specification stage comprises the investigation of the data needs for the future integrated information management system, the development of the conceptual data model structuring these data in a well-ordered way, the deduction of a logical data model including relational tables and their columns, and the formulation of software specifications for programming of the interfaces needed to couple the applications in question to the TITAN database. This stage is also finalised and documented in the internal reports AP51 and AP54, as well as in the deliverable 5.1. However, some additional data elements for the TITAN database have still to be specified by the City authorities, mainly related to the traffic planning domain. As the municipality is not officially involved in the TITAN project, the TITAN planning cannot be automatically applied in the cooperation with the City authorities. Some refinements of the TITAN database are therefore likely to occur in the near future, not affecting the basic structures already defined, but being additions necessary to meet the user requirements of the municipality. The corresponding internal reports will therefore be issued in a final version subsequently. The hardware platform for the TITAN database as well as the installation of the Oracle RDBMS and development tools is ready, with an initial prototype of the TITAN database already realized, including most of the tables needed for the public transport domains foreseen to be integrated in the demonstrator. The SICAD Open version of the GIS is installed, and geographical data have been transferred from the mainframe version of the GIS (SICAD) to SICAD Open, as far as needed for the TITAN demonstration system. Additional data entry is well advanced, concerning the geographical aspects of public transport objects, like the location of stops and traffic lights, particular stop point equipment, structure of the public transport and overhead wire network and other data not maintained in the genuine public transport scheduling applications. Demographical data of the service area, related to a 100m x 100m grid, were also updated to prepare additional future traffic planning evaluations. Regarding the programming of interfaces, the implementation phase has started with the realization of the module coupling the scheduling system (EPON) to the TITAN database. A standard interface for EPON to guarantee data export from EPON to any suitable TITAN database is aimed at, so the realization work is done together with üstra to benefit from a synergy facilitated by the cooperation in the consortium Status of the Work in the Pilot Site SLTC After the initial phases of identification of requirements (reported in Deliverable 4.1), conceptual data modelling, specification of logical models and of applications (reported in Deliverable 5.1), the present phase covers the definition and implementation of database structures, physical architecture and communication architecture. As reported in the previous Deliverables, the staged approach (first study of requirements, then conceptual modelling, then logical modelling, etc.) has not been applied to the whole project but to each domain of application. For instance, the development of the calendar management application was almost completed and the Public document Project n TR /09/97

26 26 Deliverable 6.1. physical tables created and filled, while details of conceptual modelling for actual kilometric follow-up was still under study. This has led to numerous feedbacks and relatively important time planning differences between domains. However, it is now felt as efficient given the local situation. The present status of the work is as follows: - the hardware platform for servers has been installed for several months and is running satisfactorily, even if some minor adaptations may be still necessary; - the client units are part of the standard PC equipment of SLTC, which is regularly renewed. The migration to the Windows NT operating system is only partly implemented; - the database has been created starting from the data used by the calendar management. At the time being, the physical objects exist as well for common network data, network description (points and patterns), and vehicle scheduling. The logical model of other parts is still under refinement; - the development of new or re-engineered applications is either completed (calendar), under process (general network data, network description) or planned after further refinement or completion of the specifications; - the interface specification for vehicle and driver scheduling is completed, while other interfaces with existing applications are still under study. Interfaces for data conversion from existing applications or files are almost completely developed; - the data network is installed, as it is an evolution of the existing network. Some improvements (speed increase) are planned for the coming months. 19/09/97 Project n TR 1058 Public Document

27 Deliverable Physical Architecture of the Demonstrators 2.1. General Principles and Descriptions Since the three sections 2.2 to 2.4 present the physical architecture of the three pilot sites separately, and the physical architectures vary slightly from each other, this section comprises common principles and descriptions related to database parts of the physical architectures, which are the most similar parts of the physical architectures at the three pilot sites Common Approach for the Physical Architecture End User End User End User End User Application Application Application Application Interface Application Interface SQL-Interface TITAN Reference Database Figure 6: The Common Physical Architecture Approach Since SLTC has slightly modified its initial approach for the physical architecture, all three sites use allmost the same approach for the physical architecture. This common approach could be shortly described as follows: The central part of the integrated information system is a reference database to which all applications and users are linked. Old (file based) applications are leaved as much unchanged as possible and are linked to the reference database via an interface. New applications are either linked to Public document Project n TR /09/97

28 28 Deliverable 6.1. the reference database via an interface, specially planning applications, or operate directly on the reference database providing an intuitive end user interface (e.g. Business Objects). Special skilled end users may access the database directly via a standard SQL-interface Principles of Optimization The normalisation rules in a relational database design are useful to avoid redundancy and contradictions in the data stored, but are sometimes troublesome with respect to system performance and efficient disk space requirements. A careful denormalization and controlled replication of information distributed over a number of tables, as well as storing derived values in particular columns to be added to the appropriate tables, turned out to be useful to support full operational performance of the data access modules to be developed as a part of the interfaces, or of specifically designed data query tools. These measures included among others the following possibilities: elimination of tables associated with another table by a one-to-one relationship in the corresponding ERD, denormalization by copying attributes into tables, to accelerate retrieval, conversion of tables associated with another table by a few-to-many relationship in the corresponding ERD into a group of repeating columns in that other table, elimination of one of the tables which are part of a many-to-many relationship in the corresponding ERD by including its attributes in the intersection table which represents the relationship, splitting of a table into two tables if a certain group of attributes often has simultaneously the value NULL, shorten access time by storing derived attributes in tables, replace a multi-column key of a table by an artificial identifier to allow other tables to make reference to this table with only one short foreign key column instead of many long ones. For the data exchange process between applications the use of artificial keys can result in several problems. To avoid problems with artificial keys, natural keys are used, so the use of multi-column keys could not be prevented. Since denormalization results in redundant identical attributes in different tables to improve the data access time, constraints were defined which will ensure consistency of the data in question Database Objects The physical database schema describes the defined data objects and their location in the physical layout of the database, i.e. in which files and on which disks the data objects will be placed. Furthermore it describes sizes of the mentioned database objects. The following database objects were defined: tables, views, indexes, sequences; constraints, triggers, 19/09/97 Project n TR 1058 Public Document

29 Deliverable stored procedures. Tables store the entities and relationships between entities of Transmodel. Nearly all entities are represented as tables, sometimes conceptual entities were converted into attributes of other tables (e.g. at üstra the entity ROW/DRIVER is converted to an attribute of ROSTER MATRIX). Views can restrict user access on tables and they are a good means to control user access to the database. For instance, at üstra a view for the entity VEHICLE JOURNEY was created to combine the physical tables JOURNEY and JOURNEY-DAY-TYPE- ASSIGNMENT (see above). Further views will be created to facilitate the development of statistical evaluations. Typical example of views in Lyon are those designed for evaluation of schedules (providing statistical evaluation of a schedule in terms of kilometers or driving time) or for the interface with the scheduling application. Indexes are data structures which allow fast data access. Indexes enable the database to access the data in the tables much faster than by table scans. The latter are reads of the whole table whereas an access by index only read the smaller index structure until the address (rowid) of data of interest are found (indexes are sorted, so the searching time within the index is much shorter). After locating the data of interest in the index the row-id of the data record(s) in the table is (are) read from the index. By using the row-id of the data record(s) table access can be speeded up. A useful rule for the creation of an index could be: Whenever tables will have more than 200 data records, indexes are created. Indexes are created on primary keys of the table and on other attributes which are used often for query or selection processes. The index referencing the two end POINTs of a JOURNEY PATTERN is a typical example. Sequences generate a serial list of unique numbers for numeric columns of tables. Sequences simplify application programming by automatically generating unique numeric values for rows, e.g. identifiers. Sequences avoid to use tables and SQL requests to increment values of identifiers. Constraints are primary keys, foreign keys and not null constraints and domains of permitted values for distinct attributes. Primary keys define the identifier of each row in their tables. Foreign keys ensure consistency between referencing and referenced tables. Foreign keys ensure that if a table references a data record of another table this record in the referenced table must exist. Otherwise the insert or update-statement for the referencing table will fail. On the other hand deleting a data record in a referenced table will lead to an error if a data record in a referencing table exist, which references the data record which shall be deleted. Another possibility is to define a cascading delete action on all referencing tables, which means, that if a record in a referenced table will be deleted all records of referencing tables which references the deleted data record will be deleted, too. Not null constaints can be defined for single attributes of a table to determine that these attributes are not allowed to be empty 7 (corresponds to "null" in database jargon). Wherever a not null constraint is specified, the insert of an empty value will cause an error. For instance the LINE name should be not null. Triggers will be defined to ensure less complex data consistency, which cannot be handled by constraints, e.g. at üstra to transfer obsolete data of modifyable tables into 7 A "null" means that "no value exists" for the attribute in question for a given record. A blank or a 0 (zero) is not a null value. Public document Project n TR /09/97

30 30 Deliverable 6.1. the reference tables ("ALL_"-tables), or to carry out some simple calculations (e.g. cumulated values). Stored procedures will be implemented to ensure complex data consistency which cannot be garantueed by triggers anymore and to calculate complex data. An example for complex calculations is the calculation of timetabled passing times from individual service journeys. Another stored procedure is for instance implemented to calculate which vehicle schedule is to be applied on a line for a specified day Physical Architecture of the Demonstrator at üstra Hardware Platforms The Hardware architecture describes the computers which are connected over the network to the TITAN-database. Figure 7 overleaf illustrates the description that follows. All servers reside in the main building of üstra, with the exception of the RVAS- and EFA-servers of the KGH 8. Users are working on workstations which are in most cases PCs. These components are connected by the existing network at üstra. The vehicle and duty planning process is centralized and will be performed on garage "Busdepot Süd" for organizational unit "Bus" and on garage "Glocksee" for organizational unit "Light Rail". The planning process will be done on PCs with a Terminal emulation program. EPON is a X-Motif-compatible application. EPON itself is installed on a DEC Alpha 2000 computer. The PERDIS server (DEC Alpha AXP 3000) is also located in the main building while the users access the PERDIS data and software by using terminal emulation on PCs. The BON data administration and maintenance system as well as its runtime system are installed on a microvax. The system will be accessed directly with a terminal. Only the data administration system of the AVM system is of importance for the connection to the TITAN-database. The data supply system of BON will receive the network and target timetable data from the TITAN database, and will internally convert these data for use in the runtime system, which uses binary files in a BON specific format. The passenger information system FGI-Z (see Figure 2) is installed in two versions on two microvax nodes. The development version serves only for further development of the FGI-Z-system. The production version will import the target timetable data directly into its runtime system. FGI-Z will be accessed over terminal. The stop point announcement system MOBILE at üstra resides on a PC which is a stand alone system at present. It has to be verified, if the PC can be connected to the üstra network. MOBILE works on a antiquated version of a PROGRESS database system which is not able to connect directly to an ORACLE database. The data transfer can be handled by using an export file, especially formatted for PROGRESS. At this point in time there are several problems in connecting the MOBILE-PC to the network. For this 8 The Greater Hanover Area transport association. 19/09/97 Project n TR 1058 Public Document

31 Deliverable reason it might be possible to exchange the data by floppy disks which hold a MOBILEspecific export of the TITAN-database. The passenger information system RVAS (see Figure 2) at üstra resides on the same server as EPON. Access on the RVAS system will be done by using a terminal. The RVAS system and the EFA system on KGH are connected via ISDN (Integrated Services Digital Network) with the üstra internal network. ALPHA 1000 TITAN DB ALPHA EPON - RVAS PC -Mobile RVAS Server ALPHA AXP Perdis micro VAX BON Dev (AVM) EFA Server Router ISDN Router micro VAX BON Run (AVM) KGH micro VAX FGI-Z Dev (PI) üstra micro VAX FGI-Z Run (PI) Figure 7: General Hardware Architecture, Connection of Servers Public document Project n TR /09/97

32 32 Deliverable Software Applications and Interfaces The Database The data exchange platform was installed on a test server (DEC Alpha) for first tests and will be installed for the final demonstartor on an Oracle database on another DEC ALPHA computer. The entire information will be stored on one node, no distributed options of the database will be used. To speak in Oracle jargon, only one database, controlled by one instance will be implemented Access Control Access control is an important subject of the realization, because several users work with the application programs but only some of them will be authorized to use the interface program to start the data transfer. Figure 8 overleaf illustrates the description that follows. Access Control is composed of two parts. 1. Access to the interface program: Since not every user is allowed to work with the interface program, during the start up process the program asks the user for his or her username and password. The combination entered by the user will be checked against an interface program internal user database or against the operating system rights database which is not part of the TITAN-database. 2. Access to the TITAN-database: Access to the TITAN-database will be controlled by maintaining one and only one user for every application interface. The user name will be the name of the application program. After a positive user identification of the interface program, the user will be connected to the TITAN-database with the name of the application. As an example, the following figure shows the user authentification process for the EPON-interface program. This method facilitates user control. The number of TITAN-database users is reduced, because every interface user will be connected as "application program". This procedure will be installed because all users of the same application, who are allowed to transfer data to or from the TITAN-database have identical access rights on tables for the data transfer. A further advantage is a decentralization of user administration. The application interface or operating system administrator can manage and control user access without delay by entering, modifying or dropping that user directly in the application or operating system specific user database. The TITAN-database administrator does not need to be involved in the user administrating process of application interfaces. He must only be involved if new applications will be integrated, to create an application system user. 19/09/97 Project n TR 1058 Public Document

33 Deliverable User "Müller" "Müller"... Interface User Application Interface "Maier" User "Maier" "Müller" "Maier" "Müller" "Maier"... Interface or Operating System User- Profile Application name (e.g. "EPON", "PERDIS", etc.) (Database-User) RDBMS Access control TITAN-DB "EPON" "PERDIS"... TITAN Data TITAN Data TITAN Data TITAN RDBMS User Maintenance Figure 8: User Access Control For administrating users of interface programs an administrator will be designated from the staff, who work with the application system of the respective interface program or who administers the operating system of the computer the application and its interface runs on. Administrative tasks which belong to the interface program are functionally integrated in the field of activity of the people working with the tool. This means, that user access control will be a decentralised process. An exception will be given for Management Information System (MIS) users. These users operate directly on the TITAN-database with their statistical tools. For these applications TITAN-database internal access rights have to be defined The Interfaces between the Application Systems and the TITAN-Database The following table summarize in a very condensed way the characteristics of the interfaces between the different application systems and the TITAN-database and their status of implementation: Public document Project n TR /09/97

34 34 Deliverable 6.1. Functional Area Application Interface Hardwareplattform implementation remarks Vehicle + Driver Scheduling Personnel Disposition EPON write to DB Alpha/OpenVMS ordered, implementing 9 PERDIS read from DB Alpha/OpenVMS ordered, implementing Autom. Vehicle Monitoring BON (or other) read from DB / write to DB VAX/VMS suspend until decision is made Passenger Info. MOBILE Appl. read from DB INTEL/Windows 3.1 under negotiation Passenger Info. FGI-Z read from DB VAX/VMS implementing Passenger Info. RVAS (at üstra) read from DB VAX/VMS negotiation nearly finalised Passenger Info. RVAS (at GVH) read from DB VAX/VMS negotiation nearly finalised Passenger Info. EFA read from DB INTEL/UNIX 10 negotiation nearly finalised Statistics/MIS MIS/Statistics operate on DB / write to MS-Excel Alpha/OpenVMS further in-depth specification in progress Figure 9: Interfaces & Applications The specifications of the interfaces are published in the deliverable 5.1 "Description of Pilot Sites Specifications" and a more detailed description is presented in the internal report "Specifications of the Pilot Sites - Pilot Site üstra (Hanover)" Database Schemas The Different User Schemas in the Database Several users will be created to hold data for different purposes, notably production data, test data for verifying the data transfer process and RVAS data which contain only timetable data for printed output. Each user holds his own objects. By using this approach, the data model can be implemented more than once. If there will be demand on further schemata, e.g. for several project purposes, they can be created. An advantage of this proceeding is that constraints for each schema can be restricted for the demands of the use of this schema. e.g. their might be a project to examine duties. Since no timetable data is used, it is possible to disable the constraints which reference blocks and jouneys. At this stage at üstra, the data model is implemented as user schema for the users "PROD", "TEST", "RVAS", "TITANIMP". The latter is an intermediate user for the data transfer process between EPON and the respective database schemas ("PROD", "TEST", "RVAS"), because several consistency checks, which cannot be garantueed by EPON, 9 Some parts of the specified functionallity are implemented in the TITAN-database to reduce the costs of the interface. 10 The platform will be changed in the next months to INTEL/NT. 19/09/97 Project n TR 1058 Public Document

35 Deliverable have to be performed before storing the data directly in the destination schema. For the realization of consistency checks database triggers and stored procedures were implemented. Public document Project n TR /09/97

36 36 Deliverable The Optimized Logical Data Model The optimized logical data model was derived from the native logical data model. Some additional (redundant) attributes within tables and views were added. Some concepual entities were converted to attributes of other enitites. One table was split to save disk capacity. Additional (redundant) attributes within tables were added to optimize access performance. E.g. FOOTNOTE ASSIGNMENT allows to specify a part of a journey pattern, on which the specified footnote will be displayed. The part of journey pattern is limited by points on journey pattern, of which the primary key is composed of the primary key of journey pattern and an order identifier. The point identifier has only informative character. In FOOTNOTE ASSIGNMENT, which references points in journey patterns, the point identifier is saved to have a direct access on the locations (stop points) where the footnote shall be displayed. Redundant attributes avoid joins of several tables to get a distinct information. Additional tables were added to simplify or speed up data access or to save space on disk. Moreover some tables were added to satisfy demands of application systems or users, not known in an earlier stage of the project. Some entities of Transmodel have only conceptual character. E.g. ROW/DRIVER is defined as entity in Transmodel. Since it has no further attributes this entity was converted into an attribute of the roster matrix. Since the set of data stored in the TITAN-database will grow immensely over time it was not possible to optimize the database model for access performance only. To economize disk usage of the TITAN-database, the logical table VEHICLE JOURNEY (which contains service journeys as well as dead runs) was split into JOURNEY and JOURNEY-DAY-TYPE-ASSIGNMENT. Joining the both last-mentioned tables will result in the original VEHICLE JOURNEY table. This method is possible at üstra using the interfaced applications, because in EPON (Vehicle and Driver Scheduling application) journeys of one day type will be copied for the use on other day types. In EPON only flags (or bits) are set to assign a journey to a day type. Primary keys of copied journeys will not be changed. The combination of journey and day type result in the Transmodel entity VEHICLE JOURNEY. By splitting this table the set of data to be saved will be reduced by a large amount. In comparison to the logical data model additional tables were introduced to realize the version concept more efficiently. In the optimized data model for all tables which contain updatable data, so called "ALL_"-tables were introduced to save currently valid and obsolete data for later statistical evaluations. Data valid on the respective operating day are stored in the genuine table. The complete name of these version tables will be composed of "ALL_" and the name of the genuine table, e.g. "ALL_LINK". In contrast to the approach, described in the logical data model, these methods facilitate the version management of data. Within the logical data model it was planned to have an attribute called "valid_since" in the primary key of each table which contains modifyable data. This method would lead to high database activities in cases of updating a modifyable data row, since the "valid_since" attribute within all records in tables which reference the modified data record have to be updated. This is required, because a foreign key constraint in the database can only reference a complete primary key. From this restriction it has to be concluded, that the "valid_since"-attribute of modifyable tables which will be referenced from other tables has to be adopted in the referencing tables. 19/09/97 Project n TR 1058 Public Document

37 Deliverable In the new concept all modifyable data will be written to the "ALL_"-tables. Within the genuine table (e.g. LINK) only the values valid on the respective operating day are stored. To realize this concept a stored procedure has to be started every night, which checks if there are values in the "ALL"-table to be transferred into the genuine table. The stored procedure checks on the basis of the valid since date in the primary keys of the data records if this record have to be used to overwrite the previous valid value in the genuine table. Primary keys of the "ALL"-tables contain the "valid_since"-attribute, which is not the case in the original tables. Cascading updates of referencing tables is not necessary. In addition a "valid_until"-attribute was introduced into the "ALL"-tables which saves the date of the day before the new updated values become valid. This procedure ensures the preparation of statistical evaluations, using the correct data of each validity period The Physical Database Schema The detailed description of physical database schema, which is included in the SQL scripts, is not of public interest. Therefore only a high level description of physical database schema and the employed techniques is presented. Figure 10 overleaf illustrates the description that follows. The physical layout of the database objects refers to the positioning and the physical storage of the database objects on the hard disks. The physical layout of the database objects is restricted by the existing RAID Level-5-harddisk-array with one disk controller. For data saving purposes only this RAID-system can be used. A distribution of data files over several hard disks to increase access performance on redo log files, indexes and data by distributing input/output activities is not possible. All data and index files will be stored on the RAID disk array. On a RAID array data units (bytes or smaller units) will be distributed over several disks by using parity information to ensure a higher data security. If a disk will cause an error or would be defective, the rest of the data can be restored by using the accessible information. Control files and redo log files should not be stored on a RAID-Level-5-Array. Instead they will be stored on a separate system disk. This is a requirement of ORACLE to ensure data recovery in cases of system failures. To facilitate database administration data, indexes and redo log files will be distributed over several tablespaces. Tablespaces are logical units in ORACLE to group and organize database objects and which consists of physical data files. The three types of data objects will be separated. Dependant on different growing factors of individual tables, tables of similar size or growing will be grouped in common tablespaces. I.e. tablespaces for small, medium and large tables will be created, as well as for indexes. During the database creation tablespaces of different sizes will be created to fulfill the demands on extent growth of the data objects. As far as possible a balance of data file access will be taken into consideration to avoid larger work loads on distinct files while others will be not or only rarely be accessed. Public document Project n TR /09/97

38 38 Deliverable 6.1. TITAN-DB redo log files control files System- Disk small tables large tables small indices large indices small tables large tables small indices large indices RAID- Disks small tables large tables small indices large indices small tables large tables small indices large indices Figure 10: Distribution of Database Tablespaces and Files 19/09/97 Project n TR 1058 Public Document

39 Deliverable Physical Architecture of the Demonstrator at Salzburger Stadtwerke Hardware Platforms The Hardware architecture describes the computers which are connected via network to the TITAN-database. The two departments of the City Department of Works concerned by the realisation of the TITAN demonstrator are - the public transport department and - the central department for graphical data processing. Apart from these two units, the - traffic planning department of the municipality is a user and provider of information to be recorded in the TITAN database. These three departments reside in different buildings in different parts of the town, but are connected by network. The hardware platforms used in the organisational units of the City Department of Works differ significantly, depending on the reqirements of the application systems in use today. Public Transport Department: The central depot for the buses and trolleybuses is at the same time the place where the offices for the staff in charge of scheduling the vehicles and the drivers and in charge of vehicle and driver management are located. The computers used to run the public transport applications are therefore installed in the offices located at the central depot. The application used to support the scheduling functions and timetable information is EPON, which runs on a Digital Alpha 1000A server under the OpenVMS operating system. Five PC's are used as EPON terminals, equipped with the Exceed terminal emulation software running under MS/DOS and MS Windows The migration to Windows NT as the client platform is planned for the near future. The BAS/VAS application used for operational analysis and statistical evaluation is installed on the same server as EPON, with one additional PC installed as the user terminal to operate the application. Department for Graphical Data Processing: This unit resides in an own building (called "Frey Villa") located in the area around the main building of the City Department of Works where the head office and all the central departments are concentrated. Figure 11 overleaf illustrates the description that follows. The geographical information system installed and maintained by the department for graphical data processing runs on a Siemens BS2000 mainframe computer, which will however not be integrated in the TITAN system. Instead of this mainframe solution, an additional Unix server has been installed to run the SICAD Open version of the GIS, using an Oracle database for storing the geographical information and thus open for data integration with other applications in the framework of the TITAN information management system. The Unix server used for this purpose is a Silicon Graphics computer running under the IRIX 5.3 operating system. Six Silicon Graphics Indy workstations are used as GIS Public document Project n TR /09/97

40 40 Deliverable 6.1. clients, running under IRIX 5.3 as well. In addition, one PC is used as the developing platform for the TITAN demonstrator and future database applications. This PC is running under Windows NT 4.0 and has the Oracle Designer/2000 and Oracle Enterprise Manager tools installed on it. Figure 11 shows the hardware components installed in the "Frey Villa" which form the basis for the hardware enviromment available to build up the TITAN demonstrator. Frey-Villa R105 fgd-exch proxy2 proxy frey15 Indy fgd_hp750c1 R110 R102 fgd-stan Indy fgd_neba Indy fgd_seeb Indy Indy fgd_hreb fgd_lore R107 fgd_mueh Indy frey11 Figure 11: Hardware Components for Installation of the TITAN Demonstrator Software Applications and Interfaces 19/09/97 Project n TR 1058 Public Document

41 Deliverable The Database The Oracle RDBMS is installed on a Silicon Graphics workstation used as the database server holding the geographical database as well as the TITAN database used for data exchange and integrated information management. The version installed at the department for graphical data processing is the Oracle Server Only one database and one instance will run on the database server, maintaining the geographical as well as the public transport and traffic planning data. Database tools supporting database administration, monitoring of database and user activities, development of database applications and data retrieval are also installed to take advantage of the possibilities of an advanced database management system Existing Applications The existing software applications to be coupled to the TITAN database (cf. section ) are - EPON for vehicle and driver scheduling as well as timetable information, - BAS/VAS for run time analysis, passenger counting and statistical evaluations, - SICAD Open (the geographical information system). EPON and BAS/VAS are running on a DEC Alpha server under the OpenVMS operating system at the public transport department, which resides in an own area and offices completely separated from the graphical data processing department (in another part of the town). SICAD Open runs on a Silicon Graphics workstation at the premises of the data processing department located near the central building of the City Department of Works Types of Interfaces and Data Access The following data transfer and manipulation activities are foreseen in the TITAN database: - delivery of new data from applications into the database via interface program, - delivery of new data from external data files (e.g. traffic planning and statistical data) into the database by means of a conversion procedure and standard database import tools, - import of geographical data available in the GDF format from external sources, - change or update of data already stored in the database, - export of data from the database into applications via interfaces, - export of GDF files from the geographical database, - export of data from the database to standard office automation packages or to separate files for further evaluations in other programs, - read access by database users or standard reporting or data retrieval tools. Related to these different data entry and retrieval processes, different types of interfaces are implemented: - one interface exclusively writing data from an application (EPON) into the database, - one interface reading (network and timetable) data from the database into the application (BAS/VAS), and writing results of operational analyses and statistical results into the database, - one bidirectional interface for import and export of GDF files. Public document Project n TR /09/97

42 42 Deliverable 6.1. The transfer of traffic planning, demographical and statistical data between the City authorities and the City Department of Works will be carried out using the standard import/export utilities of the RDBMS and specific conversion routines to be applied dependent on the data files available from the municipality and other external sources. The export of information from the database to office automation tools (like e.g. Microsoft Access or Excel) will be realised using ODBC drivers (e.g. from Intersolv) and tools like e.g MS Query Database Application A new database application for data query and retrieval as well as reporting purposes will be implemented using the Oracle Developer/2000 tools. This application aims at providing end-users with all information from the database they need for their daily work or specific projects Access Control The TITAN database will be administered by particular staff assigned to this task from the graphical data processing department. Access to the database by interface programs or by human users will be regulated and controlled by the database administrator. Human end-users will principally be granted read access only. They will be authorized to connect to the database by user-name and password. The database user-names will be generated in a generic way, reflecting the organisational unit and functional domain the individual person asking for database access is assigned to (e.g. "Fahrplanbüro" - scheduling unit, "Verkehrsplanung" - traffic planning unit etc). Additional database user-names will be introduced for each of the interface programs, in order to allow these programs to connect to the database and perform data queries and manipulations by embedded SQL statements. The rights and priviliges granted to these implicit users will be defined according to the tasks performed by the program in question. Access to the interface programs will be granted and controlled by the organisational units which are responsible for the application package in question. The public transport department is in charge of running and maintaining EPON (the scheduling system) as well as BAS/VAS (the operational analysis system), and will therefore also be in charge to run (and control access to) the corresponding interfaces coupling these applications to the TITAN database. This department will therefore appoint the person(s) in charge of triggering the data transfer process from EPON and from BAS/VAS into the database via the interfaces, as well as the provision of basic network and timetable data from the database to BAS/VAS. The access rights to start these interface programs will be regulated by the public transport operator accordingly. The central department for graphical data processing is in charge of running and maintaining the geographical information system, and therefore controls all activities related to the GIS, including user authorization. Staff from this department will therefore remain responsible for all data entry and maintenance processes related to geographical data, and will be assigned the responsibility for controlling access to the future GDF interface to be introduced as a part of the TITAN demonstrator. The maintenance of correspondence tables between GIS objects and data objects from other domains (e.g. traffic planning areas, public transport network elements, addresses etc) will also be the 19/09/97 Project n TR 1058 Public Document

43 Deliverable responsibility of the data proccessing department. Write access to these parts of the database will be exclusively granted to the people in charge of this task. The new database application will only read data from the database, and will connect to the database using the Oracle user-name assigned to the human end-user who has invoked the tool Database Schemas Different User Schemas The TITAN database at the City Department of Works in Salzburg is implemented on the same database server which was built up to run the SICAD Open version of the GIS with its geographical data stored in an Oracle database. To separate the genuine geographical data sets from the generic pool of information which forms the core of the TITAN demonstrator, different user schemas "GIS" and "TITAN" are defined. The "GIS" schema holds all the data exclusively accessible by the GIS, and structured according to the internal conventions of SICAD Open. The "TITAN" schema holds all data to be exchanged between public transport applications, the correspondence tables defining relationships between public transport objects and geographical objects maintained in the GIS, and statistical and administrational data related to the traffic planning domain, to be exchanged with the City authorities. The separation between the "GIS" and the "TITAN" schema was introduced from the functional point of view, in order to distinguish the different semantical domains and functional purposes of the information in question. Another category to be taken into account is the management of the data transfer processes. As any data sets to be imported into the TITAN database should be checked against integrity and consistency with the data already stored in the database, an additional schema "IMPORT" is necessary. Any data transferred to the TITAN database will be stored in this schema temporarily, in order to be able to carry out the necessary checks, comparisons and computations before the data received e.g. from EPON are definitely stored in the "TITAN" tables The Optimized Logical Data Model The normalized logical data model for the TITAN demonstrator in Salzburg was derived from the conceptual data model built up on the basis of Transmodel and taking into account the specific requirements of the Salzburg pilot site. Starting from the normalized logical model, optimizations were carried out to speed up data access, to reduce disk space requirements, and to better adapt the database structure to the methods with which the application systems to be integrated are viewing their data. One of the main optimization measures was to introduce additional attributes in tables to avoid time-consuming table joins and thus to increase the performance of data access. Another type of optimization was to record explicitly the results of computations carried out for evaluation purposes in particular attributes, which were added to statistical tables e.g. in the operational analysis domain. This is of course redundant and can at any time be derived from the basic information included in the normalised part of the tables, but is not critical with view to data integrity because empirical results (of counts and measurements) do not change their value. Public document Project n TR /09/97

44 44 Deliverable 6.1. In some cases additional tables were introduced to simplify or speed up data access or to satisfy some needs of application systems or users not known in an earlier stage of the project. The refinement of the logical data model was carried out partly in cooperation with the pilot site üstra, in particular concerning the scheduling tables of the public transport domain. This cooperation was started with the intention to check how far the development of the EPON interface can be harmonised, because EPON is the scheduling package used in both sites. The current expectation is that this interface can probably be largely standardized, which is in the interest not only of the two sites concerned, but also for the user community in general. As a consequence, part of the database tables related to the scheduling domain were adapted to the requirements of a common interface specification. The most important modification refers to the definition of the JOURNEY table, including journeys (service journeys as well as dead runs) which are defined independently of the day type. This deviates from the Transmodel view and from the initial logical data model developed for Salzburg, but is equivalent to the initial solution by means of the JOURNEY-DAY TYPE- ASSIGNMENT table, which allows to define a database view (VEHICLE JOURNEY) providing exactly the same information as defined by the original Transmodel entities. This method is possible at üstra as well as in Salzburg because in EPON journeys defined for one particular day type can be copied for use in other day types. In EPON principally journeys are defined (and identified) independently of the day type identifiers. The day types for which a journey is valid are marked internally by a bitmask amended to the journey record within EPON. The combination of journey and day type results in the Transmodel entity VEHICLE JOURNEY. By splitting this table, the amount of data to be recorded in the database is reduced significantly Physical Database Structure The physical database structure and its parameters are defined by DDL statements included in a number of SQL scripts, which have been developed on the basis of the logical data model in a straight-forward procedure. The structure and definitions of the logical data model contributed largely to a very efficient realisation of the physical database. The basic structure made up of tables, attributes and various constraints (e.g. primary keys and foreign keys and other clauses of the table and attribute definitions) was almost completely determined by the definitions of the logical data model. The physical layout of the database structure and schema objects had to be developed in addition to the regulations already fixed by the logical model. The size and location of database files as well as redo log and control files, the definition of tablespaces, indexes etc. was carried out according to tuning considerations normally applied in the generation of an Oracle database Physical Architecture of the Demonstrator at SLTC Hardware Platforms 19/09/97 Project n TR 1058 Public Document

45 Deliverable Servers Figure 12 overleaf illustrates the description that follows. The system is mainly based on Alpha servers from Digital (DEC), rapid and powerful (64 bits) computers. Their main characteristics are the following: - server DEC Alpha 4100, type 5/300; - 64 bits CPU at 300 MHz; - possibility to install 4 parallel CPU for each server; - cache memory 4 MB; to 576 MB RAM; - system disk 2,0 GB; - 5 disks 4 GB using Raid technology (16 GB available for data); - CD-ROM, TK and 3,5 diskette readers; - FDDI card at 100 Mbits for networking. These computers are evolutive: it is possible to increase their power by adding processors and increase of their working frequency, without changing the hardware or most of the software. The same observation can be made for storage capacity, which can be increased to several hundreds of GB, with an efficient data protection due to the Raid technology. The operating system used on the servers is Open VMS 6.2, allowing to transfer existing applications currently running on VAX/VMS systems. The main servers are located at the headquarters, grouped in a room within the computer department, with the connecting equipment and the storage and backup systems. The servers are organised by function or functional area, supporting all data and applications they require. Some servers support only one activity (vehicle maintenance, development) whereas other support two or more, according to a balance of activity load (production database with scheduling, info-centre with statistics, files and network services...). Public document Project n TR /09/97

46 46 Deliverable 6.1. Headquarters DB servers Equipment mngt Scheduling TITAN Fare coll. Marketing LAN WAN DecNet TCP/IP WinNT Clients Depots (x12) LAN Files Prog. WinNT Clients Files server Figure 12: Architecture of the Hardware at SLTC Local servers in each site support the LAN and file services, but do not support (at the moment) any database. Details breakdown of servers is the following: - Production ( Horgen node): TITAN production database and most connected applications; scheduling tool database; existing old applications and corresponding file servers (will disappear after integration); - Vehicle Maintenance ( Maint ): 3 databases for the maintenance application: development, test and production; - Info-Centre ( Centra ): 1 database for info-centre and a lot of file transfers; - Main File Server ( Pcserv ): no database, only file services, office software and tools; - Development ( Axpdev ): 2 databases, development and Designer 2000; - Local servers in the TUs: no database, only file and network services for the site - Some other servers are used for technical or minor functions: internal mailing, SNA connection (to an outside mainframe for pay-roll), backup facilities, addresses autoconfiguration, etc Client Units The client units used by SLTC are mainly PCs running on Windows 3.1x. More than 600 units are installed, all connected in principle to the data network. In addition to the classical office software (word processor, spreadsheet...), some of them will be equipped with the interactive and graphical applications allowing to access the data stored in the databases. The minimal configuration is the following, bearing in mind that it will evolve according to the rapid progress of this type of hardware: 19/09/97 Project n TR 1058 Public Document

47 Deliverable Pentium CPU, minimal frequency 100 MHz; - RAM 16 MB minimum, 32 MB for computers supporting scheduling applications; - disk 1,3 GB for system and applications; - diskette reader 3,5 ; - CD-ROM reader on some units; - network card 16/32 bits, multi-protocol. All PCs currently run under Windows 3.1 and 3.11 (Windows for WorkGroups) and use the office and network corresponding tools (16 bits). As these versions become obsolete, they should be renewed to use Windows NT4. For the PCs concerned by the TITAN project, Windows NT has been chosen for reliability and performance reasons. One of the main advantages of this operating system is to allow working on several applications simultaneously. On PCs used as clients of the information system, SQL*Net is installed with some tools depending on applications used: Oracle tools (Developer 2000 runtime) for connected applications and Business Objects for info-centre activities Software Applications and Interfaces Software Applications In the Lyon site, numerous applications linked to the operational information system will be re-engineered or created with a development controlled by SLTC. Therefore, these applications will have data structures in a full compliance with the Transmodel-based database. For the other applications, there has been no attempt to modify the internal data storage of the interfaced applications. This is in particular applicable to the scheduling tool Hastus, of which the data is of a key importance and which presents differences in data structures with either Transmodel or the site-specific model, but which will keep its own data structures (unless a future evolution is decided by the supplier). Another example is the personnel disposition software, developed in-house, but of which the conceptual design was completed before the launching of the TITAN project and differs in some cases from the TITAN data structures. Therefore, each interface between an application and the database should include a translation of data structures to or from the TITAN database. The software applications connected to the TITAN database have been listed in the section above. As many of them are new or re-engineered, a huge specification work has been carried out, which has been presented in detail in the Deliverable 5.1 and in the internal report 54. Some of the applications are critical for the system in so far as they are in charge of managing (creating, updating) data to be used by several other applications. These are: - the application for the management of points and of the network description, of which the data is used by most applications connected, i.e. for scheduling, passenger information, theoretical and actual supply follow-up, etc. - the vehicle and driver scheduling tool, of which the data is used by the same applications than in the previous case, plus personnel disposition; Public document Project n TR /09/97

48 48 Deliverable the application for management of calendar of operations, of which the data is used by all applications dealing with supply control and evaluation, on-line control and passenger information, personnel disposition, etc. Some other applications, even of a high functional importance, such as the personnel disposition application, have a lower influence on the data stored. For the personnel disposition tool, this is mainly due to the fact that the concerned data is at the end of the chain (in the current configuration) and the data manipulated are not used by most of the other applications. Other cases refer to data relatively stable (e.g. network common data) or of a minor influence (actual supply follow-up). Many applications will use the data transferred from the database only to convert or aggregate them in other formats (e.g. schedule evaluation or budget follow-up). From the conceptual point of view, these applications do not affect the database, even if some physical tables or views will be filled by them. Some applications will only read the data stored to use it directly: the various passenger information tools, the on-line control system, etc. Finally, the info-centre system, mainly used for statistics, will likely access, by reading only, all data stored in the database Types of Interfaces Several types of interfaces will be implemented to feed and use the TITAN database: - direct dialogue with the database: all the new developed applications will have a direct access to the database tables, using the client-server architecture and the standard Oracle tools. Some of the applications will use working tables; - relational interface: some applications, of which the scheduling tool and the personnel disposition application, use their own relational database on Oracle. The interface will consist of implementing conversion tables or views, that should be read or written according to the direction of the data transfer; - pre-compiler interfaces: an Oracle pre-compiler will be used, allowing to create a C programme containing translated SQL orders able to access (read or write) the database. This will be used especially when treatment processes should be synchronised (e.g. on-line information); - file interface: an SQL programme is implemented, which creates a file (ASCII, Excel file, etc.) able to be read by the application. This solution will be the less favoured, used preferably for off-line applications only reading the data Access Control The whole data system will be managed by a database administrator, from the computer department, in charge of maintaining the data models and the database. The data structures in the database will be grouped by functional domain or application. All tables and other database objects (views, indexes, procedures...) will be created and owned by generic users, each being data manager for one domain. Resource rights are only granted to such users of the base, allowing them to create objects for instance. These managers, defined in the base, will be used only for development and maintenance. The names will be assigned to physical users (in principle from the computer department), responsible of data structures and owning their own password. 19/09/97 Project n TR 1058 Public Document

49 Deliverable The end-users will access the data through private synonyms, hiding the name of the data manager, and having only connection rights. Therefore, they will work on the data, according to their rights, without modifying the data structures. End users of the information system will be identified in the databases they are allowed to access. They will be responsible of their own password and of any action (data access/manipulation) made with this name. This is aimed at ensuring access security, to trace certain operations and to follow-up the use of the bases through Oracle Enterprise Manager. For most of the data, any user will be allowed to read the data, whereas only the department owner of the data will have the right to write. For instance, the Transport Units will have access to the data referring to the stop points they are in charge and to modify it, this data being readable by users from other departments. The Oracle 7 roles will be used to manage the access rights granted to the users. Standard access rights will be defined and attached to roles, which will be in turn assigned to physical users. Changes made in rights granted for a role dynamically affect the rights owned by all users to which the role is assigned. This principle will be used to manage the direct access rights to the database and the menus of the applications developed with Oracle*forms (with some menu items hidden for some roles). Roles will be created by function in each application, to each user being assigned one or several roles. Typical roles will be: - central data administrator for a certain domain, from the operational methods department, in charge for instance of managing network data common to several TUs (point creation, distances) or of calendar programming; this role will have select, update and delete rights, in principle on all tables of the domain; - TU method technician for a certain domain, owning similar rights, limited to a subset of the tables of the domain and to the data corresponding to the considered TU; - operations consultation role, with only select rights granted; - other roles may be defined as necessary in the future (e.g. roles for central or TU marketing functions). The Oracle 7 profiles allow to control the resource consumption: CPU time, volume of data, connection duration... Two main user profiles will be defined in all applications accessing the database: - info-centre profile (see section ), limiting the consumption of CPU time per query, the number of simultaneous connections to one per user, as well as the idle time; - transaction profile, less limiting as regards CPU time but with an idle time more limited. Profiles will be assigned to the roles described above. The database administrator (from computer department) will have all rights to access the database. The access rights (management of the roles and profiles and their assignment) will be defined through a specific application (Oracle Enterprise Manager tool) managed by the computer department: the users will be listed in tables with their name and their assignment to departments and roles. Public document Project n TR /09/97

50 50 Deliverable 6.1. The access control on the client side will be improved by the migration to Windows NT, which requires a user name and a password. On the server side, the access control will not be managed through the operating system, because it has no information on the users. The main access control procedure will therefore use the procedures described below, implemented in the database and in applications Database Schemas Database structure at SLTC All databases are installed in Lyon on DEC Alpha servers. There are several nodes linked by the headquarters local network, each node supporting one or several database instances (operations, maintenance, development, etc.). No distributed database options is currently used. One of these instances is indeed the production "TITAN" database. It co-exist on a server with the database of the scheduling application, with which frequent data exchanges will occur. Sharing a server avoids to use the LAN which would slow down these exchanges. Users and their access rights are entirely handled by the standard Oracle tools. All data will be entered through specific applications, which means that changes (create, update, delete) in the data stored are operated through writing interfaces. Reading of data will be operated through interfaces of specific applications or by using the info-centre system; this should limit the use of SQL requests for development or maintenance purposes. No convincing requirement has been identified to use database schemata Types of Data The Lyon logical data model comprises the following types of data: - production data: this type of data is the most important of the system. All data corresponding to lines, vehicle or driver schedules should be kept and protected in the database. This concerns mainly the network description (points, stop equipment, routes and journey patterns), the details of vehicle and driver schedules, the calendars and the follow-up of actual supply and service quality. All data will be entered and updated through the main applications connected to the database (except for the initial data conversion from old applications); - network data: this concerns data valid for the whole network, such as list of lines, of transport units or depots, which are likely not to evolve often. A specific small application will be developed to manage this kind of data, under the responsibility of a data administrator; - typing data: this concerns the various concepts aimed at classifying and characterising the data: types of stop point, of line, of duty, etc. A specific small application will be developed to manage this kind of data, under the responsibility of a data administrator; - external data: some data will be imported from other systems or databases in order to provide a more comprehensive management information for the operational staff: data on fare controls, passenger counting, consumption, etc. In principle, only aggregated data will be imported into the TITAN database, through specific interfaces; 19/09/97 Project n TR 1058 Public Document

51 Deliverable technical data, referring to the administration of the database, such as data owners (services, e.g. transport units) and users. This will be managed by the database administrator, through a standard Oracle tool; - in principle, no provisional working data is allowed to be stored in the database. Applications should manage their working data (e.g. line version or calendar modification under design) in tables logically separated from the production data, even if the data structure of these tables sticks to the TITAN one. The data which is no-longer valid will not be deleted from the database. The version system should be able to manage current, old and future sets of data, and the connected applications should cope with this system Optimisations Realised on the Logical Model In the Lyon Pilot, the design of a normalised logical model and the optimisation of this model have been carried out at the same time. This is due to several reasons among which the most important was the simultaneous writing of application and interface specifications: for each specification, the complete logical model had to be delivered together with the functional specifications. This process was operated cautiously, using the consistency checking tools integrated in the Oracle designing tools. The design of an optimised logical model leads to modifying the normalised conceptual model from which it is derived. In the Lyon case, the following modifications and optimisations have been carried out: - some entities of the conceptual model are not present in the logical model. In most cases, the conceptual modelling reflects a future need which the logical model does not yet address (e.g. the entities ROUTE and JOURNEY PATTERN are at present merged in one table); - some concepts grouped into a single entity in the conceptual model have been detailed in separate tables, easier to manage (e.g. the address of a POINT is described by several elementary tables); - some entities or relationships have been merged into single tables, mainly in order to provide simplification (e.g. the entities STOP POINT IN JOURNEY PATTERN, TIMING POINT IN JOURNEY PATTERN, TERMINUS and WAITING POINT have been grouped in the table describing POINT IN JOURNEY PATTERN); - intersection tables have been introduced to describe many-to-many relationships, for instance for the STOP AREA to SALES POINT or PUBLIC SITE relationships; - some entities have been adapted to the fact that the TITAN database will only store aggregated values for some statistical data (e.g. total recorded during a specified period of time); - some multi-column primary keys of tables have been replaced by an artificial identifier, in order to facilitate management of foreign keys in related tables (e.g. for VEHICLE SCHEDULE); - for performance reasons, some user-defined identifiers have been qualified as user name and replaced as identifier by an internal number (e.g. for JOURNEY PATTERN); - other identifiers may have been modified for other reasons (e.g. BOARDING AND ALIGHTING); - decisions have been made on how to describe sub-types and super-types of the conceptual model (e.g. sub-types of SPELL are described by a flag in the table); - as a result of the denormalisation process, some redundant information will be stored and controlled in the database, in order to support better performance of data access modules. This will result in redundant tables or columns, by replication of Public document Project n TR /09/97

52 52 Deliverable 6.1. information or addition of derived data (e.g. planned passing time, figures summarising the evaluation of schedules, etc.); - the tables corresponding to the main concepts will include the recording of the user having operated the last modification, together with the date, in order to allow a better control by the database administrator in case of problems Physical Structure of the Database As mentioned earlier, the databases are installed in Lyon on DEC Alpha servers running under Open VMS. The management system is Oracle 7, of which the current release will be upgraded before the final integration, at least to the version These characteristics are used for the TITAN production database and for other database instances (e.g. maintenance, personnel management, etc.). The bases are organised on the disks in order to store separately the management systems, the applications and the data. Large (50 MB) System Global Areas (SGA) are used to share memory, in order to improve performances. Figure 13 overleaf illustrates the description that follows. A lot of tablespaces will be used in order to balance the input/output activity. For instance, each base instance will normally have the following standard tablespaces: - SYSTEM: mandatory, contains the data dictionary; - TMP: for temporary data which are produced by some complex SQL requests; - RBSEG: for storing of rollback segments; - DATAxxx: containing data referring to one main domain or application (e.g. network management, scheduling...); - INDxxx: containing the indexes per main domain or application. As far as possible, the tablespaces for data and for indexes are not installed on the same disk or disk array, in order to balance the input/output activity. In order to control the storage of data into tables and indexes and to minimise the number of extents, all tablespace storage definitions are explicit, which means that each database object will have its own storage definition, including the initial space and the rules for extension (fixed space or percentage). A rough classification may be as follows: - small space for small tables with a very low expected growing rate, such as static tables, tables for types or parameters; - medium space for tables of which the expected growing rate is low to medium, such as lines, depots or driver work categories; - large space for tables with an expected high growing rate, such as points, calendar days, schedules, etc. If necessary, some tables may have their own specific storage definition. The TMP and RBSEG tablespaces are not daily backed up, because they store only temporary data. Database control files are duplicated on 2 or 3 disks, redolog files are duplicated on 3 or more disks. This organisation should allow a good reliability by the balance between disks and a huge flexibility by the use of relatively small tablespaces. 19/09/97 Project n TR 1058 Public Document

53 Deliverable App1 tables App2 indexes Redo log Ctrl file App2 tables Appx indexes Redo log Ctrl File SYSTEM App1 indexes Redo log Ctrl file Appx tables Rollback Segs TEMP Ctrl file Figure 13: The Physical Database Architecture Public document Project n TR /09/97

54 54 Deliverable Communication Architecture of the Demonstrators 3.1. Principles of Integration A data model is a very good foundation for an integrated information system, but an integrated information system is more than just a physical database, which implements this data model. Another main part of the integrated information system consists of the application systems and their interfaces to the database and is described in the chapter above. But there are also some other parts of the integrated information system which are implemented in the database and are related to the interfaces, some of which are specific. In each application system each data item must be identified in some way, normally something like an identifier or a key is used for identification. Often there are more than one possible way of identification and each application system may choose another key for identification. Sometimes there is no "natural" or only a very complex identifier. In these cases artifical identifiers are introduced, which are generated in an application specific way. For the data model and the implemented central database only one (common) identifier has to be implemented, which may be even a new artifical identifier (e.g. a sequence number). Therefore for some keys some or even each application system needs a description how their internal keys could be translated into the common key and vice versa. This problem occurs also for the foreign keys, which are identifying other data items, especially if an application system does not use any explicit foreign key but uses the value of some attributes as implicit foreign keys. Another additional principle is the use of some modelling conventions, e.g. that links may be defined between points but with the convention that not all types of points are used to define links. This restriction is not of the level of a constraint but a simple rule. For some attributes the values in the application system must be translated into a corresponding value in the database and vice versa. For this purpose "corresponding tables" have to be implemented either in the database or in the (interfaces of) the application systems. E.g. at üstra EPON uses 49 time bands (1 to 49) and BON uses 5 time bands (fast, slow, without stop,...). Generic parts of the data model must be instanciated for the specific use of these parts, dependent on their particular use in the application systems. E.g. "TYPE OF LINE GROUPING" has to instanciated with the "purpose" "SCHEDULING", "PI"... 19/09/97 Project n TR 1058 Public Document

55 Deliverable Communication Architecture of the Demonstrator at üstra Networking Concepts Communication Layers between the Interfaced Applications and the Database The general concept of the TITAN-database realization at üstra is to leave the internal data storage of the interfaced application as it is. Internal data structures of the application systems are optimized for the use in that application so that they are not affected. The data exchange process will be done by using interface programs which convert the internal data structures into the TITAN-/Transmodel-format in case of data export by applications, or in cases of data import from the TITAN-database the TITAN- /Transmodel-datastructures will be translated into application internal storage structures. Data of application systems will be stored on several computers, which have to be interfaced to the TITAN-database over the existing network or per ISDN-router (communication device to KGH) as described above. Since the applications connect to the Oracle database on all computers the Oracle connectivity software SQL*Net has to be installed. SQL*Net performs the following main functions: determine where a database is located, because for the interfaced applications the database access will be transparent handles connection and disconnection requests from the client to the server resolve data representation differences between client and server (possibly they use different character sets). The communication layer under SQL*Net is the TCP/IP- or DECNet protocol. On the sending side the communication protocol software builds data packages from the data streams of the SQL*Net-layer to enable the transport on the network. On the receiving side the TCP/IP- or DECNet protocol software analyzes packages received from lower communication protocols and assembles these packages to data streams for SQL*Net Networking Organisation General Rules for Management of the Networking The management architecture describes the organizational concept of data maintenance and data access. First the following rules for information acquisition and exchange have to be stated: - Application system users which produce data which will be written into the TITAN-database are responsible for the data and for starting the data exchange process in time - Information will be acquired only once - Entry of long- and medium-term planned information and their modifications will be centralised in EPON - Entry of short-term occuring modifications (at operating day) will be done directly in the applications Public document Project n TR /09/97

56 56 Deliverable Only selected and cumulated real-time data will be saved in the TITANdatabase - The automated data exchange process will be activated only once a day Management of the Interfaced Components Responsibilities for the components of the integrated system are well defined. For the TITAN-database a database administrator who controls and supervises the availability of the database will be designated. The TITAN-database administrator has to garantuee the availability of the database, to grant database access rights to users, to control the growth of physical and logical objects of the database, archiving actions, and all other actions, which have to be performed. Another task of the TITAN-database administrator will be to coordinate archiving and deletions of obsolete network version data, timetable version data, duty version data and real time data. This process has to be coordinated since applications could have imported the old (obsolete) data, so all participants of the exchange process have to be informed immediately to take the necessary steps for adapting application internal data to the current state. Management of the application systems will remain as it is. Those persons who are responsible for the functioning of the existing systems at present will also be in charge of this job in future. Management of the data acquisition, entry and maintenance process will be modified because of the requirements formulated in the previous chapter (see section ). More data have to be administered in EPON because it is the first application system in the process chain under consideration at üstra. Data which will be planned in EPON will be distributed to all other interfaced applications. To facilitate the maintenance of the topological network beacon points, traffic control points, etc. will also be entered in EPON, which was not the case until now. If different topological data would be maintained in different applications it would be difficult to join these data correctly in the TITAN-database. Since several application systems have different demands on data precision the highest demand on precision has to be fulfilled. The data has to be exactly measured physically by the responsible staff. The high requirements on the data adminstration process make it necessary to assign this work to selected people. The process of exporting planned data to the TITAN-database has to be coordinated with the data import process of the other application systems. For storing the vehicle monitoring data (missed interchanges, larger schedule deviations) in the TITANdatabase no further coordination with other applications is necessary because other systems will not import this type of data with the exception of the MIS, which performs statistical evaluations on these data. Coordination could be necessary to minimize workload of the database. EPON and the AVM should not try to write data to the database at the same time. 19/09/97 Project n TR 1058 Public Document

57 Deliverable Dissemination of information has to be ensured. For this task the TITAN-database adminstrator could be responsible, because he has access on the tables and their definitions to generate a data catalogue for the end users. For more information see Internal Report AP Network Architecture The üstra consists of various organizational units situated in several buildings and areas spread over the city of Hanover. To connect the different sites, a structured cabling system was installed. Figure 14 and Figure 15 overleaf illustrate the description that follows. As transport medium an Ethernet network is used. The Ethernet is able to support the two transfer modes 10 and 100 Mbit/sec. 10 Mbit is the standard band width on the third level of the structured network (connection of the PCs to the floor distributor), which can be increased to 100 Mbit by coupling two computers directly by a switch device. All computers are connected over the existing structured network at üstra. "Structured network" describes an approach of hierarchising a network for easier administration. Three levels are given in the network structure of üstra. Level 1 comprises connections between buildings (e.g. main building and garages), Level 2 comprises connections between floors of a certain building and Level 3 describes the connections on certain floors, between PCs and the Level 2 connection wire. Buildings are connected by optical fibre cable (level 1 cable, see Figure 14). Within each building a fibre optical cable distributor connects the fibre optical floor or department distributors with the fibre optical cable between the buildings (level 2 cable, see Figure 15). The fibre optical floor or department distributor connects to the network segments the PCs and workstations. Within the main building of üstra an Ethernet switch is installed at the information management department. The switch can be used for separating network segments and for connecting computers which perform time and network critical applications so that they can communicate directly without burdening the network segment(s) with their data packages. 11 Internal Report AP 54, Work Package 5, Version 1.1, Specifications of the Pilot Sites, Pilot Site üstra (Hanover), April 1997 Public document Project n TR /09/97

58 58 Deliverable 6.1. Garage Glocksee Garage Vahrenwald ofc ofc KGH ISDN üstra main building ofc Garage Döhren ofc ofc Garage Buchholz Garage Busdepot Süd Figure 14: Level 1 Cable Connections PCs are connected to their specific Ethernet segments (level 3 cable) by copper wire. The RVAS and EFA server at KGH is connected via ISDN to the üstra internal network. üstra Garage Distributor üstra main building Switch Distributor Distributor Distributor Distributor Distributor Distributor Distributor Figure 15: Level 1 and Level 2 Cable On the Ethernet two transfer protocols are in use: TCP/IP and DECNet. TCP/IP is the tranport protocol of choice for ALPHA-Servers and Personal Computers. The micro Vax computers communicate on DECNet protocol. ALPHA servers are also enabled to work on the DECNet protocol. This facilitates the communication between the microvax 19/09/97 Project n TR 1058 Public Document

59 Deliverable computers and the TITAN-database server, because no additional protocol transforming components must be inserted in the network. Other communications are not necessary Data Transfer Processes The logical communication architecture describes how the applications access the TITAN-database by functionalities of the database itself. As described in Internal Report it is not permitted for EPON to write data directly into the PRODUKTION, TEST, RVAS and several PROJEKT-schema database tables 13. The following order of events will be passed through the data transfer process (see Figure 16): 1. The interface program loads the schema names (purposes) from the TITAN_VERWENDUNG table of the ADMIN schema. The ADMIN schema comprises administrative tables which hold information valid for all other "working" schemas (e.g. PRODUKTION, TEST, etc.). TITAN_VERWENDUNG stores information which working schemas are permitted for which applications. This information will be listed in the interface program for user's choice. E.g. within the user interface of EPONs interface program an option menu displays the entries "Produktion", "Test", "RVAS", and "Projekt X". 2. After selection of a purpose, EPONs interface program selects from the respective schema of that purpose the transfer extent (which means a logical name or group name of the tables to be filled) from the table TITAN_EPON_SCHEMA_TU Using the transfer extent name, all tables to be filled will be selected from the table TITAN_TU_TABELLE. 4. Before the transfer process will be started, all table constraints will be disabled by the interface program for the Import-Schema. Probably this will be done by a stored procedure call. An advantage of disabling database constraints is, that the transfer process will be sped up. 5. Now the transfer process from EPON internal data into the Import-Schema of the TITAN database will start. 6. After finishing the import process, all table constraints will be enabled with the exception of those which are defined as disabled in the working schema internal table TITAN_CONSTRAINT. If fatal errors occur a message will be written to a file and sent as message to EPONs interface application and the contents of the tables in the import schema will be dropped. Otherwise a stored procedure will be started which checks complex integrity constraints which cannot be checked by table constraints such as foreign keys. If fatal errors occur a message will be written to a file and the contents of the tables of the import schema will be dropped If after all consistency check routines no errors were detected calculations of several data will be perfomed, e.g. data for the TIMETABLED PASSING TIME. 12 Internal Report AP 54, Work Package 5, Version 1.1, Specifications of the Pilot Sites, Pilot Site üstra (Hanover), April This is forbidden because EPON cannot automatically ensure to keep all the consistency requirements of the üstra specific Transmodel. 14 "PRODUCTION" and "TEST" should be identical to perform a complete test with the "TEST"-Schema. 15 The database command "drop table" deletes the content of the table without restoring old table data. Public document Project n TR /09/97

60 60 Deliverable Then, the stored procedure of the import schema invokes a subroutine which transfers the data from the import schema into the schema of the user's choice, e.g. PRODUKTION and enlarges data, which is permitted to be modified, with versioning data. Before the transfer process starts, constraints of the receiving schema will be disabled to increase transfer performance. After finishing the transfer the constraints will be enabled with the exception of these which are defined as disabled in the working schema internal table TITAN_CONSTRAINT. If there are any stored procedures defined in the working schema table TITAN_EPON_ST_PROC, these procedures will be invoked to fulfill several tasks. As last action the stored procedure will update timestamp value of the table TITAN_MODIFIKATION which defines the point in time when the last transfer of EPON was performed and finished. 19/09/97 Project n TR 1058 Public Document

61 Deliverable EPON TITAN-DB EPON- Data TITAN_SCHEMA_TU 2 TITAN_TU_TABELLE Interface Program 1 Admin Schema TITAN_CONSTRAINT Export of Data Stored Proc. Call "UEBERNAHME" 3 4 TITAN_ST_PROC TITAN_- VERWENDUNG_- EPON 5 Stored Proc. 7 Import Schema Confirmation of Transfer 6 Working Schema PRODUKTION Working Schema TEST Working Schema PROJEKT A Figure 16: Data Import Process of the TITAN Database The AVM transfers its data directly to the PRODUKTION schema, while most data importing applications read the data from the PRODUKTION schema directly also. Possibly RVAS and EFA will import from RVAS schema in an early stage of the Public document Project n TR /09/97

62 62 Deliverable 6.1. timetable planning process, in order to provide preliminary data for some passenger information purposes. The data transfer process of applications which read data from the TITAN database will cause the following events: 1. Steps 1 to 3 of the description above are identical with the events, performed by data importing applications. 2. The interface program will read all data from the defined tables and convert them into the data format of its parent application. 3. After finishing the transfer process the timestamp entry in the TITAN_AKTUALISIERUNG table for the application in question will be updated to document the last point in time an application updated its internal data set Communication Architecture of the Demonstrator at Stadtwerke Salzburg Networks The computers installed in the different sites constituting the whole City Department of Works are connected by Local Area Networks within each site, the LAN's of all sites being coupled by a Wide Area Network linking together the sites (e.g. the central data processing department and department for graphical data processing, the public transport department, the electricity department etc., which are all located in different buildings and parts of the town). A stationary telecommunication line to the City authorities is used for file transfer between the organisational units of the City Department of Works and the municipality, in particular its traffic planning and computer departments. The transport medium used for data transfer is an Ethernet network. The transfer protocol used for communication between the different servers, and the communication processes between servers and their clients, is TCP/IP. Database access from client processes and transfer of the data selected from the database server to the client applications is supported by a communication layer based on Oracle's SQL*Net software (SQL*Net version 2). In the future, a City Information Highway (an Extranet based on the Internet technology) is planned to realise an extensive information network connecting all organisations and public bodies associated with the municipality in the widest sense, and which can serve as a gateway to future nationalwide networks planned in the public sector for the whole of Austria. Intranets installed at various sites will be connected to this public network to facilitate easy retrieval and dissemination of data recorded anywhere in this overall information society. But this concept is to be developed and implemented outside the scope of the TITAN project Data Transfer Processes Figure 17, Figure 18 and Figure 19 illustrate the description that follows. Data transfer processes related to the TITAN demonstration system can be summarized under the following categories: 19/09/97 Project n TR 1058 Public Document

63 Deliverable a) exchange of data between the GIS and public transport applications, b) exchange of data between the City Department of Works and the City authorities, c) exchange of (geographical) data between the City Department and external partners (customers and providers). ad a) One of the main objectives of the TITAN project in Salzburg is to facilitate data exchange between public transport applications and to develop correspondences between public transport data and geographical data. Two components of the future integrated system are currently being implemented for these tasks: - interfaces between the public transport applications (EPON and BAS/VAS) and the TITAN database, and - geographic references of public transport objects, defined in specific correspondence tables within the TITAN database itself. The following Figure 17 shows the concept of the data transfer related to the public transport and geographical data domains. The GIS is already installed with an Oracle database for persistent storage of geographical data. This version of the RDBMS and the database defined on it forms the core of the future TITAN database. The geographical tables defined in the GIS database are therefore identical with the geographical tables of the TITAN database. Graphical Data Processing Dept. TITAN database Public Transport Dept. Oracle RDBMS Scheduling GIS PT planning data tables e.g. Stop Points geographic references Interface EPON PT planning data SICAD Open Geographical data tables e.g. Road Network geographic Operational Analysis references PT operational data tables e.g. Passenger Counts Interface BAS/VAS PT operat. data Figure 17: Data Transfer between the GIS and the Public Transport Applications Public transport data will be delivered by the EPON interface into the TITAN database. Particular tables holding the public transport network and timetable data, as well as all planning data related to these, are defined in the TITAN database in addition to the geographical tables. Each time a new planning status has been defined by the scheduling unit of the public transport department, and these planning data are qualified as production data and have been approved for dissemination by the staff Public document Project n TR /09/97

64 64 Deliverable 6.1. responsible for issuing the new schedule, the EPON interface will write the whole set of planning data into the "IMPORT" schema of the TITAN database. The operational analysis system (BAS/VAS) will import the current network and timetable data from the TITAN database into its own file system before the start of a new measuring and evaluation period. Such periods will never overlap with a change of the timetable, because otherwise no consistent basis for statistical evaluations would be given. The results of run and wait time analysis and of passenger counts, as well as the statistical evaluations carried out on the basis of these results, will then be exported from the BAS/VAS files into specific tables of the TITAN database by means of the BAS/VAS interface. In order to allow for geographical representations and evaluations of public transport objects and related information, geographical references of these objects have to be established to be able to access the corresponding information from the GIS. Particular correspondence tables have therefore been introduced to define the necessary relationships between geographical objects and public transport objects, which are maintained in the GIS and in EPON, respectively. ad b) The TITAN demonstrator aims also at a better exchange of information between the City Department of Works and the City authorities, notably its traffic planning unit. This data exchange procedure consists of the import of demographical, administrational, infrastructural and statistical data related to traffic and transportation planning into the TITAN database, and the export of operational data and evaluation results from the public transport run time analysis and passenger counting functions from the TITAN database to generic data files usable for further evaluation carried out by the traffic planning department. The import of data related to traffic planning is based on conventions of the file formats and the corresponding table structures in the TITAN database. The transfer of data will be initiated by the City authorities which are the source of the corresponding information. The data files in question will be submitted to the database server maintained by the City Department of Works by file transfer via network, and be imported to the TITAN database by means of standard database tools. 19/09/97 Project n TR 1058 Public Document

65 Deliverable City Dept. of Works Graphical Data Processing Dept. TITAN database Oracle RDBMS City of Salzburg Traffic Planning Dept. Traffic planning data tables e.g. Population, Traffic Counts Import Demographic data Traffic planning data GIS (Admin) SICAD Open Geographical data tables e.g. Road Network GIS (User) SICAD Open PT operational data tables e.g. Passenger Counts Export Evaluated operational analysis data Figure 18: Data Transfer between the City Department of Works and the City Authorities The contents of the TITAN database tables holding the results of operational analysis and passenger counts can be exported vice versa in a similar way. The data files generated by standard database export tools or equivalent procedures will be made available for the municipality in a format which can be processed for instance by their standard office automation applications. This data transfer will be done by the data administrator in the City Department of Works as soon as new evaluation results have been imported to the database, or on specific request. The traffic planning department of the City of Salzburg can use the GIS maintained by the City Department of Works, by means of workstations running SICAD Open modules necessary to perform graphical representations and evaluations related to geographical information. The geographical data needed for these functions are stored in the database installed at the City Department of Works, and are accessible for the application running at the municipality via network. ad c) The exchange of geographical data between the TITAN database and the external world will be done on a standardized basis, using the GDF norm and a corresponding interface generating GDF files from geographical data to be exported from the database of the SICAD system for dissemination to customers or other interested parties, and able to read GDF files from external sources and import them into the SICAD database. This procedure may be useful to support commercial activities of the City Department of Works, aiming at the marketability and exploitation of its information base, and to facilitate the overall transportation planning process in cooperation with the City Authorities as well as Federal or National bodies on the basis of a harmonised geographical data description and exchange format. Public document Project n TR /09/97

66 66 Deliverable 6.1. City Dept. of Works Graphical Data Processing Dept. TITAN database Oracle RDBMS External Partners Customers and Suppliers of Information Geographical data GDF data files GIS SICAD Open Geographical data tables e.g. Road Network, Urban Features, PT Information, other Service Info. GDF-Interface Figure 19: Data Transfer between the City Department of Works and External Partners The data exchange via GDF interface will be carried out unregularly and on request, depending on the projects and the commercial relationships with other partners which may evolve in the future once the integrated information base of the City Deopartment of Works has been established Communication Architecture of the Demonstrator at SLTC Networking Concepts Management of Interfaced Components The new OIS will be built around a "Production" database, storing all data collected referring to the production operational plan and the actual results. All connected applications will be interfaced with this database. With the except of the initial conversion of data samples for testing and storing the past data, all data will be inserted through the connected applications. The specifications of each application states which data are accessible for creating, updating, deleting, etc., according to access rights specified for the roles. This also concerns very stable data (such as typing data, list of depots, etc.) for which specific small applications will be developed. Most of these interfaced applications will use a client-server access to the database, which will facilitate this approach. Other interfaces will apply the same principles, stored in programme codes. Only data validated for production will be stored in the database. Many applications will use in addition provisional working tables. The structure of these tables should stick as far as possible to the logical model of the production database. However, the working tables will be logically separated from the production database. 19/09/97 Project n TR 1058 Public Document

67 Deliverable This means that any data inserted or updated should be carefully validated by the user. Therefore, apart from the classical rules for database administration, some specific rules will be implemented to ensure an appropriate data validation before production. The process of interrelating validation and interface transfer processes may be rather complex. For instance, the validation of a line version on the points and lines management application will launch the writing process into the production database, and in turn the interface process of reading the new line version data and transferring it to the scheduling database. All data stored in the production database will be kept and not deleted, at least until the end of the contract with the authority. This principle addresses a requirement from this authority: request on past data should be accessible at any time during the contract. The size of equipment has been designed to cope with such a requirement. This means that the only deletion of data will occur on a big occasion (6 years after system implementation), for which no detailed procedure has been defined yet Physical Network The SLTC organisation comprises many organisational units, located all over the Lyon city and suburbs. The main sites are the depots (each of which forming in principle a TU) and the headquarters. Smaller sites (such as workshops or commercial agencies) are integrated, from the network point of view, to the TUs. All sites are connected together, through a data network composed of a Wide Area Network (WAN) linking the sites and Local Area Networks (LAN) in each site. UTA - dépôt Audibert UTP - dépôt Des Pins UTPA - dépôt Parmentier UTC - dépôt Caluire 64kb/s 64kb/s 256kb/s UTPE - dépôt Perrache UTN - dépôt Alsace 64kb/s 64kb/s 64kb/s B12 Headquarters 64kb/s 256kb/s 64kb/s UTS - dépôt La Soie UTO - dépôt Oullins UTV - dépôt Vaise 256kb/s 64kb/s 256kb/s UTMA - Metro Lignes A/B UTMC - Metro Ligne C UTMD - Metro Ligne D Figure 20: First Level of the SLTC Network The whole network is based on an Ethernet layer with a speed of 100 Mb/s on the headquarters main LAN (connecting servers and every floor switch), while a speed of 10 Public document Project n TR /09/97

68 68 Deliverable 6.1. Mb/s is used on other headquarters LANs (floor networks) and on the TUs and other sites LANs. These LANs are interconnected by a private WAN, composed of specialised telephonic lines, private lines (e.g. in metro tunnels) and PABX lines (through the phone server). The transfer speed on the WAN is 64 kb/s, currently in the process to be increased up to 256 kb/s, before the final system integration. Hardware switches and other connecting boxes are able to support a speed of 2 Mb/s, which is the target speed of the WAN within 2 or 3 years. DEC Alpha servers switch 100Mb/s LANs B12 (by stocks) fddi 100Mb/s switch 10Mb/s Bridge Router kb/s Specialized lines private copper lines private PABX lines Figure 21: Second Level of the SLTC Network The network protocols DECNet and TCP/IP are jointly used, DECNet being used basically for communication from server to server (on which it is native), TCP/IP being in principle used for data request dialogues between client units and the databases implemented on servers. In the future, TCP/IP will replace DECNet on all client PCs under Windows NT (of which it is a native feature). TCP/IP has better connection times, a lower network consumption and is a standard independent of hardware or software suppliers and portable on all platforms. DECNet, which is mandatory to benefit from the cluster facilities of DEC systems (e.g. disk sharing), will be kept only on the FDDI ring, to connect the Open VMS servers together. The Oracle SQL*Net communication layer is used to connect databases and client applications together. The network protocols are therefore SQL*Net for DECNet and SQL*Net for TCP/IP. In both protocols, two versions of SQL*Net are still in service, versions 1.1 and 2.x. The first is now used only for MS/DOS configurations. All new PCs will be equipped with version 2.1 under Windows 3.11 and 2.3 under Windows 19/09/97 Project n TR 1058 Public Document

69 Deliverable NT. The corresponding application and configuration files are stored on a dedicated file server and managed by Oracle Software Manager. To this basic network supporting the TITAN system are currently linked other applications or utilities: file sharing and file transfer systems, mailing system, interfaces to external batch suppliers (accounting, pay-roll...). The servers and networks used for metro on-line control are not linked to this network, mainly for security reasons Data Transfer Processes The processes of data transfer between the applications connected to the database may be classified according to the types of interface listed in section All newly developed applications will have a direct access to the database tables, using the client-server architecture and the standard Oracle tools. Typically, the data entered by the user of the concerned application will be stored in working tables (of the same structure as the database) before they are validated. Examples of data validation processes concern the validation of a line version (new set of data describing routes and journey patterns and associated concepts), of a calendar of a certain type (e.g. the annual reference calendar is frozen in December), or the validation of a new schedule ( put in production ). In the interface, the validation control process and the database writing process are linked, the latter being dependent of the full achievement of the first. The writing process, as well as any reading process used by such an interface, will use SQL statements implemented as PL/SQL stored procedures. The use of such standard procedures ensures that a whole transaction is either successfully completed or completely cancelled (thanks to redolog files). Some applications, of which the scheduling tool and the personnel disposition application, use their own relational database on Oracle. The interface will consist of processes allowing a dialogue between the bases. With the scheduling tool (Hastus), the transfer of data from the production database to the scheduling database will concern every new line version, and will be triggered by the validation of this version. All data to be updated in Hastus may be described in a new line version (including data not strictly belonging to a line version, such as a new depot name or a changed distance). From the confirmation of the version validation and after successful writing of data in the base, a PL/SQL procedure will be launched, which will build views of the data corresponding to the line version. In turn, another PL/SQL procedure, implemented on the Hastus side, will read the views, make the necessary conversions to translate the data according to the Hastus data structures and write the data in the Hastus base. On the opposite direction, a similar process will be implemented when a new vehicle schedule or a new driver schedule is validated and ready to be in production. A specific application calls a procedure stored in Hastus, building views describing the schedule data, then another procedure stored with the production database reads these views and converts them to the TITAN structures, makes the necessary validation controls (which may involve other interfaces) and, if successful, writes the data in the production base. The advantages of such an approach is that the structure of the interface views has been agreed between SLTC and the application supplier, and will be independent of any internal evolution of either Hastus or the production database, and that the procedures Public document Project n TR /09/97

70 70 Deliverable 6.1. are developed on each side, without any intervention from the other side (except for the calling process). A similar procedure will be organised with the personnel disposition application, with daily transfers of data from (calendars, schedules...) and to (result of personnel disposition) the production database. The design of this interface will be however much easier, because this application has been developed by SLTC. Other types of interfaces (pre-compiler interfaces or file interfaces) will be used only to transfer data read from the production database. In these (few) cases, rules and procedures are defined specifically. 19/09/97 Project n TR 1058 Public Document

71 Deliverable Implementation Plan 4.1. Implementation Plan at üstra Installation of the Database The database is the central part of integrated information management system at üstra, to which all application systems are linked. Therefore this database had to be installed before all other interfaces could be tested and integrated. The DDL-Statements needed to prepare the database and its various schemas for different purposes have been spread over 123 SQL-scripts in order to maintain the complex structure of the corresponding physical tables and other database objects in a modular way. The scripts contain well defined storage parameters for all tables and foreign key indexes. Storage parameters define the ORACLE-tablespace where the objects shall be located, the sizes of diskspace to be reserved for these tablespaces and exact values of object growth. Additional scripts have to be defined which will implement triggers and stored procedures. These program modules are still under development. Scripts which insert data into the administrative tables of the ADMIN-schema and the respective working schemas are developed, too. The order of events of the database installation process will be controlled by one installation script, which invokes further encapsulated SQL-scipts. A hierarchy of procedure calls will be run during the database installation. Indexes which are used for high performance access of the Management Information System (MIS) will be defined and implemented dependent on the queries performed on the database. All tables and constraints were installed on a test server. At present the database comprises approximately 2 GB of disk space in its initial configuration with schemas ADMIN, PRODUKTION, TEST, RVAS, and TITANIMP (Import schema). After the successful integration test of the integrated information system the demonstrator database will be installed on a production server to build the productive demonstrator Implementation of the Interfaces The implementation of the interfaces will be done by the software suppliers of the specific application systems. The implementation requires the availability of the database and test data or the definition of test data, resp. Both will be provided by üstra. At the beginning only a small size set of test data will be provided and after the implementation of the EPON interface a full scale set of test data will be derived from existing production data and distributed to the other software suppliers. Therefore the implementation of the EPON interface is the most important and urgent part after the Public document Project n TR /09/97

72 72 Deliverable 6.1. implementation of the database. All other interfaces between the database and the application systems may be implemented and tested independently of each other. The integration of the whole system will follow the same application by application approach, starting with the TITAN database and the interface to the scheduling application EPON Data Conversion and Entering The TITAN database will be filled by newly entered data and by data existing in the current system. As mentioned earlier, only few data will be entered newly in the database. This will be done mainly through scheduling application EPON, the editors of which were slightly extended. This may concern for instance POINTs ON LINK, which may be TRAFFIC CONTROL POINTs. Furthermore some administrative data and first draft test data will be entered into the database via SQL-scripts. Since most of the existing data will be converted to be stored in the database, in order to save entering time, to build test data samples and because all data should be stored in order to address requests from the management and research departments, the conversion will be carried out within the developed interfaces. This concerns mainly: - topology data; - description of journey patterns; - schedule data; - calendar data; - duty and rostering data. This approach facilitates a progressive implementation of the new integrated system without loss of data or inconsistency. This will allow a better modularity of the implementation, of validation tests and of the final system integration Database Evolution The size of the information system is likely to increase in the future. Therefore, the various possibilities to develop the database to cope with new requirements has been studied. The first solution is to increase the size of the servers, which is an easy solution but probably the most expensive. The second consist of distributing the database on several dedicated servers. The initial costs are lower, because of the small size of distributed servers, but requires a lot of efforts to maintain and administrate the servers and huge performances of the network. The third solution consists of increasing the power of the servers, which is cheaper and easier than the two others. The last solution will be used at üstra combined with an archiving concept, to reduce the online-stored data to the needed minimum. 19/09/97 Project n TR 1058 Public Document

73 Deliverable Accompanying Measures The implementation of the TITAN information system will be accompanied by a number of actions aimed at facilitating the validation and good integration of the system and its taking up by the end users. Among others, have been defined: - intensive dialogs with end users for identification of requirements (cf. Deliverable 4.1); - organisational concepts to improve the workflow (cf. Deliverable 5.1 and internal reports 51 and 54); - user manual part of the education and training process (cf. internal report 51); - test plan for validation of the modules and of the whole system (cf. Deliverable 5.1 and internal report 54) Implementation Plan at Salzburger Stadtwerke Installation of the database The Oracle RDBMS and database tools necessary for database administration and development are already installed at the graphical data processing unit of the City Department of Works. The TITAN database to be generated on this RDBMS has already been defined and is implemented on the database server, although some later refinements of the database structure and the physical database parameters may become necessary. The tables derived from the Transmodel-based conceptual data model and the logical model deduced from it are implemented, however, additional database objects like indexes, triggers and stored procedures still have to be developed. Any database tuning considerations have been postponed intentionally to the test phase after the installation of the software interfaces, because the performance of data access and database procedures can practically be evaluated only on the basis of empirical tests under realistic conditions Implementation of the Interfaces The implementation of the interface coupling the scheduling application (EPON) is currently under way. Delivery of this interface program is expected in autumn The interface for the operational analysis system (BAS/VAS) will be implemented afterwards. This module needs network and timetable data delivered from EPON into the database for testing its operability. Its delivery is planned before the end of the year. The GDF interface is currently under development at Siemens, the supplier of the GIS. Siemens aims at a generic GDF interface for its SICAD products which is in accordance with the European GDF standards and applicable in all sites having a SICAD system in place. The "interface" between the geographical data and the public transport objects is rather an interface between the geographical and the public transport part of the TITAN database than a software program. It consists of specific relationships implemented as particular tables in the database, and thus is a matter of additional data entry rather than programming an additional software module for the integrated system. Public document Project n TR /09/97

74 74 Deliverable Data Entry and Conversion The data entry process for the TITAN demonstrator in Salzburg consists of (at least) three different elements: - provision of public transport data, delivered mainly by the scheduling application via interface into the TITAN database; - provision of geographical data from the GIS, including geographical references of public transport data; - provision of demographical and statistical data as well as information on the infrastructure and the overall traffic and transportation system from the City authorities. The delivery of most of the public transport data to be entered into the TITAN database depends on the availability of the interface program which will be able to transfer these data from EPON (the scheduling application) to the database. Before this interface (currently being programmed by the software supplier of EPON) is installed and workable, only a limited amount of test data can be entered into the database. The provision of geographical data from the GIS is already advanced. The main source of these data is the mainframe version of SICAD already in place and working at the City Department of Works. However, the main focus of the GIS was up to now not the public transport area, but the other networks maintained by the City Department of Works. All data necessary for the future TITAN information system were selected from the mainframe version of SICAD and have been transferred to the SICAD Open version installed for purposes of the TITAN project. Additional geographical data were entered into the GIS (and thus the geographical domain of the database) which are particularly important for the public transport and overhead wire network. This refers to the geographical references and structures of stop points, traffic lights, public transport links and lines, and any features and facilities related to these. Traffic planning zones, administrational areas and units and the demographic and infrastructural data related to these were updated with view to the evaluation requirements generated by the TITAN project. These demographical and infrastructural data, as well as the transportation network of the service area, were in addition split into cells according to a geographical 100m x 100m grid, in order to update the attractivity potential plan made up on this fine level to allow for advanced techniques to be applied for optimization of the public transport network. This part of geographical data entry is currently being completed by the assignment of addresses to public transport stops and the corresponding distances and access conditions. Public transport planning and operational analysis data will be transferred later on to the database by means of the interface programs to be realised. Apart from the demographical data needed for the attractivity potential plan mentioned above, no further specific data from the traffic planning domain have been entered yet. The City authorities will deliver these data once the final decision on the extent of information to be integrated in the TITAN database has been taken Database Evolution 19/09/97 Project n TR 1058 Public Document

75 Deliverable The integrated information system built up for the City Department of Works in Salzburg is not a static object with unchanged features remaining stable for all times, but is likely to evolve and will have to meet more and extended user requirements in the future. This implies extensions and modifications of the database structure and capabilities and an increased size of the database itself. There are several categories of factors determining the future growths of the database and its overall features: - the amount of data stored in the database will grow automatically, as empirical and historical data will have to be preserved for statistical evaluations (and cannot be shifted to external archives as long as they are relevant for such evaluations); - the amount of data will be increased the more geographical information and data sets relevant for traffic planning purposes are added to the central pool of information held in the TITAN database; - additional data requirements will increase the extent of the "TITAN" database schema as soon as further public transport applications are integrated in the TITAN demonstrator in Salzburg; - the possible later insertion of the Salzburg project into country-wide or nationalwide information systems initiated by the Government of the Federal State of Salzburg or by the Austrian Government, respectively, may generate additional data requirements which have to be taken into account in the database. As the development of the TITAN database is part of the long-term strategy of the City Department of Works aiming at a more efficient utilisation of the overall information base in the company, additional functions and company areas are likely to be considered for further extension of the company-wide information management system (e.g. demand management, traffic management and marketing). Figure 22 shows schematically the scope of possible extensions of the TITAN demonstrator after the TITAN project itself. Functional areas... included in Transmodel... not included in Transmodel at present implemented in Salzburg at present not implemented in Salzburg future integration PT Network Definition Timetable Planning Vehicle Scheduling Passenger Information (planned service) Statistics (Performance) Interface to GDF Driver Scheduling Driver Rostering Personnel Disposition Automatic Vehicle Monitoring Real-Time Passenger Info. Transmodel Extension? possible integration Passenger Counting Run-Time Analysis Geographical Information Strategic PT Planning Traffic Planning Multi-modal Traveller Info. Demand Management Integrated Traffic Managemt. Public Transport Marketing City Marketing Fare Collection Statistics (Recorded Trips) Figure 22: Possible future extensions of the TITAN demonstrator in Salzburg These extensions will generate the need to adapt the TITAN database accordingly. Possible extensions to other functional areas within the Public Transport domain (shown at the lower part of the left side of Figure 22) are likely to be covered by simple extension Public document Project n TR /09/97

76 76 Deliverable 6.1. of the existing "TITAN" database schema by additional tablespaces and database files. The insertion of completely different domains, e.g. Integrated Traffic Management or City Marketing, to be developed in cooperation with numerous external partners from the municipality and from private service providers, will however generate the necessity to include additional servers and a distributed database. These are options far beyond the current project, but show the possibilities for future evolution and development in favour of improved business processes and a better service for the customers Accompanying Measures The implementation of the TITAN information system will be accompanied by a number of actions aimed at facilitating the validation and good integration of the system and its taking up by the end users. Among others, have been defined: - agreements between the organisations involved in the overall integration project in Salzburg on the common support and utilisation of the demonstration system; - the way of cooperation between these organisations (public transport department and data processing department in the City Department of Works, and the authorities of the City of Salzburg), during the development phase as well as the practical implementation and test stage; - organisational concepts to integrate the TITAN demonstrator in the business processes of the organisational units concerned; - options for further extension and integration of additional applications in the overall information management system; - the need for a user manual and for education and training of the staff in charge of administering the integrated system and of the end-users of the information; - a test plan for validation of the individual modules of the integrated system and of the whole demonstrator, with view to technical validation as well as the compliance with the user needs and requirements identified in the first stage of the project Implementation Plan at SLTC Database Creation The design of all SLTC databases, including the TITAN production database, is carried out using the computer-aided system engineering (CASE) tool from Oracle, Designer This tool is operated on the SLTC standard client/server architecture, PC client units and DEC/Open VMS servers, via SQL*NET DECNet or TCP/IP. The version currently used is the version 1.2 on Windows 3.11, which will be upgraded before final integration to the version 1.3, running with clients on Windows NT 4.x. Designer 2000 is used for modelling and design of entities, relationships, diagrams, etc, at the conceptual denormalised level. It allows to further generate objects at the physical level: tables, constraints, indexes... The use of the Database SQL Generator allows to obtain all SQL DDL (data definition language) statements used to build the physical database, in form of ASCII files. This allows to create the database and all included objects without directly using any SQL statement. All features of the Oracle generators are not currently used, mainly because of lack of time for acquiring the required knowledge of the tools. However, it is planned to use the tool in the next future to generate PL/SQL stored procedures, and applications for end- 19/09/97 Project n TR 1058 Public Document

77 Deliverable users using the Forms/Reports/Graphics generators. Further, the Web generator, allowing to produce interactive applications to be used through Web navigators is likely to be used Database Optimisation A very important step of the database implementation is the optimisation (or tuning) phase of the database. This covers the tuning of the running system of the database, without any consideration for the contents of data. The first step of tuning concern the correct writing of SQL statements included in applications. Some rules have to be respected in order to ensure a good data access: SQL syntax, use of explicit cursors, avoiding of complex operators ( in, union, operators with many sub-queries...), order of the tables in the join clauses (in order to avoid full scanning of large tables), appropriate use of indexes, etc. Most of this work is normally to be performed during the development stage, but it should be maintained and completed during the test and integration phases. Standard tools provided by Oracle will be used in Lyon for that purpose: optimizer, xplain and tkprof statement analysers. The next step is the tuning of the database itself, with all connected applications running. It is recommended to tune the shared memory usage of the database, especially the SGA. Once again, the Oracle tools will be used (bstat/estat utility, process monitor...). Some of the most important parameters are the number of database blocks used to store data in the SGA, as well as the maximum number of SQL statements possibly stored in the SGA. Maintaining these parameters at a sufficient level allows to avoid memory contention and loss of performance. Input/output contention may occur if the distribution of the various files composing the database is not appropriate. The use of numerous disks reduces the input/output activity. For that reason, the solution chosen in Lyon favours for instance to store 20 GB of data in 10 disks of 2 GB each, instead of 4 disks of 5 GB (independently of the security reasons for such a choice). Other tuning aspects that should be frequently checked by the database administrator during the system life cycle are the following: - free space left in tablespaces; - number and size of extents (fragmentation); - usage and size of rollback segments; - network traffic and its influence on the listener and server processes; - SGA parameters. Public document Project n TR /09/97

78 78 Deliverable Data Conversion and Entering The TITAN database will be filled by newly entered data and by data existing in the current system. As mentioned earlier, all new data will be entered in the database through one of the interfaced applications. This may concern for instance: - typing data or data valid for the whole network (lines, TUs, depots, etc.), which will be entered through dedicated small applications; - operational data created or updated by the other connected applications: calendars, new schedules, etc. However, some existing data will be converted to be stored in the database, in order to save entering time, to build test data samples and because all data concerning the current contract with the authority should be stored in order to address requests from this authority. The conversion will be carried out thanks to specific conversion routines developed by the computer department. This concerns mainly: - stop point data; - description of journey patterns; - vehicle schedule identifiers and main characteristics and evaluation (for use by calendar management and budget follow-up); - details of existing schedules, which will be converted in the format of the scheduling tool for early tests and to the database format. However, the first conversion attempts clearly show that the migration from old data structures, defined for specific isolated applications and having to cope with strong computer limitations, to new, clean, exhaustive and consistent data structures makes a lot of problems. The software or hardware limitations forced the user of old applications to create fictitious data or to pervert the normal definition of data. Typical examples were found in the use of fictitious stop points to describe mapping or timing points, confusions between the stop point and stop area concepts, the use of the line concept to describe driver groups, etc. Converting this odd data, often ancient, requires not only to write conversion routines but in addition to implement a process to make the data clean and complying with the Transmodel-based data structures. The study of this problem has recently started and the procedures (which should involve mainly operational users as well as some computer department members) are not yet defined. However, the choice of this approach facilitates a progressive implementation of a new system, with old and new applications temporarily running in parallel, without loss of data or inconsistency. This will allow a better modularity of the validation tests and of the final system integration Database Evolution The size of the information system is likely to increase in the future. Therefore, the various possibilities to develop the database to cope with new requirements has been studied. The first solution is to increase the size of the servers, which is an easy solution but probably the most expensive. The second consist of distributing the database on several dedicated servers. It is less expensive, because of the small size of distributed servers, 19/09/97 Project n TR 1058 Public Document

79 Deliverable but requires a lot of efforts to maintain and administrate the servers and huge performances of the network. The third solution consists of increasing the power of the servers, which is cheaper and easier than the two others. The last solution has been chosen by SLTC for the future. The company information system is already shared between some dedicated servers (TITAN production database and scheduling application, vehicle maintenance, info-centre, development, file server...) and it is not desirable to install larger servers (e.g. mainframe). The hardware equipment chosen is able to be upgraded by increasing the number of CPU up to 4, and the RAM to more than 1 GB. In addition, the software features from Oracle (Parallel Query Option and Parallel Server Option) allow to distribute parallel statements such as data access, index creation, table loading, etc, which makes easy the addition of supplementary CPUs. This solution is expected to meet the evolution of requirements in the mediumterm Accompanying Measures The implementation of the TITAN information system will be accompanied by a number of actions aimed at facilitating the validation and good integration of the system and its taking up by the end users. Among others, have been defined: - working groups mainly composed of end users for identification of requirements (cf. Deliverable 4.1); - ergonomy standard chart for development of applications (cf. Deliverable 5.1 and internal reports 5.1 and 5.4); - user manual part of the education and training process (cf. internal report 5.1); - test plan for validation of the modules and of the whole system (cf. Deliverable 5.1 and internal report 5.4). Public document Project n TR /09/97

80 80 Deliverable Conclusion As mentioned in section , the implementation is still in progress at all three pilot sites (see section 1.5. "Status of the Work in the Pilot Sites"). This deliverable presents the first part of the implementation and planned next steps of the implementation, which are not the final results of the implementation. So far no major problems in the implementation process have occured. At this point in the TITAN/1 project, the experiences of the pilot sites described in this deliverable, which are related to management of large software engineering projects with many external software suppliers involved, will be interesting for future implementations of Transmodel-based integrated information systems by other Public Transport operators. However, the validation of Transmodel as a reference data model is not the purpose of this report. The company-specific conceptual data models, developed with Transmodel as a reference and based on a thorough analysis of user needs performed by the sites, were transformed into logical models to be used as a starting point for the definition of the TITAN databases. The implementation process performed so far has largely benefitted from this sound preparatory work. The logical data models developed in the specification stage proved to be an excellent basis for the database design in all three pilot sites. The database development and implementation process was carried out efficiently and led to results on a high quality level, facilitated by the methodology and reference structures inherent to the Transmodel principles. The specification and implementation of the interface programs needed to couple the transport applications to the central TITAN databases realized in the three sites was also largely supported by the company data models and the knowledge and experiences gained from the analysis and data modelling activities. Thus the software developers were provided with very detailed and comprehensive specifications, which facilitates the programming work and keeps the frictional losses between the specification stage and the implementation stage to a minimum. These advantages are however mainly gained from a proceeding in accordance with a sound methodological approach, advanced technical principles for systems analysis and software development, and a tight project planning (but independently of any detailed semantical contents of the Transmodel standard). Further contributions to the validation of Transmodel itself are expected from the integration process at the pilot sites. This feedback will be presented in the next deliverable 7.1 "Implications of Pilot Verifications on the Reference Data Model". Another interesting experience is that although the Transmodel approach does not mandate any particular choice as regards the physical implementation of information systems in practice a common approach for the physical architecture was developed by using market standard products (e.g. server hardware, database management system and design tool, network protocols, etc.) and exchange of experiences in the design process. Never the less, many differences appear, as regards the details of implementation. This shows that the common Transmodel approach is compatible, as far as the implementation aspects are concerned, with a variety of site-specific requirements. 19/09/97 Project n TR 1058 Public Document

81 Deliverable Bibliography CEN TC278/WG3: Reference Data Model for Public Transport, version CEN prenv , Paris, November 1996 CORD Project V 2056 / WRATHALL Chris: High Level User Requirements & Quality Factors for a European IRTE Deliverable No D007 - Part 1, March FOSTER Ted, et al.: Overall Requirements of the Pilots Titan Deliverable 4.1 (Version 2.1), February 1997 JESTY Peter, et al.: Architecture Assessment Guidelines CONVERGE (project TR 1101) Deliverable No. DSA3.1, February 1997 PATRIKALAKIS Yannis, et al.: Titan Evaluation Plan Titan Deliverable 9.1 (Version 6.0), May 1997 PFITZER Wilfried, et al: Description of Pilot Sites Specifications TITAN Deliverable 5.1, July 1997 RYD Per-Olof: Recommended Definitions of Transport Telematics Functions and Subfunctions CORD (project V 2056) Deliverable D004 Part 3, December 1994 Public document Project n TR /09/97

82 82 Deliverable 6.1. List of Abbreviations This list comprises all abbreviations which are not common known to the public. For instance CPU is not listed, because all people interested in information systems know the meaning Central Processing Unit. AP Activity Package AVM Automatic Vehicle Monitoring DB DataBase DDL Data Definition Language ERD Entity Realtionship Diagram FDDI Fibre Distributed Data Interchange GDF Geographic Data Files GIS Geographical Information System GVH Greater Hanover region transport ISDN Integrated Services Digital Network KGH communal federation of greater Hanover area LAN Local Area Network MIS Management Information System ODBC Open DataBase Connectivity OFC Optical Fibre Cable OIS Operational Information System OM Operation Methods PL/SQL Procedural Language extension for SQL RAID Redundant Array of Inexpencive Disks RDBMS Relational DataBase Management System SGA System Global Area SLTC Sociètè Lyonnaise des Transport en Commun SQL Structured Query Language SSTW Salzburger Stadtwerke TITAN Transmodel based Integration of... TU Transport Unit WAN Wide Area Network 19/09/97 Project n TR 1058 Public Document