DIVA 4 and EFA 10 - Paradigm Change at the VVS

10 mdv news II/2011
AVM and Vehicle Scheduling Light at VRN
Project
Earlier this year the Rhein-Neckar transport authority
announced an international request for
proposal for the creation of a regional AVM. The
requirement was a client-capable AVM, which
would allow for the participation of multiple
small to mid-sized bus companies in the VRN
region. Also salient to the project was the generation
of real-time information for the journey
planner and connection guarantees, the latter
of which needed to work with both AVM internally
and AVM externally (with third-party AVM
systems).
Because the existing vehicle equipment varies
greatly from operator to operator, from the
non-existent to modern AVM-capable ticket
printers, the AVM system required by the VRN
had to be quite flexible. The AVM system would
need to both communicate with diverse existing
systems and also provide vehicle equipment,
if necessary.
The real-time information collected by the AVM
would then flow via the VRN data platform (still
in planning) to the journey planner and also to
third-parties to guarantee connections and
provide passenger information to stations.
Another requirement first became apparent
during the specification phase in collaboration
with future AVM clients. The proposal was for
an AVM that would work with block information
for the operator and that would calculate
real-time information. As can be expected,
smaller clients often do not have their data in
electronic form, or it is in a form that cannot be
read over a standardized interface.
As a consequence, a fast and convenient way
had to be developed to collect the block information
of smaller clients for use in the AVM system.
AVM Light
mdv entered the request for proposal with the
AVM that was described in the last issue of mdv
news and was successful. After the specification
phase in spring, development hit full stride
during the summer. In contrast to the first version
that was installed in the Vogtland Region,
a number of enhancements and improvements
were included in the newer version. While the
first version of the AVM was still partly supplied
by partners, the second version was developed
solely at mdv.
As described above, one of the requirements for
the VRN AVM was the participation of multiple
transport authorities. For this reason, the AVM
was developed to become a client-capable system.
It is now possible to have an instance of
the background system simultaneously used by
different operators without them being able to
see each other’s data. Using rights management,
the functions and data accessible to each
user can be separately defined. Functions rights
are set similarly to the DIVA 4 roles, with each
system function defined for user’s ability to
read, write and delete. Also parallel to DIVA 4,
data rights are defined in groups where rights
administrators can determine, up to the level of
operating branch, which data can be read. A
user can be assigned to one or more roles and
groups. This provides the operator with the flexibility
needed to depict the range of constellations
that happen in the real world.
The second major innovation is the completely
refashioned driver terminal. While the Vogtland
version still had a platform-independent
browser application, the new driver terminal is
an Android-based app. In this way platformindependency
was traded for a solution to a
few issues that are caused by a browser. At the
same time, a few functions were first possible
because of app technology, which could not be
implemented in a pure browser application.
Use in Vogtland has shown that network coverage
in parts of the countryside does not reach
the lowest standard called “EDGE”. A pure
browser application would obviously not be
possible in places with no network, and drivers
could not sign on to a new trip at the end of the
first. In this type of situation, an app is much
more tolerant. Even when the app cannot
directly transfer the sign on data, it can still save
the information and then send it in the background
as soon as reception is available again.
One example of a new function made possible
with the app is access to the telephone infrastructure,
where acoustic signals can be sent. In
the future, it will be possible to access USB- and
Bluetooth interfaces on third-party devices like
ticket machines or vehicle displays.
An innovation that is invisible to control center
staff and drivers is the powerful administration
environment. This allows AVM operators the
ability to manage data in the AVM and have
insight into the internal processing. Planned
timetable data can be loaded in VDV 452 and
TransXchange formats or directly from EFA data
into the AVM. Other data for which there is no
standardized exchange format, like vehicle and
driver lists, can either be entered in the AVM or
imported as CSV files. When in use, the processes
to determine logical vehicle position and
forecasts can be displayed through the administration
interface both in graphic and tabular
form.
AVM Light is currently in testing with Stadtwerke
Eberbach vehicles equipped with mdv
software. The testing phase is planned to successfully
end in December.
Integration of on-board third-party devices into
the AVM is still ongoing, particularly by the
manufacturer of on-board devices to bring the
interfaces up to a common standard. As soon
as there is something new to report we will be
sure to tell you in a future issue of mdv news.
Vehicle Scheduling Light
Vehicle scheduling in DIVA is nothing new; it
has been a part of previous versions since the
introduction of the operational data model. In
DIVA 3 and DIVA 4, classic vehicle scheduling
was done in the graphic schedule, a powerful
tool that supports schedulers when planning
vehicle blocks. For smaller operators with between
one and twenty buses, vehicle scheduling
may not even be required to this degree. Their
blocks are often so simple that they can be
managed in normal office software like Excel or
may be set by the contractor themselves. In this
case the existing blocks, which are not in
machine readable format, have to be entered
into DIVA in a simple format and transferred to
the AVM system. Technically this procedure
could be done in the graphic schedule module,
but doing so would be like hunting sparrows
with a canon. To avoid overkill, we have developed
an extension in DIVA Schedule that deals
with this frequently occurring situation. Using
drag and drop, trips can be assigned to blocks
from route group containers (see figure 1).
Because the day types of the authority routes
often differ from the vehicle schedule day
types, meaning that there is a timetable for
Mon-Fri, but different shift schedules for each
day, DIVA 4 enables a route group to be assigned
to several day types within the block. So for
each block day type, independent blocks can
be combined from one and the same timetable
in DIVA Schedule. In this way DIVA Schedule
supports the scheduling process with diverse
editing functions like the ability to copy a block
to another day type.
Also missing from most authority data are the
operational trips or “empty trips”, like a bus trip
without passengers from the end of one pro-