Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Entity–attribute–value model wikipedia , lookup
Extensible Storage Engine wikipedia , lookup
Open Database Connectivity wikipedia , lookup
Concurrency control wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Relational model wikipedia , lookup
Functional Database Model wikipedia , lookup
VAS – a Mass Transit Information System in C# Sándor Juhász, Kálmán Marossy Department of Automation and Applied Informatics, Budapest University of Technology and Economics, Faculty of Electrical Engineering and Informatics, 1111 Budapest, Goldmann György tér 3. IV. em., Hungary E-Mail: {juhasz.sandor,marossy.kalman}@aut.bme.hu Abstract – This paper describes the VAS (Vehicle Application Support) software, which was developed to create and edit the background database driving the intelligent public information system used on the board of mass transit vehicles. The software is built on the .NET framework, and exploits its strength through the C# language. This application is an example of employing the different capabilities of the .NET Framework in the industry, like database support, convenient user interface elements and interoperability features. II. The intelligent on-board system is mainly responsible for presenting audio and visual information to the passengers, but depending on its type, it can also collect and process some vehicle specific information like position, load, and engine data. Fig. 1 gives an overview of the entire systems. The heart is the on-board controller, the role of which is to automate the information system on the board. These functions include driving the internal signs, making the next stop or warning announcements, tracking GPS data and inspecting vehicle health. Keywords: intelligent vehicle systems, database editor, visual data edition, industrial application I. STRUCTURE OF ON-BOARD SYSTEMS INTRODUCTION The signs attached to the controller trough the VMX bus (Vultron Message Exchange, an industrial standard bus) are responsible for displaying the messages. It is important to note, that the system is built up in a modular way, which allows integrating different number (up to 32) of signs of any type, from any manufacturer in any combination. The products of the following sign manufacturers have been tested with the system until now: Vultron, FOK-GYEM, Alphavision, Aditech, Buse, AEG, and Ameli. The VAS (Vehicle Application Support) On-Board Database Editor is a complex software tool meant for preparing and editing the background database used on the board of vehicles equipped with intelligent public information systems. The created data is transferred into the vehicles either on different memory cards (e.g. flash cards), or with the help of a wireless radio transmission network (WLAN). When on board, the data are interpreted by the controller of the public information system driving the on-board sings and the announcement system. The sound controller is responsible for the announcements. It has its own database containing all the possible sound fragments, and it will play these sounds through an amplifier according to the orders of the main on-board controller. The main purpose of the VAS On-Board Database Editor is to allow easy creation and edition of the sign images, the sound records, and GPS positions belonging to the different stops of the different routes served by the vehicles. The VAS Editor achieves this goal by providing a user-friendly, graphical interface to the operators, who can create onboard databases from the grounds, or can customize and update business data imported form their existing systems. The Editor also includes a national language support to make its usage easier in the different countries. At the moment the Editor is available in English and in Hungarian languages. The VAS system also includes comprehensible auxiliary tools for font and picture creation, as well as for flash card writing. GPS receiver handling and radio communication capability allows some advanced functions like vehicle position tracking and reporting to a central location, wireless upload and download of different data, or scheduled announcements based on the vehicle location. There is also a possibility of installing the software on multiple sites. In the multi-site version, the database of the whole fleet is edited in a central location, and this master version is downloaded to various sites, where local modifications are allowed before transferring the data to the vehicles. Fig. 1. Overview of the on-board system 1 III. SOFTWARE ARCHITECTURE select them according to their needs. The VAS software is responsible for the creation of the onboard databases for both the main and the sound controller. To allow easy maintenance and extension the core software was implemented in a modular architecture. The.NET platform of Microsoft has been chosen to host the modules, because it provides the newest technology for system integration with a comprehensive structure, and also provides a wide range of ready components for system integration, and makes the seamless cooperation of modules implemented in almost any programming language possible. The software system was designed in a way allowing the exploit of all the function by the use of one single conventional personal computer. This covers all the data import and export, font, picture and sound creation and editing, as well as on-board database and flash card creation. There is also a possibility for verifying the sign images and announcements for each stop and each route before testing them finally on the vehicles. The main component is the On-Board Database Editor itself, which allows building databases for different vehicle configurations. A configuration describes the hardware components (GPS, modem, fare box, etc.), the number and the type of the different signs on the board, the type of the announcement system, as well as all the visual and audio data for each stop and each route covered by the vehicle. The data also include some administration fields about the creation (name of the operator, date and time, id). The Editor was mainly designed for human interaction, but it also includes some important automation for sign image creation based on templates. The Editor is able to import previous data coming for the existing systems and has a number of output formats (extensible on demand) allowing to export old edited data back to its original format, as well as to any new systems. This latter feature allows a continuous and seamless transition of even a bigger fleet from the older systems or technologies towards any new hardware types. In the single computer version, all functions of the system are available from a single PC. The data concerning the stops (identifier, name, GPS location), the routes (identifier, name, stop sequence, stop distances), the onboard databases (sounds, sign images, other data depending on the hardware configuration) are stored here, and their edition, review and download is also handled by the same computer. A. Single-Site System B. Multi-Site System The block schema of the multi-site version is shown in Fig. 3. The basic design concept of the system was to fulfill the need of storing and handling all the data concerning the intelligent on-board system, but in order to provide higher flexibility the system must allow modifications at different sites in the same time. These modifications are made by the staff working directly with the vehicles in case of temporary and local changes (vehicle reconfiguration or replacement, detours, custom routes). To maintain the integrity of the whole system, these modifications are controllable, and temporary in nature. The software already supports, or is adaptable to support the products of any chosen hardware manufacturer. It is able to handle any number of editable fonts, and support various different sound formats including the most popular .mp3 sound compression. Central Office The storage and the edition of the data are done in a central location (marked with Central Office in Fig. 3). There is a continuously operating data storage server (file server) and a workstation capable of editing the master data in the central office. Fig. 2 shows the flows of the different types of data through the On-Board Database Editor. Although most of the functions are tightly integrated into the Editor, but some features like font and sound editing or flash card writing are handled by external programs allowing the operators to The role of the central server is to store the data concerning the stops (identifier, name, GPS location), the routes (identifier, name, stop sequence, stop distances), the onboard databases (sounds, sign images, other data depending on the hardware configuration). The sound fragments building up the totality of the announcements and the logs coming from the remote locations are also held here. ABC ABC Data of the Runs ABC Fonts Sounds VAS On-Board Database Editor Data Export Controller Flash The software being able to show and edit these data is installed on the workstation. Although the software may be installed to more than one computer, but it is important to note that the edition process can be in progress at only one of them at a time. The changes made here are directly written to the master database. After finishing the changes, Sound Flash Fig. 2. Overview of the software architecture 2 External Site Central Office PCMCIA 64M INSERT THIS END controller database File server (master DB, sound files, differnce file form the external sites) Workstation for editing the database PCMCIA 64M Workstation for editing the database INSERT THIS END sounds LAN External Site PCMCIA 64M INSERT THIS END controller database internal network of the company PCMCIA 64M Workstation for editing the database INSERT THIS END sounds temporary connection 64M PCMCIA External Site INSERT THIS END 64M Workstation for editing the database PCMCIA controller database Laptop (test, verification) INSERT THIS END sounds Fig. 3. Block diagram of the multi-site system the VAS system allows to publish the updated data (it becomes visible to the remote locations). The publication is not done automatically, that is why the current (possibly temporary, inconsistent) state of the edition process has no direct effect to the remote locations. physically to the on-board controller of the vehicles for coping. As urgent changes may promptly be required (detours, stops skipped temporary, transfer changes, traffic associated to special events), the local staff can do the necessary modifications in a quicker and more flexible way. These modifications are temporary in nature, so it is possible to write them to flashcards, but do not effect the master database. The local changes will persist until a newer version (modified later in the central than at the remote site) becomes available at the central location, which will overwrite all the local changes made. The persistent changes must be requested to be done in the central office on the master database. To avoid uncontrolled changes of the master data, at each save and at each flash card writing the local and the master data is compared at the remote sites, and the changes are logged in a human readable form, and finally the logs are transferred back to the central location. Based on the logs, the changes made at the remote sites become traceable and verifiable at the central office, too. Remote Sites The edited data is transferred to the vehicles (by means of flash card or wireless transmission) at the remote sites (garages, depots). At every site the VAS Editor software is installed to a workstation. The software is capable of showing and editing the database locally, and also allows transferring the data to the vehicles. The working cycle of the VAS at the remote sites is the following: At each start, the program verifies whether the central (published) database has changed. If so, the changes in the master database are replicated to the local storage. If the central location is not available, or there are no new data present, the user will be able to continue working with the local data. Initially the responsibility of the staff at the remote location is limited to transferring the data prepared in the center to the vehicles. In every vehicle group two data units (one controller and one sound database) must be associated. If there is no wireless transfer possibility present, the databases must be written to flash cards, and be taken IV. STRUCTURE OF THE DATABASE To reduce the redundancy in the database the configuration data are created in two phases. First, the background data common for the whole vehicle fleet must be built up, and 3 then this data must be customized for each vehicle configuration. announcement systems can be grouped into one configuration. It is not obligatory to put all the vehicles with compatible on board system into the same configuration, the grouping can also be made considering other points of view (grouping vehicles belonging to the same administration unit, to same depot, or to same logical group). A. Background Data The background data consist of the followings: sign types, fonts, pictures, sounds, stops and routes. Each configuration includes two categories, one describing the configuration of the mounted signs, and the other enumerating the routes. The sign types are predefined, adding more types is only possible by reconfiguring the software. A sign type is described by it size, a gap parameter (if a bigger sign is composed of smaller ones), the default number of fields (signs can be horizontally and vertically divided into fields), and a flag that determines whether the sign images are based on characters or on pixels. The content of every field of each signs can be given. Simple text and special content, like destination name, route code, or predefined text for a stop. Scrolling phases can be also defined. The routes defined as background data can be added to a configuration. Then the sign content of each stop can be customized, if necessary. Different types of fonts can be used on the signs. The font category includes information on the name, the height, the width as well as the name and the path of the data file belonging to each font. V. USER INTERFACE The dot-matrix based signs are not only capable to present characters of the defined fonts, but can also show pictures. Like fonts, this category is also described by the name, the height, the width and the name and the path of the data file belonging to each picture. The On-Board Database Editor possesses a user-friendly interface to edit the background and the on-board data. As in Fig. 4 can be seen, the main screen is divided into 4 mayor parts: there are two tree-structure controls on the left, and two bigger panels on the right. When editing the configurations, unique announcements can be associated to each stop of all the routes. These sound fragments can be either in mp3 or voc format. The left part of the user-interface reflects the concept of the separation of background and on-board data. The background data navigation panel is occupying the upper-left part of the screen. The different types of background data (stops, sounds, fonts, pictures, routes) are put in a tree-structure to allow easy navigation. A stop is a geographical spot characterized by a GPS location that can be used as part of one or more routes. As more stops can belong to a bigger geographical location (big junctions, crossings, opposite side of the streets), the stop not only have a name, but they possess an identifier as well. The identifier is always unique (e.g. Central Park NW, Railway station stall 5), while more stop can share the same name. The on-board database navigation panel is occupying the lower-left part of the screen. The different configuration using the same background data are shown in a treestructured view to allow easy navigation. A route is a sequence of stops; it is used as the basic unit of the messaging and of the announcement systems. The back and forth direction of the same path are counted as two different routes. The upper-right part of the screen is destined to make the required edition work. The editor panel always shows the properties of the items chosen in the left panels. The changes made in the panel take place promptly; no additional validation is required. B. On-Board Data On the lower-right part of the screen the auxiliary panel can be seen. Its main purpose is to allow navigation between the sub-items. It might be empty, showing the overview of all the scrolls of each sign, or might contain a map for graphically representing the stops and routes. The edition of on-board databases can be started after creating all the background data. The on-board databases are prepared configuration by configuration. The vehicles possessing compatible sign and 4 Fig. 4. User-interface of the editor The edited database can be saved to or loaded from an mdb (Microsoft Access) format file, thus the data can easily available by third-party programs too. Because of using a standard format, the big databases with several hundreds of routes may be slow to save. For this reason there is a quick save function, which stores the whole database in a proprietary format, which is very fast and produces a compact binary file. data can be done through the standard user interface of the chosen database management system. The serialization method in the framework can quickly produce a compact binary file, which stores the state of the whole application in one step. This is very useful when implementing functionalities like quick save, and is effortless to implement from the programmer point of view. Writing all the code needed to load and save the whole state of an object is only history: the automatic serialization saves not only the state of a single object but a whole object tree following the references. VI. EXPERIENCES WITH THE .NET FRAMEWORK For the development of the VAS application we have used Visual Studio .NET, and the C# language. Both of them can save time to the programmer: Visual Studio with the new form designer and improved code editing features, and C# with the new language elements missing from older programming languages. Of course besides them, the .NET Framework itself played also a key role in the project. Because of the garbage collection in the .NET Framework, the development time of this version of the application was much shorter as compared to developing earlier versions. Although automatic deallocation of unreferenced objects can help programmers a lot, to avoid slow operation some attention must be paid to release references to unused objects, and to reuse objects with large memory footprint where it is feasible. The data handling mechanisms in the framework are very easy to use. DataSets provide the possibility of storing the data in a commonly used relational database, like Microsoft Access or SQL Server. First of all, this can help us to maintain the compatibility between the saving formats of the different versions of our application. Secondly, exporting data to and importing data from other applications or new extension modules are very easy, which can be an important factor in designing industrial applications. Thirdly, an exceptional manual edition of the The user interface was created using WinForms. It is much powerful than its predecessor, and the form designer in the development environment has improved a lot. We also took benefit from custom controls (e.g. the signs in the editor panel), which are much easier to use than ActiveX controls. 5 The C# language has valuable extensions to either Java or C++. The properties and their get/set method is very elegant and good language element. The new foreach statement was also frequently used. This is a very convenient way to iterate through object collections, and this application is very rich in this type of data structures – if one looks only upon the user interface of the application, a lot of tree and list elements can be found. This complex software has a single-site and a multi-site version. In both of them, the edition of all the vehicle data enumerated above can be made conveniently through a user friendly interface. In the multi-site version beside the central edition of the whole database, local changes are allowed in an external site to be able to handle special cases. The application uses the .NET Framework, which is a perfect choice for applications with intensive database usage, user friendly interface and interoperability needs – like the VAS software. In addition, interoperability and compatibility is a great concern in this application. Fortunately the .NET Framework addresses these issues, and we could use our old COM components, as well as other older software parts (e.g. the flash card writer) in the application. Visual Studio .NET also helps a lot with hiding the necessary extra work with COM components: using a COM component in an application is as simple as if .NET classes would be used. VII. ACKNOWLEDGMENTS This work has been supported by the fund of the Hungarian Academy of Sciences for control research and the Hungarian National Research Fund (grant number: FKFP 0078/2001) CONCLUSION The VAS application presented in this paper is a real world application used in the industry to edit and create databases of intelligent vehicle systems, and publish these databases with writing the main and sound controller data to flash cards or transmitting them with the help of a wireless network. The application is also able to test the different types of signs with the chosen text and fonts, and with additional tools not only fonts and pictures can be created, but sound for the different announcements can also be recorded and edited. REFERENCES [1] [2] [3] [4] [5] [6] [7] 6 Archer, T, Inside C#. Microsoft Press, 2001. Zhao, Y., Vehicle Location and Navigation Systems, Artech House Inc., 1997. Bureau of Transportation Statistics, <http://www.bts.gov> Intelligent Transportation Society of America, <http://www.itsa.org> ITS Online, <http://www.itsonline.com> Gabriel, J. et al., Professional .NET Framework. Wrox Press, 2001. Fedorov, A., A Programmer’s Guide to .NET. Addison-Wesley, 2002.