ICT and operational requirements for delivery and …-ELBA Document Type / No. / Title Deliverable /...

Deliverable D3 – ICT and operational requirements for delivery and coordination of people and goods mobility services in Elba island Vers. 1.0

© LIFE+ELBA Consortium: All rights reserved

LIFE ENVIRONMENT Programme EUROPEAN COMMISSION, DIRECTORATE GENERAL ENVIRONMENT, Directorate D, ENV.D.1 - LIFE

ELBA – Integrated Eco-friendly Mobility Services for People and Goods in Small Islands

Contr. No. LIFE09 ENV/IT/000111

ICT and operational requirements for delivery and coordination of people and goods mobility services in Elba island

Deliverable D3

Document Control Record

LIFE+-ELBA Document Type / No. / Title Deliverable / D3 / ICT and operational requirements for delivery and coordination of people and goods mobility services in Elba island

Action No. A3

Date/ Version/ Status 31.03.2011 / 1.0 / Final

Dissemination level PU

Document Responsible(s) Softeco Sismat

Contributing author(s) Marco GORINI, Valentina CERESETO

Number of pages 29

File Name ELBA-SOFTECO-DELVD3-v1.0.docx

© Copyrights LIFE+ELBA Consortium 2010-2013: All rights reserved

LIFE+-ELBA Project – LIFE09 ENV/IT/000111 31/03/2011

Deliverable D3 – ICT and operational requirements for delivery and coordination of people and goods mobility services in Elba island

Vers. 1.0


Document information

Abstract

The Elba project addresses innovations in two main aspects of mobility: collective people transport and goods transport/distribution. In the following, a review of enabling ICT solution for the implementation of integrated eco-friendly mobility services for people and goods is outlined.

Keywords

Small islands, freight distribution, environmental compatibility, clean vehicles, EU Projects.

Authors

Editor(s) Marco GORINI (Softeco), Valentina CERESETO (Softeco)

Contributors Marco BOERO (Softeco)

Antonio LIBERATO (MemEx)

Andrea IACOMETTI (MemEx)

Bruno BASTOGI (ATL)

Document history

Date Author Main Changes Status

31/03/11 GORINI Marco Original Final

Status: Draft, Final, Submitted (to European Commission); Approved (by European Commission)



Vers. 1.0


Contents 1 INTRODUCTION ................................................................................................................................................ 5

1.1 BACKGROUND AND AIM OF LIFE+ ELBA PROJECT...................................................................................... 5

1.2 OVERVIEW OF EXPECTED RESULTS .............................................................................................................. 5

1.3 SCOPE OF DELIVERABLE D3 ........................................................................................................................ 5

2 FREIGHT MANAGEMENT ............................................................................................................................... 6

2.1 FREIGHT MANAGEMENT INFRASTRUCTURE................................................................................................... 6

2.2 MAIN SERVICES ............................................................................................................................................. 6

2.2.1 Forward Logistics Management (Last-Mile Management) .......................................................... 6

2.2.1.1 Delivery Request ............................................................................................................................ 7

2.2.1.2 Parcel Labelling .............................................................................................................................. 8

2.2.1.3 Load Consolidation & Trip Planning............................................................................................. 9

2.2.1.4 Delivery Failure Management....................................................................................................... 9

2.2.2 Reverse Logistics Management ..................................................................................................... 10

2.2.3 System Resource Management ..................................................................................................... 10

2.2.4 Track & Trace .................................................................................................................................... 11

2.2.5 Routing ............................................................................................................................................... 11

2.2.6 Mobile Services................................................................................................................................. 12

2.2.6.1 Basic Operation ............................................................................................................................ 12

2.2.6.2 Vehicle Localization...................................................................................................................... 13

2.3 VALUE-ADDED SERVICES............................................................................................................................. 13

2.4 DIRECT LOGISTICS MANAGEMENT.............................................................................................................. 14

2.5 ICT REQUIREMENTS ................................................................................................................................... 15

3 PUBLIC TRANSPORT MANAGEMENT ...................................................................................................... 18

3.1 DRT OPERATION CHAIN ............................................................................................................................. 19

3.1.1 Phase 1: Travel request submission.............................................................................................. 20

3.1.2 Phase 2: trip notification .................................................................................................................. 21

3.1.3 Phase 3: booking confirmation (or refusal) ................................................................................... 21

3.2 BOOKING METHODS .................................................................................................................................... 21

3.2.1 Immediate booking schemes .......................................................................................................... 21

3.2.2 Pre-booking schemes ...................................................................................................................... 21

3.3 MAIN TECHNOLOGICAL OPTIONS ................................................................................................................. 22

3.3.1.1 Booking via the Travel Dispatch Centre (TDC) ........................................................................ 22

3.3.1.2 Booking via TDC operators ......................................................................................................... 22

3.3.1.3 Interactive Voice Response Systems ........................................................................................ 22

3.3.1.4 Internet booking ............................................................................................................................ 22

3.3.2 On-street booking ............................................................................................................................. 24

3.3.2.1 Booking terminals ......................................................................................................................... 24

3.3.2.2 Driver booking ............................................................................................................................... 25

3.3.2.3 Information and booking on-the-move....................................................................................... 25

3.4 DISPATCHING TECHNOLOGY / OPTIMISATION TOOLS................................................................................... 25

3.4.1 Methods and main functionalities................................................................................................... 25

3.4.2 Technologies ..................................................................................................................................... 26

3.4.2.1 Basic TDC architecture ................................................................................................................ 26

3.4.2.2 Digital maps and address databases......................................................................................... 27

3.4.2.3 GIS systems .................................................................................................................................. 27

3.4.2.4 Assignment and planning engines ............................................................................................. 28

3.4.2.5 Optimisation engines.................................................................................................................... 28

3.4.2.6 Tracking and monitoring .............................................................................................................. 29



Vers. 1.0


Tables

Non è stata trovata alcuna voce dell'indice delle figure.

Figures Figure 1. Sample of Elba shipping label........................................................................................................8

Figure 2. Sample of Elba parcel label ...........................................................................................................9

Figure 3. The PSION© Workabout Pro 3C..................................................................................................12

Figure 4. Elba IT Platform software architecture .........................................................................................16

Figure 5. Elba IT Platform hardware architecture........................................................................................17

Figure 6. DRT Operation Chain...................................................................................................................20

Figure 7. ElbaDRT Travel Dispatch Centre .................................................................................................23

Figure 8. Steps for set-up and running of ElbaDRT TDC............................................................................24

Figure 9. A typical TDC deployment architecture. .......................................................................................27



Vers. 1.0


1 Introduction

1.1 Background and aim of LIFE+ ELBA Project

Elba is a pilot project part-funded by the European Commission under the http://ec.europa.eu/environment/life/funding/lifeplus.htm, the EC financial instrument for the Envi-ronment.

Launched in October 2010 and running until September 2013, ELBA has the main objective of planning, implementation and demonstration of a number of advanced eco-sustainable, integrated mobility schemes and services for people and goods targeting, specifically, the "small islands" environment and application context.

Particularly, the territorial context of ELBA project includes the Elba Island, the main island of Tuscan Archipelago (Tuscany Region, Italy) and the connected mainland area, including the town of Piombino (Livorno Province) and the surrounding regional transport environment.

Action3-related activities have been carried out starting from the initial achievement of the analysis of stakeholders and user needs (Action 2), trying to identify the main needed technologies and technical components, together with their most relevant requirements (technical, operational).

Finally, all the three objectives have been fulfilled. The IT platform design that resulted from these activities seems to be an excellent basis for the successful validation and demonstration of the project, as well as a good starting point for further developments and commercial exploitations.

1.2 Overview of expected results

ELBA will investigate, implement and pilot a number of "intermediate" and "flexible" (i.e. demand-responsive) transport and logistics schemes, operated by eco-friendly vehicles and integrated in the broader context of mobility measures, thus allowing Elba Island to achieve high standards of energy efficiency and environmental quality.

Attaining high levels of applicability to the addressed geographical and environmental context - i.e., small islands, short distance and frequent mainland-islands trips, intermodal freight flows, interactions among freight, local mobility, tourists mobility flows, etc. - the solutions demonstrated in the project will provide viable models of interests for and transferable to many other national and European sites concerned with small islands mobility. Represented by the Municipality of Kalymnos, the Greek island belonging to Dodecanese is partnering within ELBA with the aim of understanding the requirements and goals of the solutions identified for the Elba island, assessing and evaluating the potentials for transferring and adapting such solutions to the local context and conditions.

The expected positive results of the planned ELBA actions include:

1. inducing a shift from private (car) mobility in the island by offering attractive public transport ser-vices operated by eco-friendly vehicles – flexible services dynamically responding to individual travel demand – to both residents (internal traffic) and tourists/visitors (incoming flows); i.e. less use of cars by residents, less needs to reach island destinations by own cars for tourists, thanks to the new demand-responsive services (demand-responsive transport from/to hotels and touris-tic destinations, personalised baggage delivery services, etc.);

2. reducing the impacts of incoming freight flows through rationalisation and optimisation of the de-livery services already on the mainland side (freight consolidation services, optimised freight transport schedules, optimised load capacity in short sea transport mainland-island);

3. rationalising freight distribution ("last mile" delivery) and logistics services e.g. inner logistics, out-going freight flows) in Elba island by applying dynamic optimisation strategies that adapt freight transport to both current demand and traffic conditions.

1.3 Scope of Deliverable D3

This deliverable focuses on possible enabling ICT solutions to be adopted for achieving the main objec-tives of the Elba project.



Vers. 1.0


Deliverables D3 is the expected result for Action 3 (Preparatory Actions) “Review of enabling ICT solu-tions, requirements and operational conditions”.

This action was concerned with the analysis of technologies and ICT solutions potentially applicable to support the operation of Elba passengers transport and freight delivery services in the project operational area. The analysis addresses technical as well as operational issues and led to the identification of the main tools, systems and infrastructures to be operated and to the understanding of the main requirements of the enabling ICT solutions. This action also led to the identification of the main needs to be met to ensure the proper introduction, operation and management of the identified systems and infrastructures in the organizational and operational context of the new mobility services on both the mainland and island sides in the target area.

Starting from initial achievements of the analysis of stakeholder and user needs (Action 2), the main needed technologies and technical components were identified together with their most relevant require-ments (technical, operational).

2 Freight management

The goal of the “freight transport/distribution” part of the Elba project is the implementation of a set of measures (regulatory, organisational, operational and technological) to enable the planning, implementa-tion, demonstration and evaluation of innovative models for flexible, collective mobility services to reduce the impacts of goods transport from Piombino (mainland side) to Elba and of freight distribution in differ-ent small urban areas of the island.

These measures are based on city logistics schemes, integrated in the broader context of mobility and transport measures, thus allowing Elba island to achieve high standards of energy efficiency and envi-ronmental quality, thereby acting as a model for freight transport/distribution management in small islands.

To this end, the Elba project aims at implementing, integrating and demonstrating innovative models for freight distributions between mainland and the Elba island, as well as in the small urban areas in the island, strongly oriented to interaction and cooperation of the different actors within the logistics chain (short/mid/long-range freight transport operators), eco-friendly fleets for city deliveries, Local Authorities, shops and retail system, mobility operators, etc. The adoption of such schemes will positively contribute to reducing the adverse effects of current processes and practice in city logistics, and will lead to relevant improvements for the urban environment as well as for the quality of life.

Following chapters will describe the operational model and the main services implemented by the Elba platform, as well as the basic procedures that support them.

2.1 Freight management infrastructure

The operational model of the Elba platform is based on two (or more) logistics bases (physical buildings, warehouse or other storage area): one (or more) located in the nearby of the mainland harbour (Piom-bino) and one (or more) located in the nearby of the Elba harbour(s) individuated as the possible destina-tion(s) of the freight flows intercepted by the platform.

The platform also manages a fleet of eco-friendly vehicles (e.g. vans) in charge of deliveries/collections at Elba island side and freight movement among logistics bases.

2.2 Main services

2.2.1 Forward Logistics Management (Last-Mile Management)

The term forward logistics, in its common meaning, indicates the flow of goods upside-down the supply chain, also known as downstream. In Elba project context, however, it indicates the “geographical” direction of the flow (outside world to Elba island area commercial operators) rather than the “logical” direction (manufacturer to final user), and it implies the transhipment from forwarders to Elba fleet.

In order to simplify the shipment procedure and to avoid redundant documents, Elba service will reuse the original shipping note of the forwarder, whenever possible. This approach also makes the forwarder more visible to the consignee, since all the original documents are preserved throughout the whole chain.



Vers. 1.0


Basically, the operational model implemented by Elba platform will consist in a transhipment that will take place at mainland base: the parcels are taken there by the forwarders, and then they are temporarily stored, waiting for shipment to the island base. Temporarily stored parcels will be grouped and sorted by delivery time, and transferred to the island base by one or more van moving back and forth between the two connected harbours (using the regular ferry service). Such transfer will be modulated according to the saturation level of the island base.

Once checked-in at the island base, the parcels will grouped in optimized delivery trips (missions), and finally delivered to their consignees. The optimization of trips will aim at maximizing the load of vehicles and minimizing the routes, always complying with possible constraints, such as delivery priority, opening hours, etc.

The whole process of collecting, storing and delivering parcels is under the control of the Elba platform, following a sequence of logically-related steps, which is described in following chapters.

2.2.1.1 Delivery Request

In order to activate the shipment procedure, the forwarder must submit to Elba platform a delivery request, indicating the shipping ID, the number of parcels (and optionally the list of label IDs

1), the total

weight, the consignee, its address, the date/time for collection and delivery2 and any other additional

information that may be required.

Usually, major forwarders submit delivery requests in advance, by one of the interfaces listed below. There are cases, however, where the forwarder unexpectedly visits the mainland base (unannounced transhipment). In such case, the delivery request is directly submitted by the Elba agent (see point 1 below).

The Elba platform will support following interfaces for submitting delivery requests:

1. Local interface (Elba console). The forwarder communicates all required information to Elba agent (via phone call, fax or e-mail), who in turn submits the requests to the Elba console. The delivery requests may be submitted one by one (by means of a dedicated window) or all at once (by reading a properly formatted comma-separated text file).

2. Web interface. The forwarder must browse the Elba website, enter the Partners’ Reserved Area and compile a Delivery Request Form. The access to Partners’ Reserved Area is only granted to those freight transport operators that subscribed the service.

3. File transfer interface. The forwarder must browse the Elba website, enter the Partners’ Reserved Area and upload a properly formatted Delivery Request File (see point 1). The access to Partners’ Reserved Area is only granted to those freight transport operators that subscribed the service.

4. Web-service interface. The forwarder’s IT infrastructure must implement and integrate the logic to submit delivery requests, by interfacing a dedicated web-service published by the Elba platform. This is a typical example of “tightly-coupled” electronic data interchange (EDI).

In all these cases, for each request the Elba platform opens a kind of logical transaction, which is closed by one of three conditions: the successful delivery of the parcel to the consignee, the return of the parcel to the forwarder (in case of delivery failure or reverse logistics) or the cancellation of the shipment (in case the forwarder doesn’t physically tranship the parcel to Elba service).

The status of such transaction is initially set to waiting-for-collection (i.e. open transaction), and then it is updated according to different events managed by Elba platform (cancelled, in-stock, on-the-way, deliv-ered, returned, shipped), in order to allow the tracking of the goods.

If, for any reason, the forwarder needs to cancel a delivery request before the collection, it can use the same interface used for submission, except for file transfer.

1 The label ID doesn’t necessarily coincide with the shipping ID (e.g. whenever a single shipment consists of multiple parcels, each

of them has its own unique label ID, which will be obviously different from the shipping ID). Although this list is not mandatory,

forwarders must be encouraged to specify it, since it enables the automatic check-in.

2 If delivery date and time are not specified, the Elba platform assumes that the parcel may be delivered at any time within the day

of transhipment. Otherwise, the forwarder may specify an exact date and time for delivery, in order to meet specific consignee

requirements (e.g. shop opening time).



Vers. 1.0


2.2.1.2 Parcel Labelling

One of the key aspects of the procedure is the labelling of the parcel. The label is a barcode sticker that is physically applied to the parcel. The ID herein contained will identify the parcel throughout the entire lifetime of the shipment process.

The label ID doesn’t necessarily coincide with the shipping ID specified within the delivery request (which is the same unique number printed on the shipping note). For instance, whenever a single shipment consists of multiple parcels, each of them has its own unique label ID, which will be obviously different from the shipping ID. Furthermore, there are fairly common cases where parcels are not labelled at all (typically when they come from minor or private forwarders).

In order to provide a uniform management of all these cases, the Elba platform will prefigure a proprietary labelling procedure, which may integrate or replace the original labels provided by the forwarder. The Elba platform generates an internal shipping ID per delivery request (i.e. per shipping note), plus an internal ID per parcel. Depending on the type of check-in (see below), the Elba agent may decide whether to print or not the additional shipping label (to be applied to the shipping note). Furthermore, when parcels are not labelled (e.g. in case of minor forwarder or reverse logistics collection), the agent may also decide to print the whole block of parcel labels. If the forwarder explicitly specified the list of label IDs (see paragraph 2.2.1.1 - Delivery Request, note 1), the Elba driver may directly “shoot” original parcel labels (automatic check-in), and there is no need to print anything at all.

At the beginning of a period (e.g. a day or a shift), Elba agents must arrange the labelling for all the shipments that are going to be received at the mainland base. The Elba platform filters all pending transactions (waiting-for-collection) for the relevant period, and displays them on a dedicated window, from where the agent may print all required labels.

The two figures below show the two types of label generated by the Elba platform:

Elba shipping ID: 1220 Elba Parcel IDs: 6194-6201

Master forwarder: M.T.N. Spa

Master shipping ID: 00479 Date: 15/02/07

No. of parcels: 8 Total weight: Kg. 153

Consignee: Linea Baby

Address: Via Mazzini, 57037 Portoferraio (LI)

Figure 1. Sample of Elba shipping label



Vers. 1.0


Elba shipping ID: 1220 Elba parcel ID: 6200

Master forwarder: M.T.N. Spa

Master shipping ID: 00479 Date: 15/02/07

Consignee: Linea Baby

Address: Via Mazzini, 57037 Portoferraio (LI)

Parcel: 7/8

Figure 2. Sample of Elba parcel label

In the figures above, the fields “Elba shipping ID” and “Elba parcel ID” contain the internally generated identifiers, while the field “Master shipping ID” contains the identifier originally specified by the forwarder within the delivery request, so that all the records can be easily cross-referenced.

2.2.1.3 Load Consolidation & Trip Planning

One of the most important duties of the Elba agent is the planning of delivery activities. The Elba platform will accomplish this task by an advanced load consolidation and routing engine, which will be typically invoked at the beginning of a period (e.g. a day or a shift), or whenever a new in-house transhipment is completed. As a first step, the system filters the open transactions by displaying all shipments ready to be delivered (in-stock) for a given date/time. All matching entries are grouped per working area and listed on a dedicated window, also displaying all available vehicles.

At this point, the system will enable the Elba agent to manually create a new trip, simply by right-clicking an available vehicle on the vehicle tree and by dragging & dropping shipments from the list. By default, deliveries are sorted according to drag & drop order. Optionally, the agent can ask the system to find the best route for selected deliveries (see paragraph 2.2.5 Routing), to optimize the sequence of stations and to calculate the schedule.

Furthermore, the Elba platform will provide an Automatic Consolidation Tool, which will allow the auto-matic building of the trips. By this feature, the agent may delegate to Elba platform the whole process of associating parcels to vehicles, calculating routes and optimizing the sequence of operations.

All the trips generated by this process may be edited as in the manual building case. By this way, the Elba agent may review the results, fixing possible inconsistencies and/or forcing particular conditions not covered by the automatic process. Trip details may then be printed on a dedicated report, which will be handed to Elba drivers to carry out their service duty.

2.2.1.4 Delivery Failure Management

If an Elba driver doesn’t succeed in delivering parcels to a consignee, he/she must record the failure by shooting the Elba shipping label, by clicking a checkmark on the Elba terminal or by shooting the original labels applied to each parcel (only if the forwarder explicitly specified the list of label IDs). Furthermore, the driver must specify the reason for the failure (e.g. the consignee is missing/closed, the goods were refused, the goods were damaged, the consignee was unwilling to pay, the consignee requested delivery at a different address). Similarly to the delivery, the failure is usually recorded just-in-time, via the GPRS wireless connection. Should the wireless connection fail, all failures are buffered locally on the device, and downloaded to the Elba platform via a wired synchronization procedure, as the driver returns to the island base.

All failed deliveries must be returned to the island logistics base, where a new check-in must take place, thus setting the shipment status to in-stock. For each failed delivery, the Elba agent must try to recover the failure, according to subscription agreements: usually, the parcels are kept in stock for some time, in order to retry the delivery, otherwise they are returned to the forwarder.



Vers. 1.0


2.2.2 Reverse Logistics Management

The term reverse logistics, in its common meaning, indicates the flow of goods downside-up the supply chain, also known as upstream. In Elba project context, however, it indicates the “geographical” direction of the flow (Elba island area commercial operators to outside world) rather than the “logical” direction (final user to producer), and it implies the transhipment from Elba fleet to forwarders.

Due to this specificity, reverse logistics includes parcels returned to the forwarder or the consignor, post-sells, return of reusable transit equipment (such as pallets and containers), but also goods that may have been manufactured inside the Elba island area and need to be shipped afar. In all these cases, however, there is no direct negotiation between the Elba platform and the consignor. In other words, the consignor negotiates the shipment with the forwarder, and the forwarder delegates the Elba platform for parcel collection and temporary storage, following a procedure that resembles the last-mile model, except for the direction of the flow (in fact, this could be called first-mile management).

Within the reverse logistics service, the Elba driver must visit the consignor and collect all the parcels, together with the accompanying delivery note. All collected parcels are taken to the island base, where a standard check-in takes place. Since the Elba is the first logistics operator involved in delivery chain, there is no original label to shoot, and then the check-in is always manual. At this stage of the procedure, the Elba agent validates the contents of collected delivery notes against the relevant delivery requests

3,

and prints the picking list (which will be used to tranship goods to the forwarder) and the Elba shipping label.

Afterwards, the parcels are moved to the mainland base, where they will be collected by the forwarder. When this occurs, the Elba agent must check-out all required parcels (by shooting the shipping label or by clicking a checkmark on the Elba terminal) and must hand them to the forwarder, together with the accompanying picking list. If Elba parcel labels are provided, the agent may shoot them one by one, instead of the Elba shipping label. As usual, the check-out is recorded just-in-time, using the most convenient and reliable wireless transport. If no wireless connection is available, all check-out data are buffered locally on the device, and downloaded to the Elba platform via a wired synchronization proce-dure. When recording the check-out, the Elba platform marks the status to shipped (or returned, in case of failed delivery return) and closes the transaction.

2.2.3 System Resource Management

Prior to begin the operational service, the Elba administrator must define a set of basic information used by the Elba platform. This information is provided by means of following tools: the Network Editor, the Fleet Directory Manager and the Driver Directory Manager:

• By the Network Editor the Elba administrator may view and modify the road network information provided by the underlying map management software. Typical editing activities include:

o To define the working areas (geographical criteria used to group pending deliveries, see paragraph 2.2.1.3 - Load Consolidation & Trip Planning).

o To modify and tune the road network (e.g. temporary access restrictions, road speed).

o To add/edit/remove network objects (e.g. commercial operators, logistics bases).

• By the Fleet Directory Manager the Elba administrator may add, edit or remove Elba vehicles (manufacturer, model, license plate, size, matriculation data, loads, etc.) and define their availabil-ity calendar. Optionally, a vehicle may be strictly associated with a driver (thus inheriting his/her calendar).

• By the Driver Directory Manager the Elba administrator may add, edit or remove Elba drivers (name, surname, address, accounting profile) and define their availability calendar (working hours, holydays, vacations etc.).

3 In fairly common cases, the reverse logistics’ delivery request may be incomplete or not accurate, specifically for what concerns

the number of parcels and the total weight. In such cases, the Elba agent may review and update the information according to the

contents of the collected delivery note, and reprint all required labels.



Vers. 1.0


2.2.4 Track & Trace

The term track and trace indicates the process for recording and publishing the progress of the shipment. More specifically, the term track indicates the current status of the shipment, while the term trace indi-cates the history of all events concerning the parcel.

An accurate tracking of the shipment is one of the most important issues for freight transport operators, since it is a primary indicator for the quality of the service, as perceived by their customers. Whenever a forwarder tranships a parcel to another party (as in the Elba case), it must get tracking data from the latter, so that it can still operate as the one and only interface to the consignor and/or the consignee. In other words, the forwarder must “hide” the transhipment and provide tracking data as if the parcel is in its hands.

In a very simplified scenario, the forwarder may flag the shipment as under-delivery at transhipment time, and then wait for final delivery notification. This approach may be adequate for active collection (cross-docking), where the collection and the delivery are accomplished within the same trip, while it can be too poor and approximated in case of temporary storage and load consolidation. In order to achieve the maximum degree of integration between different IT infrastructures, the Track & Trace Service supports two main interfaces:

1. Web interface. The forwarder will browse the Elba website, enter the Partners’ Reserved Area and open the Shipment Track & Trace Page. From this page, the forwarder may trace the history of the shipment (given its ID) and see the scanned image of the signed shipping note (or the elec-tronic signature captured by Elba terminal), if available. The access to Partners’ Reserved Area is only granted to those freight transport operators that subscribed the service.

2. Web-service interface. The forwarder’s IT infrastructure may implement and integrate the logic to get track & trace data from the Elba, by interfacing a dedicated web-service and passing the label ID. This is another example of “tightly-coupled” electronic data interchange (EDI).

The Track & Trace Service records all the events concerning a transaction (check-in, check-out, delivery, failure, return, shipment), together with the associated time stamp, so that the forwarder (or any other user) may reconstruct the exact history of the shipment. Obviously, if the events are recorded with delay (e.g. unconnected terminals) the accuracy of the tracking lowers, so that the service is qualified as near-to-real-time (rather than real-time).

Normally, by Elba’s point of view, the consumer of Track & Trace Service is not the consignor nor the consignee, but the forwarder, which in turn will route information to its customers. In this context, the web-service interface seems to be the most suitable solution, providing detailed and up-to-date shipping information directly to forwarder’s IT infrastructure (assumed that it can be modified to consume such data). In case of value-added services, however, tracking data may be directly consumed by private citizens (e.g. park-and-buy, parcel-taxi). In this context, since the consumers need not to be tightly integrated with the Elba, the only suitable interface is the web.

2.2.5 Routing

The term routing indicates the computer-aided process of building trips, according to road network information provided by the underlying map management software (mapware).

When building trips, the Elba agent may choose one of three operating modes:

• Manual: the agent manually builds each trip, by defining the parcels to be delivered/collected and the associated sequence of operations (stations).

• Hybrid: the agent manually builds each trip, by defining the parcels to be delivered/collected, and then delegates to Elba platform the optimization of the trip, by finding the most convenient se-quence of operations (stations).

• Automatic: the agent delegates to Elba platform the whole process of associating parcels to vehi-cles, calculating routes and optimizing the sequence of operations.

In last two cases, the Load Consolidation & Trip Planning Service cooperates with the Routing Service to optimize routes. The road network information will be normally kept up-to-date by subscribing a mainte-nance agreement with the map provider. Furthermore, the Elba platform provides a Network Editor tool that allows administrators to modify the road network in an easy and interactive way (e.g. temporary road closures, traffic limitations). All this considered, the Routing Service provided by the Elba platform will be an effective and affordable help (although not mandatory) to ease the trip building procedure.



Vers. 1.0


2.2.6 Mobile Services

The term Mobile Services indicates the set of remote functionalities that are consumed “on the field” by the Elba driver. Such functionalities are exposed by an intelligent mobile device, running some specifi-cally-developed software (that is, not simply using a web browser) and wirelessly connected to the Elba platform.

While most of the Elba platform services are hardware-agnostic (that is, they are designed to be pack-aged and deployed to any commercially available computer), the design of Mobile Services is heavily affected by the capabilities of the hosting device. The basic requirements for this device indicate a standard rugged palmtop or handheld PC, with a high degree of robustness and reliability and with a wide range of hardware interfaces and communication options. The figure below shows an example of such device (PSION Teklogix© Workabout Pro).

Figure 3. The PSION© Workabout Pro 3C.

2.2.6.1 Basic Operation

In order to use the Elba terminal, the driver must first login into the system, by entering a username and a password. This action protects the application from unauthorized accesses, and in the meanwhile identifies the driver for subsequent service duty download.

Usually, the download takes place over a wireless connection. If the home wireless LAN network is detected, the terminal connects it, otherwise it fallbacks on the GPRS network. As long as the Elba agent plans new delivery trips (usually due to new in-house transhipments), all the interested terminals are continuously and remotely kept up-to-date, thus streamlining the overall management.

Once the service duty is onboard, the driver can browse it and have a quick view of his/her scheduled trips. A few minutes before a trip is planned to start, the terminal alerts the driver by a ring tone, so that he/she can prearrange it.

In addition to planned trips, the terminal may display the list of all expected in-house transhipments. This feature is specifically designed for those Elba drivers directed to welcome forwarders at mainland base, rather than carry on deliveries. Since this is a horizontal activity, it is not assigned to a specific driver, so that any available employee (included the Elba agent) can accomplish it.

Depending on the type of activity, the Elba terminal displays different information:

• In case of in-house transhipment, the terminal displays the name of the forwarder, the expected arrival time and the complete list of shipments to be collected or delivered.

• In case of trips, the terminal displays the expected time for start and the list of stations to be vis-ited. For the first station (i.e. the Elba logistics base), the terminal displays the list of all the ship-ments to be loaded aboard the vehicle, in the right order (last-in-first-out). For all other stations, the terminal displays the complete list of shipments to be delivered or collected, similarly to what’s reported in Delivery Trip Plan (see paragraph 2.2.1.3).



Vers. 1.0


When a given trip is complete, the Elba driver must advance to the next one. At the end of the working shift, the driver must simply log off the terminal by a dedicated button.

2.2.6.2 Vehicle Localization

The Vehicle Localization Service allows the vehicle belonging to Elba fleet to communicate periodically its position to the Elba platform. Vehicle localization is only available if external on-board devices (black boxes, which periodically send vehicle’s position, gathered from the integrated GPS receiver) are installed on each vehicle. By this service, the Elba platform may provide a continuous monitoring of the fleet and the personnel, either in real-time or historical mode.

In first case, the Elba agent may navigate through a map of the served area, having a quick view of current position of terminals. This feature greatly improves the safety of Elba drivers, vehicles and transported goods, as well as the flexibility and the efficiency of the platform, since knowing the position of all vehicles may help the agent to identify the most convenient solution for a trip deviation (see next paragraph).

In second case, the Elba agent may review the history of movements for a given driver and a given period of time, by plotting on the map all recorded position samples (playback). This feature provides a good control over the conduct all Elba drivers, highlighting the deviations from expected routes.

2.3 Value-added services

Value-added services include a set of functionalities that, although not usually involved by the supply chain, contribute to improve the quality of life by addressing the needs of different classes of users. These services may be classified in three main groups, depending on the final consumer: citizen-dedicated services (B2C), professional-dedicated services (B2B) and administration-dedicated services (B2A).

1) B2C Services

a) Park-and-buy.

When an occasional customer (e.g. a tourist) buys some goods in a shop inside the Elba area, the clerk submits a delivery request (usually by calling the Elba agent or by the web interface), in-dicating the pick-up point (the shop), the drop-off point (a parking or a hotel) and the time for de-livery. The request is then processed according to direct logistics workflow (see paragraph 2.4 - Direct Logistics Management). If the drop-off point is a parking, it must be guarded and must have a suitable place for storing and delivering goods.

b) Elderly & Disabled Delivery.

When an authorized customer (or a social services employee) orders goods to a shop inside the Elba area, the clerk submits a delivery request (usually by calling the Elba agent or by the web in-terface), indicating the pick-up point (the shop), the drop-off point (the customer’s home) and the time for delivery. The request is then processed according to direct logistics workflow (see para-graph 2.4 - Direct Logistics Management).

c) Parcel-Taxi.

When an occasional customer needs to ship a parcel to some place in the Elba area, he/she submits a delivery request (usually by calling the Elba agent or by the web interface), indicating the pick-up point (his/her home), the drop-off point (the workshop) and the time for collection. The request is then processed according to direct logistics workflow (see paragraph 2.4 - Direct Logis-tics Management).

2) B2B Services

a) Packaging Pick-up & Recycle.

The Elba system may implement this service following two different models: the Round Trip Packaging Pick-up and the On-demand Packaging Pick-up. In the former case, the Elba defines in advance a calendar of round trips through Elba area, by planning their routes and time sched-ules. Interested commercial operators (assumed to be properly informed by some promotion ef-fort) must simply leave compacted packaging along the route, according to the planned calendar. In the latter case, the commercial operator (e.g. a shop) submits a delivery request (usually by calling the Elba agent or by the web interface), indicating the pick-up point (the shop), the time for



Vers. 1.0


collection and the packaging pick-up flag. The request is then processed according to direct logis-tics workflow (see paragraph 2.4 - Direct Logistics Management). The two models are not mutu-ally exclusive, but can coexist side-by-side (e.g. most populated zones may be served by round trips, while other zones may be served on-demand). Once taken to Elba logistics base, the col-lected packaging are stocked in a compactor container, and then withdrawn by interested paper recycling companies.

b) Third-Party Warehousing.

The Elba system rents part of its warehouse to commercial operators (shops, workshops). The sub-

scribers may use this service as a “virtual” warehouse, stocking batch supplies from wholesalers and

delegating the Elba to manage the retail supply of the shop.

3) B2A Services

a) Unloading Area Control.

The Elba platform exposes unloading area reservation data (authorized license plate, begin time, end time) to local authorities. Such data may be verified on the field by traffic officers, either by remote controllable panels (installed beside the unloading area) or by specifically developed handheld de-vices.

Some of these services can easily fit in the procedures described in previous paragraphs, whereas others need a specific processing. More precisely, the services at point 1.a (park-and-buy), 1.b (E&D delivery), 1.c (parcel-taxi) and 2.a (packaging pick-up & recycle) simply implement a booking-collection-delivery cycle (following the cross-docked model), while the services at point 2.b (third-party warehousing) and 3.a (unloading area control) require additional infrastructures and dedicated procedures. Due to this distinc-tion, the first block of value-added services (commonly indicated as direct logistics) will be implemented and evaluated within the LIFE+ Elba project, while the second block will be implemented and evaluated in possible project follow-ups and extensions.

Although the overall procedure remains almost similar, direct logistics services differ from base services by a series of peculiarities that affect their interface and their implementation:

• The Elba operates as the one and only interface for both the consignor and the consignee, thus taking charge of some additional job usually carried out by the external forwarder (e.g. the Elba must emit and manage the shipping note).

• The consignor (the subject who triggers the shipment, by submitting the delivery request) is not necessarily a business operator, but may also be a private citizen. In such case, all contractual issues concerning the shipment (payment, transfer of liability) are not necessarily regulated by any subscription agreement, but are rather negotiated (and paid) from time to time.

• Both the consignor and the consignee reside inside the Elba area, and are both served by the Elba fleet, without any transhipment from/to any external forwarder.

2.4 Direct Logistics Management

The term direct logistics, in Elba project context, indicates the flow of goods from and to different actors all resident in the Elba area, and it is entirely carried out by Elba fleet, without any transhipment from/to any external forwarder. Due to this specificity, direct logistics may be considered as a combination between reverse logistics’ collection and forward logistics’ delivery (following the cross-docked model).

As usual, the Elba shipment procedure is initiated by submitting to Elba platform a particular type of delivery request, marked by an additional flag indicating the direct flow. Depending on the type of service, the delivery request may be submitted by a commercial operator (park-and-buy, packaging pick-up & recycle) or by a private citizen (elderly & disabled delivery, parcel-taxi).

This flag is used to identify trips for different services. Depending on specific company strategies, the Elba agent may choose to build dedicated trips, or build mixed trips integrating different activities. The agent may then proceed building trips following the standard procedure described at paragraph 2.2.1.3 - Load Consolidation & Trip Planning).

Since direct logistics follows the cross-docked model, the parcels do not pass by Elba logistics base, and then the overall process gets simplified (no need for check-in, check-out nor labelling). On the other hand, the Elba must provide some travelling document to certify the transfer of liability between parties, in the different stages of the shipment (neither shipping note from the forwarder nor delivery note from the



Vers. 1.0


consignor). In fairly common cases, such document cannot be printed in advance, due to the high degree of dynamism of value-added services (notably for park-and-buy).

In order to provide a uniform management of all direct logistics scenarios, the Elba will prefigure a dedicated paper form called travelling shipping note. Each Elba driver must always have a block of empty forms, to be compiled, signed and distributed at parcel collection and delivery.

Basically, the Elba driver only must record the collection and the delivery of the parcels, by clicking a checkmark on the Elba terminal. Usually, collection and delivery are recorded just-in-time, using the GPRS wireless network. Should the wireless connection fail, all these events are buffered locally on the device, and downloaded to the Elba platform via a wired synchronization procedure, as the driver returns to Elba logistics base.

If the driver doesn’t succeed in delivering parcels to the consignee, he/she must proceed according to standard delivery failure workflow (see paragraph 2.2.1.4 - Delivery Failure Management), featuring failure notification, check-in, load consolidation and retry.

When the driver returns to the logistics base, he/she must hand all travelling shipping notes and payment receipts to the Elba agent. The agent will then validate the shipping notes against the delivery request

4,

and manually enter accounting data according to payment receipts.

2.5 ICT Requirements

The Elba IT platform will be implemented according to most reliable, stable and widely accepted design patterns for enterprise applications. Basically, the system architecture will follow the n-tier model, where all functions are logically encapsulated into self-consistent components belonging to different logical layers:

• Data Access Layer (DAL): this layer implements all database access functions, exposing a uni-form interface to upper layers. The data access layer encapsulates all DBMS-specific constructs, thus abstracting the application from the underlying database.

• Business Logics Layer (BLL): this layer implements the most of application logic, processing data, coordinating activities for different clients and exposing processed data to the presentation layer. The DAL and the BLL together represent the “server side” of the IT platform.

• Presentation Layer: this layer implements the user interface, thus representing the “client side” of the of the IT platform.

This distribution is purely “logical”, rather than “physical”. This means that all the components will be designed to cooperate among themselves, either locally or through a network infrastructure, without being associated to any particular computer. In other words, all the components may be aggregated or distrib-uted over different computers, depending on the capabilities of the hardware in use and the size of the application, thus allowing the maximum flexibility and scalability of the system, far beyond the classic client-server scheme.

All the software modules (except for the third-party components, such as the map management software) will be implemented using an OOP language (such as the Microsoft© .NET framework or Java) and a robust and market-proven development environment.

The DBMS of choice for the Elba platform could be one of Microsoft© SQL Server family, Oracle or MySQL.

The term presentation layer is a generic indication for any software module implementing the user interface of the system. Usually, it is possible to identify two main classes of user interfaces: thin (web) clients and fat (thick) clients. In the first case, the user interface is simply represented by a web browser, and then the presentation layer is embedded by the web server. In the latter case, the presentation layer directly resides on client machine, in form of some deployable component. As it turns out, the first is the only possible solution for widely distributed (web-based) applications, while fat clients are still preferable for centralized applications.

4 In fairly common cases, the request for direct logistics delivery may be incomplete or not accurate, specifically for what concerns

the number of parcels and the total weight. In such cases, the Elba agent may review and update the information according to the

contents of the collected delivery note, so that accounting data is properly updated.



Vers. 1.0


Due to the different classes of reference users, the Elba platform will need to expose both kinds of interface. In fact, the platform must support a light interface for remote users (forwarders, subscribed shops, but also private citizens consuming B2C value-added services), requiring a thin client approach, as well as a full-featured Elba console (for Elba agents), where a fat client approach is preferable.

The figure below shows a reference architecture for the Elba IT platform and the different technologies that will be used. The figure also indicates how all services described in chapters 2.1 and 2.3 map to the different layers.

Figure 4. Elba IT Platform software architecture

Web browser (remote users)

Co

mm

un

icati

on

Co

mp

on

en

ts

Elba Console (Elba Agents)

Data Access Components

Network Editor (Elba Administrators)

Mo

bil

e

Co

mp

on

en

ts

MMoobbiillee

SSeerrvviicceess

Kern

el C

om

po

nen

ts

Ad

min

istr

ati

ve C

om

po

nen

ts

3rd

Part

y

Co

mp

on

en

ts

SSeerrvviiccee

ddaattaabbaassee MMaapp

ddaattaabbaassee

FFoorrwwaarrdd LLooggiiss--

ttiiccss MMaannaaggee--

mmeenntt

RReevveerrssee LLooggiiss--

ttiiccss MMaannaaggee--

mmeenntt

SSyysstteemm RRee--

ssoouurrccee MMaann--

aaggeemmeenntt

TTrraacckk && TTrraaccee

RRoouuttiinngg

DDiirreecctt LLooggiissttiiccss

MMaannaaggeemmeenntt

WWiirreelleessss CCoomm--

mmuunniiccaattiioonn

SSeerrvveerr

WWeebb SSeerrvveerr

MMaappwwaarree

AD

O (

CO

M)

Web service

WWeebb bbuuss ii--

nneess ss

oobb--

jj eecctt ss

Internet

(PSTN, ADSL, BB)

FFoorrwwaarrddeerr’’ss

mmaannaaggeemmeenntt

iinnffoorrmmaattiioonn

ssyysstteemm

Wireless networks (GPRS,

UMTS, WiFi)

PPrr eess eenntt aatt iioonn

LL aayyeerr

BBuuss iinneess ss

LL ooggii ccss

LL aayyeerr

DDaatt aa

AAcccceess ss

LL aayyeerr

CO

M

Web service

SO

AP



Vers. 1.0


The figure below shows a possible hardware architecture of the system, included all required peripherals. The diagram explicitly indicates the minimum set of equipments required for the Elba to work, assumed they can be integrated in an existing network infrastructure, here not detailed.

Figure 5. Elba IT Platform hardware architecture

The computers indicated as “Elba Consoles” will host the whole presentation layer. According to the n-tier architecture, this layer simply consumes data processed by the business logics layer, thus there is no particular requirement for CPU, disks or memory. Actually, a normal entry-level desktop computer seems to be enough, with only a few additional peripherals: a barcode reader to scan travelling documents, a barcode printer for parcel labels, a network printer for system reports (in order to support other office automation activities, a multifunction printer is recommended) and one or more wireless routers that will provide the WiFi coverage for the logistics base where the console is installed (mainland or island). The final configuration is expected to comply with following minimal requirements:

• CPU Intel Pentium Core i5 750 processor at 2.66GHz dual core, 4 GB RAM DDR2, 250 GB HDD serial ATA, 1 Gbps network card, DVD +/- R/W unit, 22” TFT colour display.

• Multifunction printer (fax/copy) with network adapter.

• Thermal transfer barcode printer, 203 dpi, 4.1” width, with network adapter.

The computer indicated as “Application Server” will host the DBMS, the whole data access layer and the whole business logics layer, except for communication components. This computer is the true heart of the

IInntteerrnneett

Route

r/fire

wall

Web Server

Application Server Elba

Consoles Barcode printers

Multifunction printer (fax/copy)

DMZ

LAN GSM Modem

Barcode readers

802.11g wireless routers

WWiirreelleessss nneettwwoorrkkss

((GGPPRRSS//UUMMTTSS//WWiiFFii))

Mobile Terminals



Vers. 1.0


system, thus a powerful, reliable and modular server-class machine is recommended. The final configura-tion is expected to comply with following minimal requirements:

• Intel Xeon© Quad Core, 5 GB DDR2 RAM, 500 GB HDD serial SCSI RAID 0, 1 Gbps network card, DVD +/- R/W unit, 1 x 700 W power supply hot-swappable, 22” TFT colour display.

All the equipments above will be logically connected to the corporate LAN, and will physically reside at one of the two logistics bases (mainland or island), assumed that a high-speed and broadband connec-tion links the two facilities.

The computer indicated as “Web Server” will host the part of the business logics layer providing access to remote users and Elba drivers (communication components). Such components include:

• Web business objects: a set of components that publish Elba data over the Internet, in form of human-readable dynamic web pages and forms.

• Web-services: a set of components that publish Elba data over the Internet, in form of standard SOAP interfaces, accessible by the forwarder’s management information system.

• Wireless communication server: a system service that concentrates all wireless traffic coming from Elba terminals, either via WiFi or via GPRS/UMTS. This service can also manage one or more GSM modems to operate as a backup of GPRS/UMTS network (in case of service unavail-ability) and to send SMS notifications.

Basically, this computer should be a server-class machine comparable to the application server. In order to be reachable from outside the corporate LAN, this machine must have a public IP address and must be connected to the DMZ.

The mobile terminal must be a full-featured industrial device, with excellent mechanical characteristics and a wide range of supported interfaces:

• Colour touch screen display, full VGA resolution 480x640, full alphanumeric keyboard (ABCDEF or QWERTY model).

• Bluetooth class II, ver. 2.0 + EDR (Enhanced Data Rate).

• Wireless LAN 802.11b/g (WiFi).

• GPRS/HSDPA module.

• Long-range 1D and 2D linear imager (barcode reader).

• High-capacity battery

3 Public transport management

The goal of the “public transport” part of the Elba project is the implementation of a set of measures (regulatory, organisational, operational and technological) to enable the planning, implementation, demonstration and evaluation of innovative models for flexible, collective mobility services for people (bus on demand and reservation) in order to provide eco-efficient solutions, meeting the typical local mobility

The Elba project aims at implementing, integrating and demonstrating innovative public transport services for different ELBA towns and villages, for Campo Airport passengers, for hotel guests, etc.

The main project objectives for such an innovative transport service, based on the DRT (Demand-Responsive Transport) paradigm, are:

• The reduction of impacts of local mobility of people (residents, commuters, tourists, etc). This goal can be achieved thanks to:

o A more rational organization of local surface transport services, enhanced usability and accessibility, related criteria of compensation between surface and maritime services.

o A more rational organization of Local Public Transport by the introduction of flexible transport services (substitutive and/or additional).

o Improvement of public transport offering (thus favouring modal shift from private car to public transport).



Vers. 1.0


• The reduction of impacts of private car traffic related to main flows (e.g. high season) between mainland and Elba island. This goal can be achieved thanks to:

o A rational organization of transport resources in the framework of EU regulation (e.g. pri-vatization of Toremar).

o An enhanced offering of “high quality” transport serviced through Flexible Transport Ser-vices in critical areas of the island:

� Flexible Transport Service from/to main harbours (Portoferraio, Rio Marina) and internal destinations of the Elba island.

� Feeding Flexible Transport Service scheme to support the new setup of the ac-cess harbour system of Elba island (Portoferraio, Rio Marina, Cavo pier)

� Targeted Flexible Transport Service scheme for tourists (e.g. transport of people and luggage to/from hotels, etc)

DRT is an advanced system of public transport, providing service in rural areas or areas of low passenger demand. This high form of user-oriented service is characterized by flexible routing and scheduling of small/medium vehicles, operating in a “shared ride” mode between pick-up and drop-off locations, according to passenger needs.

Elba project will focus on the implementation of a software package to support planning, operation and management of ElbaDRT service, a tool to help public transport operators meeting their customers’ demand of mobility, in a flexible and innovative way:

• vehicle journeys are defined dynamically, without predefined time plans;

• routes are defined dynamically, with origin and destination stops and times solely based on cus-tomer’s request;

• vehicles reach customers at stops only when required.

ElbaDRT service will allow public transport operators moving from the constraints and limitations of regular bus services - based on fixed routes and times - to a flexible and modern service concept, helping to reduce the gap of attractiveness between collective and individual transport. The implemented service will lie in an effective solution for low or dispersed demand areas, peripheral and rural areas, time periods of low demand and low frequency or unavailable service - night hours, holidays, off-peak hours, etc.

ElbaDRT service will become an effective way to bring public transport in geographical areas where regular public transport services are not available or are affected by bad economical and service per-formance: vehicles run empty, customers have long walking distances to bus stops, long waiting times, etc. With ElbaDRT planning and operation system, public transportation vehicles will travel and meet users at stops only when required. The service will economically viable for the operator and attractive for the user.

3.1 DRT Operation Chain

When a trip is needed, the customer gets in contact with the Travel Dispatch Centre, specifying the desired conditions:

• origin and destination points of the trip,.

• pick-up or drop-off times.

• date.

Based on customer’s request and on the current journey planning, the Travel Dispatch Centre finds automatically the journey which fits best with customer request. This may be an already existing journey, a journey modified to accommodate the request or a completely new journey.

The resulting different feasible journeys are offered to the customer, who will then accept a trip among them.



Vers. 1.0


In the following diagram, the required basic steps for availing of ElbaDRT service are summarized:

Figure 6. DRT Operation Chain

The booking and passenger information system is a central component of ElbaDRT (as for any IT-supported flexible transport service) management system. It represents the main interface between the transport end-user, i.e. the passenger, and the flexible transport service production system. This interface mainly comes into play during the pre-trip phase, enabling the passenger to submit his or her trip request to the ElbaDRT operator, to receive one (or more) service offer(s) in reply to the request, to select and book the preferred trip, eventually. This component may support also the exchange of information with the passenger at later stages, after the booking phase proper – for instance, allowing access to and modifica-tion of previous passenger’s bookings, delivering trip information (e.g., the expected pick-up time at the origin of passenger trip), providing communication of any change to previously booked trips, etc.

3.1.1 Phase 1: Travel request submission.

This is usually the starting phase of any DRT operation scheme, providing the end user with the capability of submitting his or her trip requirements to the DRT management system (within the Elba project, the ElbaDRT Travel Dispatch Centre). Travel requests normally include the following information:

• passenger identification (e.g. name, ID code, etc.).

• day of desired trip.

• origin and destination points of the trip.

• start time and/or arrival time.

• number of seats.

On-line “negotiation” of travel

Trip Booking (immedi-ate reservation)

Journey planning update

Generation of a feasible trip offer

Trip booking or

refusal

Update of DRT journey plan

DRT Service Database

Management of

customer’s travel

request



Vers. 1.0


• any additional (optional) requirement, such as, e.g., wheelchair, accompanying person, etc., mainly in DRT dedicated to specific user groups (disabled or elderly users).

3.1.2 Phase 2: trip notification

In response to user’s request, a “trip offer” is proposed to the end-user, including the details of one or more feasible services. These may include rather wider time windows over the departure and arrival times (e.g. 5-10 min.). In some cases, also alternative pick-up or drop-off points may be offered, if “stop points” exist which are conveniently located for the user (for example, other stops within short distance from the requested stops). Such variations over the user’s desired trip represent some “elasticity parameters” used by the booking system in order to accommodate users’ requests within the overall planning.

3.1.3 Phase 3: booking confirmation (or refusal)

Following trip notification, the user has then the possibility to accept one of the offered trips or refuse the offer. If any offered service is accepted, the corresponding trip is booked for the user, and a “trip confirma-tion” is issued by the booking system, providing the details about the planned passenger trip (pick-up and drop-off times and points, max. variations on agreed pick-up or drop-off times). Depending on the opera-tional characteristics of the booking system (see chapter 3.2), trip confirmation may be issued immedi-ately after the booking step is completed, or at a later stage (e.g. half an hour later, some hours later, the following days, etc.) by a new communication between the user and the booking system. Furthermore, a service modification phase may be provided, when users are allowed to access the booking system in order to modify or cancel any previous booking.

3.2 Booking methods

Elba DRT will provide two main different booking methods: immediate booking and (early) pre-trip booking.

3.2.1 Immediate booking schemes

In immediate booking schemes, the entire booking chain - from travel request submission, trip notification, booking confirmation – occurs:

• rather close to the time of desired trip (e.g. 1 hour, 30 min., 15 min. before) and

• usually within a single interaction between the user and the booking system.

This method is usually adopted for fully dynamic DRT schemes, in which modifications and re-planning of the service can be done also for en-route vehicles. This enables operating more dynamic and responsive schemes, but may lead to less efficient scheduling and vehicle use.

3.2.2 Pre-booking schemes

In pre-booking schemes, the trip booking chain:

• occurs considerably in advance with respect to the desired departure time (e.g. several hours or some days before) and

• the various phases are implemented at different times and require two (or more) interactions be-tween the customer and the TDC (Travel Dispatch Centre).

For example, travel request submission is realised in one initial step, ending with a trip order being recorded in the management system for later processing. Trip notification (and actual booking) are then implemented in a second step, which may take place even several hours (or days) after travel request submission. Finally, a defined trip notification phase can follow closer (e.g. 30 min.) to the reserved departure time, and takes place through a third communication flows between the booking system and the customer. This booking scheme is usually adopted for long and mid-term trip reservation schemes, where users can book their trip, for instance, for the following days, next week, next month, etc. This method is sometimes preferred to immediate booking, since it allows more efficient scheduling and use of available transport capacity, but leads to less dynamic systems from the point of view of users.



Vers. 1.0


3.3 Main technological options

3.3.1.1 Booking via the Travel Dispatch Centre (TDC)

In ElbaDRT trip booking and reservation occurs through a Travel Dispatch Centre (TDC), which receives and processes the travel request from the end-user and handles the subsequent trip notification and booking confirmation phases.

3.3.1.2 Booking via TDC operators

In the vast majority of DRT implementations, booking via TDC operators is the prevailing booking method today. In such booking schemes, the DRT end user contacts the TDC on the phone (often through a toll free number) and communicates the details about the desired trip directly to TDC operators. TDC opera-tors use a booking system to handle incoming booking requests by manually inserting travel request, checking user and travel request details, processing travel request and recording the resulting reserva-tions.

ElbaDRT will have a modern IT-supported TDC booking system which will provide a range of facilities to help operators and to speed up travel requests, processing and booking operations, including:

• Order input templates for the TDC operator.

• Digital mapping, address databases and GIS (MapInfo® Geographical Information System) func-

tionalities to help locating pick-up and drop-off points.

• Supporting customers databases to help in order taking, validation and registration (home ad-dress, frequent destinations, preferences, special needs).

• Information about previous bookings to speed up the processing of recurrent reservations, enable modifications and cancellations.

• One or more operator’s workstations (typically, depending on the type, size and operation model of the DRT to be implemented on the Elba island).

• PC based workstation.

• Phone line connection (e.g. dedicated toll-free number) and internet-based customer access to the TDC, for trip booking and service information.

Phone booking is mainly adopted due to:

• the simple interface it offers to end users to access the DRT system (i.e. a simple phone access to a call centre) and

• the element of flexibility it allows in the booking workflow: the human operator can act as a “me-diator” between the user’s request and the service offer, often “negotiating” the service which best suits the requirements of the user in the framework of the service production rules of the DRT op-erator.

Costs of the method are a factor to be considered, though. These include costs of personnel of the call centre and the cost of tool-free telephone lines to access the TDC.

3.3.1.3 Interactive Voice Response Systems

As the volume of booking increases, Interactive Voice Response Systems (IVRS) can be applied to automate the booking cycle. IVRS technology will be available especially for long- and mid-term reserva-tions, and for regular ElbaDRT users and subscribers. In such cases, the load on TDC operators will be considerably reduced by automated collection and processing of the long-term, recurrent travel requests, while leaving non-recurrent requests collection and processing to direct phone call to the operator.

3.3.1.4 Internet booking

Internet booking will be provided as a further booking alternative. As for IVRS booking, internet booking will be a suitable method for long-/mid-term booking schemes and for service subscribers. An internet booking system has also the advantage to provide an access point to ElbaDRT, which will be able to offer



Vers. 1.0


also other services, from automated booking confirmation through e.g. email or SMS, to end users’ cell phones, to public transport information and trip planning facilities.

Basically, both IVRS and internet booking provide the substantial advantage of being available on 24x7 basis, thus considerably enhancing the accessibility to the TDC and to the booking system. This generally can result in higher capacity of booking services and reduction of lost bookings.

Figure 7. ElbaDRT Travel Dispatch Centre

ElbaDRT Travel Dispatch Centre distributed layout

a simpler version may be based on a single, stand-alone workstation

Customer interfaces with the TDC

One or more operator workstations, devoted to different DRT zones

Connection to remote maintenance

services

Central archive, possibly on

dedicated data server



Vers. 1.0


In the following diagram, the required basic steps to set up and run the ElbaDRT Travel Dispatch Centre are identified:

Figure 8. Steps for set-up and running of ElbaDRT TDC

3.3.2 On-street booking

In addition to TDC booking as the main booking method, ElbaDRT will support also some form of on-street booking.

3.3.2.1 Booking terminals

Booking terminals are a way to support on-street booking and are sometimes used to equip dedicated booking points on the street, either at “smart stops” or at public buildings (e.g. hospitals, shopping

centres, etc.). Experiments with magnetic swipe cards have been conducted in Gothenburg (Flexline DRT scheme) with good public response and results for return trip booking. Interactive kiosks, sometimes equipped with graphical displays and touch screens, can be used at bus stops.

Data Collection DRT service design

Identification of the candidate area for DRT deployment, collection of mobility data

Acquisition of base, geo-referenced digital road map

Definition of required DRT service operation model: service times, served user catego-ries, modalities for customer access to service (booking hours, time limits for reservation, service notification modalities and time, etc.)

Identification of type of vehicles and defini-tion of their availability calendar for DRT services

Implementation of a detailed model of the DRT service network. Introduction of required data in the base digital map: road sections, stop points, parking areas, etc.

Set up of (initial) planning data and parame-ters:

- DRT vehicle availability calendar - DRT planning rules - “customer comfort” parameters (max in-

vehicle time, max. delay at pick-up, etc.)

Software installation, configuration, tuning

Ready for Planning and operation of

DRT Services



Vers. 1.0


3.3.2.2 Driver booking

Issuing a travel request to the ElbaDRT driver is another option for on-street booking. This possibility requires the driver to contact the TDC in order to check the validity of the requested trip and its feasibility with respect to the planned services. This can be done, usually, via on-board terminals which, among others, may provide travel request entering facilities, trip validation and submission to the TDC booking system. The modified trip as a consequence of the accepted booking is then communicated to the driver via the communications system and on-board unit.

3.3.2.3 Information and booking on-the-move

ElbaDRT will provide SMS communications facilities, to notify the user about a confirmed booking and give information, for instance, about the planned departure time. Mobile terminals such as PDAs and Smartphone, widely available for mobile internet access, can offer greater options for passenger informa-tion and booking “on the move”.

3.4 Dispatching technology / optimisation tools

The software systems and tools for handling vehicles’ assignment, schedule build up, optimisation and dispatching are the core components ElbaDRT system scheme. Travel Dispatch Centre operators use such tools and components:

• during the service planning phase, to build up consistent trip plans over selected time periods, starting from passengers’ bookings and vehicles’ availability calendars for those periods;

• during the service production phase, to schedule current services, adapt the current trip plans in response to incoming bookings and modify planned or ongoing trips accordingly.

As previously noted for booking technologies (see section 3.3), also dispatching / optimisation compo-nents will be available not as stand-alone systems but as parts of larger, possibly modular systems supporting the main cycle of operations in ElbaDRT TDC, from passengers’ bookings, to service planning, trip scheduling, operation and monitoring.

3.4.1 Methods and main functionalities

Dispatching systems enable dispatch centre operators to adjust the offered service and cost parameters in response to the actual demand. Generally, three main dimensions define the planning and decision making space (see e.g. Finn, 2002):

• the type of route taken (e.g. fixed on-demand, fixed trunks with deviations on demand, free be-tween stop points, door-to-door, etc.);

• the timing of the service (e.g. fixed departure times, max. duration, departure times on demand, non pre-determined max. duration, etc.);

• the vehicle assignment criteria (e.g. vehicles with wheelchair or other special facilities, vehicle characteristics – size, capacity, etc.- in relation to the served area, fleet size in relation to different demand conditions, etc.).

The dispatching / optimisation system for ElbaDRT will support:

• off-line trip planning and vehicle scheduling, based on collected booking requests for a given time period and vehicles’ availability in that period. This might take the form of two different types of basic planning operations:

o off-line planning of a batch of reservations in the given time period, resulting in a service plan (routes and vehicle schedule) for the period;

o off-line updating of a previously defined service plan by insertion of a batch of new reser-vations;

• on-line (real-time) trip planning, vehicle scheduling and dispatching, when new bookings are processed on-line and the current trips are adapted (route modification) as an effect of the new assigned passengers.



Vers. 1.0


ElbaDRT’s dispatching and optimisation tools will offer the following basic functionalities:

• Booking management: in off-line planning operations, passengers’ bookings (collected through the booking system; see previous section 3.2) can be pre-processed to allow grouping and order-ing based on several service criteria (e.g. geographical areas, date and time, type of passengers, preferences, priorities, etc.). In on-line scheduling operations, incoming bookings must be ac-commodated within the current service plans (scheduled trips) taking into account the commit-ments already taken with the other passengers (assigned pick-up and drop-off stops/collect points and times).

• Trip planning: route planning and development based on requested pick-up and drop-off points and times, ElbaDRT service network and the offered scheme (many-to-many, door-to-door, etc.).

• Vehicle assignment: selection and assignment of vehicles to the planned trips, based on available transport capacity and requirements (e.g. wheelchair, accompanying person, baggage, bicycle rack, etc.).

• Driver assignment: assignment of drivers to scheduled trips based on duties.

• Optimisation: the planned service (routes, trips, assigned vehicles) can be adapted to match dif-ferent (often conflicting) criteria for optimal use of resources (e.g. max. number of passengers served, best use of vehicle capacity, uniform use of vehicle capacity, min. mileage, min. duration of trips, etc.).

• Fare management: calculation of fares of trips (different possible options) and presentation of fares to the TDC operator.

• Dispatching: start scheduled trips at departure time, monitor vehicles and runs, track vehicles and trip development (requires automated vehicle location facilities and communication between the TDC and the vehicles).

• Reporting: generation of various types of service reports for both drivers (hand delivery, auto-mated on-board delivery through in-vehicle terminal and communication facilities) the dispatcher and ElbaDRT operator (various types of service statistics).

3.4.2 Technologies

3.4.2.1 Basic TDC architecture

The basic TDC functionalities described in previous section (see 3.3.1.1) can be implemented in different ways. Most existing TDC systems include (see e.g. Figure 9):

• one or more dispatching workplaces (PCs or workstations) allowing TDC operators to serve trip booking, manage ElbaDRT planning, vehicles dispatching and (optionally) service tracking and monitoring;

• one (or more) DB server(s), hosting the different data sets used for ElbaDRT planning and opera-tion (i.e. transport network data, fleet and vehicles data, customers data, service data, etc.);

• a communications server, to enable data exchange between the TDC and the vehicles;

• optionally an internet server, providing internet access to e.g. booking and trip information, users’ portal services, etc., together with a firewall and related secure access services.



Vers. 1.0


Figure 9. A typical TDC deployment architecture.

3.4.2.2 Digital maps and address databases

As for booking systems, also ElbaDRT planning and dispatching applications will use digital maps and address databases to support operations such as:

• display routes and services (both planned and ongoing);

• manually defining or editing automatically computed routes and services;

• display vehicle positions;

• quickly identify passenger pick-up and drop-off points, trip origins and destinations, locations, etc. during DRT operations.

Digital maps are supplied by a number of vendors. Maps and address databases are also supplied by national mapping agencies (e.g. Ordnance Survey in the UK; www.ordnancesurvey.co.uk). Existing products use a variety of formats for graphical and geographic data files, and the use of reference standards for data objects is becoming of an increasing interest. GDF (Geographic Data Files) for example, started as a European standard (CEN GDF 3.0), has become a draft international standard (ISO GDF 4.0) for digital road network data. Transmodel (www.transmodel.org) is a reference data model for public transport IT applications and systems. Use of standards is important, for example, when ElbaDRT dispatching systems will have to exchange data with public transport or traffic applications (e.g. exchange data with a public transport lines database, vehicle or driver shifts database, etc.).

3.4.2.3 GIS systems

Complimentary to digital road maps and address databases is the use of Geographic Information System (GIS) technology. GIS technologies are required to manage digital road maps and any object having a geographic reference, and provide the general software environment allowing easy management of geographic data and information for both software applications and ElbaDRT dispatching operators. GIS applications allow the dispatcher to easily access routes and locations information by simple point-and-click, zooming, panning, etc. operations on the digital map. Likewise, they enable the interaction with (or the integration of) software applications for e.g. automated mapping of location-referenced objects, both fixed and moving, on the map.

dispatcher workstation

data server

Modem

(ISDN, GSM)

printer

Internet services

communication server

dispatcher workstation

firewall

In-vehicle terminals

PDAs, smartphones

(GSM data)

GPRS



Vers. 1.0


Some dispatching systems use (or are compatible with) commonly available, off-the-shelf GIS products

such as Mapinfo (www.mapinfo.com) or ArcView (www.esri.com). This may be an advantage as, often, such GIS tools are used by Public Transport operators also for other type of applications (e.g. regular lines data management, etc.). Other dispatching software use built-in GIS-like functionalities, allowing all basic map management operations but within (often more simple) proprietary applications.

3.4.2.4 Assignment and planning engines

Assignment and planning engines are the fundamental components of any DRT dispatching system, allowing building up consistent service plans by:

• generating, adapting and updating service trips (routing and timing);

• assigning and, where necessary/possible, re-assigning passengers to trips;

• checking and ensuring that at each passenger assignment the time windows of the other passen-gers are respected;

• ensuring that any service constraint related to the service model and vehicle management poli-cies is respected (upper limits of trip durations, driver rest times, vehicle service times, etc.).

ElbaDRT assignment and planning engines of today’s dispatching software take into account several constraints, including for instance:

• number of vehicles;

• capacity of the vehicle;

• vehicle type and characteristics (e.g. length);

• vehicle shifts: availability in time;

• driver shifts;

• number of drivers;

• road characteristics;

• location of parking areas;

• capacity of parking areas;

• commercial speed;

• passenger’s special requirements;

• etc.

As planning and assignment engines represent a critical part of the intelligence of the ElbaDRT dispatch-ing system, the underlying models are usually not disclosed by vendors. Partly based on operation research models methods (e.g. shortest path algorithms, Traveller Salesman Problem algorithms, etc.) the existing systems are often based on proprietary heuristic models.

3.4.2.5 Optimisation engines

Optimisation engines represent the complement of assignment and planning engines and allow (a) optimising service response to users demand and/or (b) minimising the resources used in ElbaDRT production. Optimisation generally refers to (i) better (re-) assignment and/or schedule of passenger rides within each trip (intra-trip optimisation) or (ii) better (re-) assignment of passenger rides between different trips (inter-trip optimisation).

On-line vs. off-line service (trips, vehicles) optimisation is a fundamental aspect of a dispatching system. On-line optimisation has the advantage of a better adaptation of DRT response to customer bookings. However, it implies higher requirements on the optimiser – particularly: the speed of the optimisation model and constraints on reservation time limits – and generally results in a less efficient service sched-ule, given that passengers are assigned to trips sequentially, as orders are received on-line. Off-line optimisation allows for globally more efficient schedule, but it requires batches of bookings are collected much in advance to service production and thus implies less user responsive services.

ElbaDRT dispatching systems adopt a combination of on-line and off-line optimisation: optimisation is applied to batches of long (and mid) term trip requests, which allow requests grouping and inter-trip



Vers. 1.0


optimisation, while on-line request are served, eventually, with insertion in the service plan optimised off-line.

Optimisation criteria used in existing DRT dispatching software are various and may include:

• maximise possibility to serve additional customers;

• minimise amount of vehicles to be used;

• minimise amount of kilometres to be driven;

• minimise on-board time for the passenger;

• minimise amount of passenger travelled distance;

• minimise individual cumulative difference between passenger's requested pick-up time and scheduled pick-up time;

• minimise individual cumulative difference between passenger's requested arrival time and sched-uled arrival time;

• minimise collective cumulative difference between passenger's requested times (for pick-up and arrival) and scheduled times (sum overall).

The most advanced dispatching software allow each operator choosing a combination of optimisation criteria and to set up several parameters in order to achieve a service that meets at best the operator’s service policies.

3.4.2.6 Tracking and monitoring

Trip tracking and tracing and service monitoring techniques use vehicle location data – e.g. GPS location data – and map-matching algorithms to maintain updated vehicle position displays on the dispatcher digital map at regular (usually user defined) time intervals. Major GIS off-the-shelf software includes dedicated plug-ins, which interface the most common GPS receivers and provide the basic engine for tracking and monitoring functionalities. Usually, the monitoring component of ElbaDRT dispatching systems provides also vehicle status information, display of alarms (e.g. stopped vehicle, incident, etc.) and access to messaging services to allow the dispatcher exchanging messages (free or pre-defined text) with vehicle drivers.

ICT and operational requirements for delivery and …-ELBA Document Type / No. / Title Deliverable /...

Documents

Transcript of ICT and operational requirements for delivery and …-ELBA Document Type / No. / Title Deliverable /...