Download references

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.