Embed Size (px)
Citation preview
Appendix 1 – List of Cintra Parking/Dornier Assets
January 2008
PARKING LOT SPACES CONTRACTS
ON-STREET
TOTAL MANAGEMENT 145.920 90
PROVISION & MAINTENANCE 7.932 6
MAINTENANCE 2.751 7
Total data on-street 156.603 103
OFF-STRETT
RESIDENTIAL CAR PARKS 27.008 81
GARAGES 83.194 113
Total data out of the Public Way 110.202 194
OTHER ON-STREET SERVICES
TOWING CONTRACTS
86 40
Total Data 86 40
PARKING LOT SPACES CONTRACTS TOWING
TOTAL 266.805 337 86
ON-STREETTotal Management
REGION CITY SPACES
ALICANTE ALCOY 477ÁVILA ÁVILA 1.793BADAJOZ DON BENITO 741
VILLANUEVA DE LA SERENA 489ZAFRA 302
BALEARES ALAIOR (Menorca) 98CALA DEIA (Estival) 65CALA D'OR (Estival) 391CAMPOS 213DEIA 50FELANITX 257FORNALUTX 70MAHÓN (Menorca) 399PALMA DE MALLORCA 7.110POLLENÇA (Estival) 246SA POBLA 265SA RÁPITA (Estival) 219
BARCELONA BERGA 239ESPARRAGUERA 224SAN CUGAT 725SAN JUST DESVERN 197
CÁDIZ CHICLANA DE LA FRONTERA 804JEREZ DE LA FRONTERA 2.497MEDINA SIDONIA 100SAN FERNANDO 639
CANTABRIA CASTRO URDIALES 3.484NOJA 3.001
CASTELLÓN ALCALÁ DE XIVERT (estv) 337BURRIANA 427OROPESA DEL MAR 460PEÑÍSCOLA (estv.) 792SEGORBE 307TORREBLANCA 54
CIUDAD REAL ALCÁZAR DE SAN JUAN 770VALDEPEÑAS 595
CUENCA CUENCA 1.619
GERONA CALONGE Y S. ANTONI DE CALONGE 854LA JONQUERA I EL PORTÚR 121L'ESCALA (Estival) 492OLOT 386PALAFRUGELL 778SANT FELIU DE GUIXOLS 819TOSSA DE MAR (Estival) 138
HUELVA HUELVA 2.326LA RIOJA ARNEDO 316
CALAHORRA 286HARO 475
LEÓN ASTORGA 384LA BAÑEZA 263LEÓN 3.560PONFERRADA 1.769
MADRID ALCOBENDAS 2.517ARANJUEZ 582ARGANDA DEL REY 305MADRID 25.565MAJADAHONDA 1.007
MÁLAGA FUENGIROLA 1.396MÁLAGA 2.330
MURCIA YECLA 338NAVARRA ESTELLA 329
PAMPLONA 5.401PAMPLONA (Ampliación) 7.766TAFALLA 152
ORENSE O BARCO DE VALDEORRAS 501PALENCIA PALENCIA 1.895SALAMANCA BÉJAR 475
CIUDAD RODRIGO 490TARRAGONA SALOU (estival) 1.115TERUEL ALCAÑÍZ 258TOLEDO ILLESCAS 184
OCAÑA 189TOLEDO 8.262TORRIJOS 348
VALENCIA ALDAIA 297ALGEMESÍ 313BENAGUACIL 52CARCAIXENT 319OLIVA 262ONTENIENTE 598REQUENA 199SUECA 188UTIEL 188VALENCIA 7.353
VALLADOLID VALLADOLID 7.119VIGO VIGO 2.850VIZCAYA BARACALDO 13.373ZAMORA BENAVENTE 500ZARAGOZA ALAGÓN 140
CALATAYUD 564ZARAGOZA 6.777
Total Spaces 145.920
OTHER ON-STREET SERVICES
Parking lots in the Public Way. Maintenance
REGION CITY SPACES
ALICANTE DENIA 540
BARCELONA CASTELLDEFELS 700HOSPITALET DE LLOBREGAT 650PRAT DE LLOBREGAT 130SANT CELONI 325VILADECANS 392
VALENCIA CHULILLA 14
Total Spaces 2.751
Parking lots in the Public Way. Provision & Maintenance
REGION CITY SPACES
ÁLAVA VITORIA 4.547BALEARES PUERTO DE PALMA 1.261CASTELLÓN NULES 40GUIPÚZCOA DEBA 284
GETARIA 700ORIO 1.100
Total Spaces 7.932
VEHICLES REMOVAL
REGION CITY BREAKDOWN VANS
ÁVILA ÁVILA 1
BADAJOZ DON BENITO 1
VILLANUEVA DE LA SERENA 1
ZAFRA 1
BALEARES PALMA DE MALLORCA 10
CÁDIZ SAN FERNANDO 1
CANTABRIA CASTRO URDIALES 1
NOJA (Estival) 1CIUDAD REAL VALDEPEÑAS 1
ÁLCAZAR DE SAN JUAN 1CUENCA CUENCA 4GERONA CALONGE Y S. ANTONI DE CALONGE 1GUIPÚZCOA MONDRAGÓN 1HUELVA HUELVA 4
PUNTA UMBRÍA 2LEÓN ASTORGA 1
LA BAÑEZA 1PONFERRADA 2
MADRID ALCOBENDAS 1MAJADAHONDA 2
NAVARRA ESTELLA 1PAMPLONA 8
ORENSE O BARCO DE VALDEORRAS 1PALENCIA PALENCIA 2
PONTEVEDRA LALÍN 1
SALAMANCA BÉJAR 1
CIUDAD RODRIGO 1TOLEDO ILLESCAS 1
OCAÑA 1TOLEDO 3TORRIJOS 1
VALLADOLID VALLADOLID 1 VALLADOLID 5VIZCAYA BARACALDO 5
BILBAO (Aeropuerto) 1PORTUGALETE 1
ZAMORA BENAVENTE 1ZARAGOZA ZARAGOZA 12
CALATAYUD 1
Total Breakdown Vans 86
OFF-STREETGarages
CITY NAME SPACES
ALICANTE La Montañeta 327Escaldes-Engordany (Andorra) Clot D'Emprivat 525
Prat Gran 300ÁVILA El Grande 269
El Rastro 242Los Jerónimos 126
BADAJOZ San Atón 421BARCELONA Joan de Borbó 656BENAVENTE La Mota Vieja 290BILBAO Alhóndiga 983
Pza. Indauxtu 565BURGOS Pza. España 354CIUDAD REAL Pza. Mayor 216CUENCA Princesa Zaida 318ESTELLA Plaza de la Coronación 417FIGUERAS Passeig Nou 303GERONA Poeta Marquina 354GIJON Jardines Naútico 565HOSPITALET Ajuntament 302HUELVA Edificio Huelva 325JEREZ Alameda Vieja 300
Pza. Mamelón 376LAS PALMAS San Bernando 337MADRID Casino de la Reina 562
Fuencarral 410Las Cortes 480Pº de Recoletos 389Pza. Colón 605Pza. España 826Pza. Mayor 684Pza. Salamanca 430Sevilla 669
MÁLAGA Alcazaba 532Avda. Andalucía 908Camas 458Carlos Haya 455Cervantes 860Cruz Humilladero 237El Palo 276La Princesa 415Pza. Marina (central) 450Salitre 650San Juan de la Cruz 702Tejón y Rodríguez 262
MATARÓ Les Tereses 337MURCIA Glorieta España 351
Santa Isabel 158NOJA Plaza de Noja 145ONTENIENTE San Jaime 79PALAFRUGELL Can Mario 167PAMPLONA Bca. de Navarra 390PONTEVEDRA Montero Rios 375
Plaza España 336SABADELL Espronceda 253SALAMANCA Santa Eulalia 242SALOU Playa de Levante 545SAN JUAN DE PUERTO RICO Convalecencia 697SANT CUGAT Lluís Millet 280
Monestir 182Quatre Cantons 228Rambla del Celler 200
SANT FELIU DE GUIXOLS La Corxera 400Plaça del Mercat 88
SANT JUST DESVERN Mil.lenari 135SAN SEBASTIÁN Cataluña 477
Concha 624Oquendo 1.505
SANTANDER México 523Pombo 345
SEVILLA Colegio San Fernando 470TARRAGONA Rambla Nova 860TENERIFE Ramón y Cajal 466VALLS Plç del Pati 227ZAMORA Marina Española 350
Total Spaces 31.566
OFF-STREET
AIRPORTS
CITY NAME SPACES
ALMERÍA Aena Aeropuerto 319GRANADA Aena Aeropuerto 450
LANZAROTE Aena Aeropuerto 1.632MADRID Aparc. Larga Estancia 2.867
MADRID Dique Sur 748MADRID P-5 AENA 2.700
MADRID Parking Express-AENA 39MADRID T-4 14.046
MURCIA Aena Aeropuerto 1.102PALMA MALLORCA Aparc. Larga Estancia 1.630
PAMPLONA Aena Aeropuerto 535SAN SEBASTIÁN Aena Aeropuerto 311
TENERIFE Aena Aeropuerto Norte 1.561VALLADOLID Aena Aeropuerto 379
VIGO Aena Aeropuerto 680VIGO Parking Express-AENA 22
VIGO Parking Terminal de carga-AENA 30
Total Spaces 29.051
PORTSCITY NAME SPACES
SEVILLA Puerto de Sevilla 264
Total Spaces 264
SHOPPING CENTRESCITY NAME SPACES
MURCIA Zig-Zag 650MARBELLA Mercado Municipal 459
PUNTA UMBRÍA Mercado Municipal de Abastos 375SANTIAGO Área Central 785
SAN SEBASTIÁN Atocha 231VALENCIA Mercado de Colón 146
Mercado de Ruzafa 346
Total Spaces 2.992
HOSPITALSCITY NAME SPACES
BARCELONA Hosp. Sagrado Corazón 438Espíritu Santo 546
FIGUERAS Hosp. Figueras 414
MADRID Hosp. La Concepción 354Hosp. Ramón y Cajal 1.790
PAMPLONA Clínica Universitaria 958Zona Hospitalaria 1.408
VALLS Sant Francesc 220Fincas Paradis 153
Total Spaces 6.281
EXHIBITION CENTRESCITY NAME SPACES
IRÚN FICOBA 928
ZARAGOZA EXPO 08 10.081
Total Spaces 11.009
NATURE RESERVES
CITY NAME SPACES
RIBADELAGO (ZAMORA) Lago de Sanabria 495
Total Spaces 495
AUDITORIUM AND CONFERENCE CENTRESCITY NAME SPACES
BARCELONA CILSA 636
PAMPLONA Baluarte 900
Total Spaces 1.536
TOTAL SPACES 51.628
OFF-STREETRESIDENTIAL CAR PARKS
CITY NAME SPACES
BADAJOZ Plaza Alféreces 282BARCELONA Arnau D'oms 334
Casa Groga 235Forum Nord 294Lorena 262Plaza Verda 262Revolución 226Santa Otilia 247Torre LLobeta 220Valldaura 332
BILBAO Alamada Mazarredo 182Azoka 200Jado 272Jardines 270Sarrito 180
GRANADA Albert Einstein 225L'HOSPITALET Can Serra 370
Primavera I 230Primavera II 267Primavera III 260Severo Ochoa 260Travesía Industrial 229
LOGROÑO Plaza 1º de Mayo 329Carmen Medrano 122
MADRID Andévalo 313Aguilar de Campoo 304Aluche 206Azuaga 294Cabestreros 321Conde de Casal 1.947Díaz Porlier 421Doce de Octubre 687Domenico Scarlatti 485Emigrantes 281Esteban Villegas 858Menorca 860Ofelia Nieto 165Pablo Casals 154Plaza Sta. Cruz 152Pza. Agustín Lara 289Rutilio Gacis 602S. Antonio de la Florida 185Sancho de Córdoba 472Valparaiso 576Villamarín 306Virgen del Puerto 793
MÁLAGA Antonio Gaudí 201Avda. Europa 839Cruz del Humilladero (Camino San Rafael) 250Bonaire 255Nueva Málaga 206Capuchinos 497El Ejido 221Torcal (José Palanca) 213Jardín de Málaga 141Gamarra 309Girón - Las Delicias 283La Roca II 173La Trinidad 225La Unión 414La Asunción 216Martiricos 165Mediterráneo-Delicias 261Puerta Blanca (Menorca) 259El torcal (Niño de Gloria) 405Miraflores-Suarez 244Parque del Oeste 786Parque del Sur 134Pedro Gómez Chaix 195Puerta Blanca (Viña del Mar) 180Cruz del Humilladero (Conde de Guadalhorce) 250Jardín de la Abadía 257San Andrés 249Santa Cristina 239
PALMA DE Alexander Fleming 362MALLORCA Pedro Garau 214
Plaza Madrid 239Plaza Serralta 262
SEVILLA Virgen de Loreto 465VALENCIA General Urrutia 266VITORIA Parque Judizmendi 372
Total Spaces 27.008
Appendix 2 – Environmental, Health and Safety Policy in Cintra
& IQNet Quality Management Certificates
Manifesto of Values
At a Strategy Meeting on 13 April 2005, CINTRA's Management Committee decided to draw up a Statement of Values for the Company, setting out the basic principles to witch Cintra employees, executives and subsidiaries must adhere. Concerning its employees
• Respect, equal opportunities and non-discrimination
• Commitment to implementing safety and health policies individually and collectively
• Respect for the privacy and confidentiality of information
• Encouraging a balance between personal and professional lives
• Opportunity for career development and taking responsibilities according to its flat organization
Commitments with third parties and the market
• Creating value through growth
• Fair competition
• Transparent management
• Quality of service
• Confidentiality regarding third-party information Regarding the community
• Conducting business in a socially responsible way
• Environmental commitment in the development of business
• Assumption of the principles of the United Nations World Pact in the performance of business activities
Appendix 3 – SIGMA Maintenance System
Summary:
Introduction
SIGMA ORA Module
Pocket SIGMA ORA Module
1
INTRODUCTION
Based on its experience in managing Street Parking Regulation services and the
maintenance work associated with them, Cintra Parking//Dornier has created a
comprehensive, integrated maintenance system. A new system that speeds up both
preventive and corrective maintenance, increasing efficiency and the good condition
of the equipment and installations connected with these services.
The proposal is based on the use of a web-based computer system (DB SQL Server and
.NET development platform) responsible for managing the different existing alarm and
maintenance systems, specifically designed for the personnel involved in the Regulation
of Street Parking.
The basic goals of the Maintenance Management System - SIstema de Gestión de
MAntenimiento in Spanish (SIGMA) are to:
• Minimize repair times in response to any incidents on the Street. Speed up
processes.
• Computerize incident documentation, maintaining the required quality format.
• Have information at all times on the evolution of a particular report or the
resolution of an incident.
• Provide easy handling.
• Mobility of the system, allowing reports to be prepared at the incident location.
• Easy implementation of the system.
2
The system is made up of two interconnected subsystems:
SIGMA POCKET SIGMA
1.- SIGMA Central subsystem or module: This consists of an SQL database and a portal
developed with .NET, where all of the elements connected with maintenance are
managed:
a) Daily new developments sheet.
b) Preventive and corrective maintenance action tickets.
c) Management of planning of preventive actions.
d) Monthly report of correction tickets.
e) Ticket query summary.
f) Administration of service center configuration elements.
g) Stock Management
h) Verification of the log and inventory of assigned dispensers.
2.- SIGMA POCKET subsystem or module: this consists of a PDA-based system that
basically gives maintenance technicians mobility to carry out the following functions
from any location in the work center (at the incident location)::
i) Generation of the new developments sheet.
j) Creation of a correction ticket.
k) Query and modify correction tickets.
l) Include photographs in correction tickets.
m) Synchronization with the SIGMA system, maintaining information consistency.
n) Receiving messages to send corrective maintenance notifications.
3
o) Status and evolution of preventive maintenance activity planning.
p) Verification of the log and inventory of assigned dispensers.
q) Sending general communications assigned to the service with the central station
and vice-versa, using a GPRS-based messaging system.
Both subsystems have an access system that requires validation with a user/password. It
can manage the user, under a specific profile, giving access to some activities or others
within the system itself.
4
SIGMA O.R.A. MODULE
MAINTENANCE MANAGEMENT
As mentioned before, the SIGMA system is subdivided into two modules. SIGMA’s Central
Module is a Web Portal (INTRANET) that interconnects the main SIGMA database, as well
as with other systems such as the parking meter notification systems, other municipal
systems, and of course with POCKET SIGMA.
In any case, although the proposal prepared for the city of Vigo is complemented with
POCKET SIGMA, this module can function independently.
The first screen is the identification and authentication screen (user + password), and
depending on the permissions assigned to users, they will be able to access some options
or others in read-only or read-write mode, which are fully configurable by the system
administrator.
Once the user identification has been verified and accepted, the basic work screen will
open.
5
This is the basic work screen. It shows the user who has entered the system, a menu on
the left side of the window, a submenu that varies depending on the option selected in
the main menu, and a content page as part of the main page:
User Submenu
Main menu Page content
To guarantee correct functioning, the system has been designed to be fully configurable
according to the operating center. Different administration screens
(ADMINISTRATION/SIGMA ORA) have been created for configuration:
Add dispenser to SIGMA (Dispensers). The first step is to enter all of the dispensers into the
SIGMA Database. This information can be collected from any Database or can be
entered manually.
The information processed is: dispenser code, location (zone, neighborhood, and
address), manufacturer, model, power supply, ticket type, and components table (part,
serial number).
6
Each one of the dispensers can in turn be configured (part by part). To access this
configuration, just click the Components button to the right of each dispenser.
The system includes an Online Dispenser List (Dispenser List) which shows all of the
dispensers entered in the system for the particular center and their characteristics.
7
Adding Maintenance Technicians to SIGMA. All maintenance personnel must be
identified to provide the necessary coherence with POCKET SIGMA. This data is entered
manually through an administration data entry screen at the central office.
Option managed by System Administrator
Assigning Dispensers to Technicians (Technical Route). This tool is essential with large
numbers of dispensers, because the management of shifts and the assignment of
maintenance routes to technical personnel become exponentially more complicated
with the number of machines to be maintained. The assignment of shifts and dispensers is
done using a help tool incorporated into the SIGMA system.
8
Adding zone controllers (Controller). This tool is required to add zone controllers to the
system. This way, when an incident is reported, the system will have a record of the
controller that created it.
Configure preventive planning and stock (Frequency and Range). One allows the
configuration of the frequency of preventive maintenance for the different dispenser
components; and the other, the minimum desired stock by component, in order to
configure the alarm manager.
9
The system is equipped with a log file (Dispenser Log) that will show all of the different
maintenance activities of a dispenser (both corrective as well as preventive, with
comments). This log file or list for a dispenser provides significant analysis capacities to the
center’s maintenance supervisor, making it possible to detect common errors on the
machine. It has filtering criteria to show the desired information.
10
The SIGMA system includes tools to manage incidents and malfunctions that arise during
the day-to-day operation of different dispensers. The different tools allow users to create
incidents (Detected Malfunctions and Incidents) and note repairs and actions carried
out by the maintenance technician (Daily Interventions).
The Detected Malfunctions and Incidents tool allows any incident that requires action by
a maintenance technician to be created in the system. A list will also be shown with the
different incidents assigned to a particular maintenance technician.
The Daily Actions file will allow a particular technician to view the maintenance tasks that
must be carried out. This tool is designed to be printed and presented to the technician
in question with all of the information required to identify the incident, as well as the entry
of information regarding the work carried out during the absence. Obviously, since this is
integrated with POCKET SIGMA, this printing is unnecessary.
11
Management of planning of preventive actions is implemented. This includes the annual
creation and the tracking of actions carried out. The system includes data entry so that
the preventive maintenance manager can add the plans for each year (Frequency,
mentioned earlier). The system allows plans from previous years to be copied and
modified to facilitate her operation.
The system includes a user interface that makes it possible for users to quickly access the
preventive maintenance actions carried out.
A Dynamic Alarm System is included, which makes it possible to send notifications via
email and from the application itself, to the center’s supervisor, when a preventive
maintenance date has passed without the work being done.
12
The preventive maintenance alarm system has a user interface (alarm list) that helps
operators to resolve them, for example, notifying the Technicians responsible for
maintenance, or classifying the alarm as terminated. This alarm system shares
infrastructure with the stock alarms.
One of the most important characteristics of the XER center maintenance system is Stock
Management. A stock of spare parts is associated and must stay within a determined
range (Range, minimum stock).
Dispenser maintenance and repair maintenance generate fluctuations in the available
spare parts. The following function will be implemented for stock management.
Create Tickets, which involves the replacement of parts with others in stock. The
available part will be subtracted from stock, and the stock with defective parts will
increase.
Adding Parts as a result of new acquisitions.
Deleting Parts, because they cannot be repaired, have become obsolete, or for some
other reason.
Spare Part Management is included, which allows the center to determine when it has
enough parts to create a shipment and send it to a repair workshop. The following
functions are included in this management:
13
Creation of shipments and generation of delivery notes.
Component to assist in the validation of returned components from repair centers.
The system has an Alarm System to prevent the center manager from possibly running
below the minimum stock level.
These alarms can be configured for each component category.
Alarms can be managed from a screen that allows consultation and modification.
Alarms will be sent both via email and through the application.
Management of General Entities connected with stock management: component
categories, thresholds, workshops, and staging centers.
Stock Management screen:
14
15
POCKET SIGMA O.R.A. MODULE
The subsystem called POCKET SIGMA includes two basic functions:
Dispenser maintenance system based on mobility.
System of messaging with the central office.
The initial screen includes the two applications or subsystems with the basic work options:
OPEN A TICKET, the technician selects this option when he detects that corrective action
needs to be carried out on a dispenser.
PENDING TICKETS, in this option, the technician accesses all of tickets that are pending
regardless of the reason (both prevention and correction tickets).
PREVENTIVE MAINTENANCE, this heading covers the screens that are directly related to
the preventive maintenance process.
16
ASSISTANTS, this heading covers a series of functions, both informational and in
connection with maintenance that help the technical personnel.
MESSAGES, access to the messaging module.
This is in turn the screen that will indicate that there is a new ticket or received message.
When the terminal receives a new ticket or a new message, in addition to beeping, the
system locks on this screen until the technician reads the ticket or received message. This
solution has been implemented this way to avoid the possibility that messages or tickets
will not be read.
POCKET MAINTENANCE
New Correction Ticket Generated from the Central Station.
The arrival of a new work ticket will be indicated by the appearance of the message
New ticket received on the start screen.
17
When the New ticket received icon is clicked, the Tickets screen opens. This screen shows
all of the information on the malfunction that generated the correction ticket.
The displayed information can be divided into three parts, by selecting the
corresponding tabs.
TICKET. This screen is a constant for most of the screens in POCKET SIGMA. It
identifies the dispenser, as well as the ticket ID (read-only).
DESCRIPTION. This screen displays a description of the malfunction or action to be
carried out (read-only).
18
DETAILS. This part of the screen shows the description of the work done, with the
technician entering the following information:
• Description of the work to be done (free text).
• Part Replacement, indicate the code for the new part and for the replaced
part. This field is a list, since a malfunction may require the replacement of more
than one part. The OK and Cancel buttons are used to accept or not accept
the part replacement.
• PHOTO, the possibility of including photographs is interesting in cases in which
the malfunction is due to vandalism.
19
Button Zone:
PROVISIONAL (provisionally closed). This button is used by Technicians when
malfunctions cannot be completed (for lack of parts or other reasons) and
completion must be postponed.
CLOSED. When the Technician has finished resolving the incident.
Another option is to use the TOOLS menu, from any of the previous screens, and
from most of the screens in the application.
20
LOG. When this button is pressed, it links to the Log for the dispenser
on which the work is going to be done. This gives the Technician the
details of other prior actions carried out on the same machine.
INVENTORY. When this button is pressed, it links to the Inventory
screen for the dispenser on which the work is going to be done. This
gives the technician details on the machines component parts.
New Correction Ticket Generated on Mobile Terminal
As shown in the attached screenshot, this is the same as the one described earlier in this
document, except that it is a writing operation. This option is used when maintenance
technicians detect anomalies during inspections and immediately generate a correction
ticket.
21
22
In addition to the options (buttons) described earlier, the SEND option is added to the
menu bar. It has two functions:
• Actually create the ticket and assign the Ticket Code.
• Send the ticket to SIGMA’s Central Database.
PENDING TICKETS SCREEN
This screen is a list of all of the pending tickets, organized by dispenser.
The pending tickets also include the prevention tickets that are generated by the
planning done on the SIGMA platform.
This screen is simply an informational screen that links to other sections of the application,
depending on the fields that are selected:
• Selecting the dispenser field (DISPENSER-dispenser code) opens the
dispenser inventory screen.
• Clicking on the ticket number (Notified) links to the ticket description
screen.
23
DISPENSER INVENTORY
This screen is merely informational and displays all of the parts that make up the
dispenser, along with the serial number. As mentioned in earlier points, these screens can
be accessed from most of the work screens in the POCKET SIGMA application, clicking
the INVENTORY option on the TOOLS menu.
24
DISPENSER LOG
As with the previous screen, this is merely informational, and is accessible from most of
the work screens by clicking the LOG button on the TOOLS menu. Clicking on the ticket
number (Notification Nº) links to the screen for the associated ticket.
25
Preventive Maintenance
This option is accessible from the main screen by clicking the PREVENTIVE MAINTENANCE
button.
26
All of the maintenance functions to be carried out for a particular dispenser are
displayed, with the possibility of specifying the part replacement (if necessary) and a free
text field for comments.
27
For a preventive maintenance ticket, the maintenance technician will check off the
different tasks carried out.
To indicate the replacement of a part, the technician clicks on the button with the three
dots to open the following screen.
28
Maintenance tasks are planned from SIGMA.
29
Appendix 4 – Internal Center Management
Summary:
Introduction
Payment Management and Control
Personnel Management
Element Management
Ratio Analysis
Messaging Web-Application for PDA
1
INTRODUCTION
SENA includes a series of web-based utilities that allow supervisors of the center and the
central offices to have up-to-date control over the payments collected by the center, as
well as the basic information such as the information for controllers, technical personnel,
inspectors, and drivers.
This will allow the center to include all of the payments collected during the life of the
center (daily, weekly, monthly, etc.) giving it automatic control over payment collection.
It will reflect all of the important events related to personnel:
• Date added.
• Date removed.
• All personal information.
• Personnel-related incidents:
1. Sick leave.
2. Vacations.
3. Union hours.
4. Late arrivals.
5. Absences.
6. Etc.
Incidents related to the materials provided to personnel:
• Mobile terminals (PDAs).
• Printer.
• Etc.
Access is by entering a user name and password, with a wide variety of permissions,
depending on the profile assigned to the user. This secures access to the data that
includes personal information and also maintains the information on who accesses, who
changes data, and when they changed it.
2
Once the user and password have been validated, the application’s main screen opens.
A user with the highest level of permissions is used as an example in this document.
The data is stored in an SQL Server Database and can then be analyzed statistically using
the analysis application included in SENA.
3
PAYMENT MANAGEMENT AND CONTROL
The purpose of this tool is to accelerate payment collection control processes from the
central station, and to automate the accounting processes with SAP. The tool, in turn,
when organizing the data in a database allows a series of reports to be generated to
facilitate the interpretation of the data and the management study for the supervisor
and operating manager in the central offices.
With this module the center supervisors can include the economic data for the parking
meter collections, according to the established procedure carried out daily, weekly, and
monthly.
4
They can generate their payment collection balance sheet, with the format that
complies with the quality directive:
5
As well as the display of the different reports defined:
Since this is a web tool, the information can be verified from any point on the intranet,
facilitating management from the central station, and therefore automation to SAP.
6
7
PERSONNEL MANAGEMENT.
This module is designed to provide a tool for the daily management of the center, but not
management of payroll or any similar tools. The basic functions of the personnel
management module are:
Current staff status, as shown in the screenshot below:
List of all controllers, with the possibility of selecting according to the following options:
• New.
• In removal.
• Morning Shift.
• Afternoon Shift.
• All.
8
Controller Log, where the following can be analyzed for each controller: Controller Log, where the following can be analyzed for each controller:
• All incidents. • All incidents.
• The reason for each incident. • The reason for each incident.
• Incident details. • Incident details.
9 9
ELEMENT MANAGEMENT.
This module gives absolute control over all of the dependent hardware elements in the
center, especially:
• PDAs or infraction terminals.
• Printers.
The following screenshots show the work screens for this area:
10
11
RATIO ANALYSIS.
The most important module in SENA from the management point of view is the “analysis
module”.
This tool is based on a Business Intelligence system that allows data from different sources
to be integrated and presents information in a quick, useful, and visual manner.
One of the strong points of the analysis is the comprehensive management of infractions.
From SENA, users can access a screen analyzing the infractions for the day:
Or the Analysis tool which provides access to other types of information with historic data
and the possibility of analyzing trends. The screenshots below provide a sample of some
of the functions and potential uses for this tool.
12
13
This tool, in addition to analyzing the basic infraction data, also integrates the messaging
and payment collection data.
Some of the ratios analyzed are:
• % Paid Occupation.
• % Vehicle infraction occupation.
• Rotation Index.
• Infractions by articles.
• Infractions by street and zone.
• Infractions by controller.
• Infractions by date.
• Payment collection.
• All of the crosses of the aforementioned parameters.
14
MESSAGING WEB-APPLICATION FOR PDA
DESCRIPTION
This application carries out the function of Mobile Messaging to allow communication
between Company personnel. Messages can be sent from Controller to Base, from
Technician to Base, from Inspector to Controller, etc. depending on the permissions that
correspond to the user who is using the PDA.
In addition to sending messages, users can consult received messages, facilitating daily
work, for example for Technicians, who can consult dispenser tickets without moving to
Base or calling, to review Tow-Truck Assignments for the current day, and operational
incidents with the service can be handled from the street by inspectors, etc.
USER VALIDATION
The PDA Messaging Website will include user control to provide secure usage, with
restrictions depending on user type.
When the web page is accessed, users must enter a user name and password, which will
then be validated, and users will then be redirected to another screen depending on
their permissions.
15
SENDING MESSAGES
When sending a message, the user selects the Recipient device and fills in the text
message with the message to be sent.
To select the device, there is a drop-down menu that will include all of the possible
destinations to which the user working with the application can send messages.
16
CONSULT RECEIVED MESSAGES
The following types of messages can be consulted:
• Service Incidents.
• Citizen Assistance Incidents.
• Tow-truck notifications.
• Dispenser Incidents.
All of the messages displayed will be for the current day.
The user selects a type and clicks Display.
A list will be displayed with all of the corresponding received messages, with the
possibility of viewing the specific details for each one.
17
In the case of messages for parking meters, the user can specify the handling of the
incident so that there is a record of when the repair process began, and complete it to
record the end of the action.
ADDING USERS
The Add Users page is accessible to the Administrator user only. The following must be
specified:
• User Name.
• Password.
• Service Incident Display Permission.
• Citizen Assistance Incident Display Permission.
• Tow-truck notification Display Permission.
• Dispenser Incident Display Permission.
• Permission to Send Messages to Controllers.
• Permission to Send Messages to Inspectors.
• Permission to Send Messages to Technicians.
18
19
Appendix 5 – Client’s Satisfaction Survey
(Translated – original follows)
I, PRUDENCIO LOUREIRO PEREZ, Co-ordinator of the Municipal Services of
the Illustrious Barakaldo City Council
DO HEREBY CERTIFY
That DORNIER, S.A. is the concessionaire of the Management of the Time
Control Service at the Car Park and the Vehicle Towing and Pound Service in
Barakaldo as from the first day of October nineteen hundred and ninety-eight,
with the said concession expiring on the thirtieth day of September two
thousand and three, without prejudice to any extensions that may be agreed.
That the number of spaces currently regulated by the Management of the Time
Control Service at the Car Park following the expansions carried out on the first
day of October nineteen hundred and ninety-nine (Expansion no. 1), the first
day of April two thousand (Expansion no. 2), the first day of July two thousand
(Expansion no. 3), and 26 July two thousand and one (Expansion no. 4) is
12,242, with a total of 322 issuing machines installed.
That for the performance of the Vehicle Towing and Pound Service, it is in
possession of a fleet of FIVE tow trucks equipped with the features necessary in
order to function properly.
In witness whereof and for all pertinent effects, I hereby set my hand to this
Certificate in Barakaldo, on the third day of April two thousand and two.
[illegible rubber stamp]
[illegible signature]
[on the headed notepaper of the Illustrious Barakaldo City Council]
[Urban Planning and Municipal Services Area]
Ver
ified
TH
E M
UN
ICIP
AL
SE
RV
ICE
S C
O-O
RD
INA
TOR
S
igne
d: P
rude
ncio
Lou
reiro
Per
ez
[rubb
er s
tam
p: B
AR
AK
ALD
O C
ITY
CO
UN
CIL
– M
UN
ICIP
AL
SE
RV
ICE
S]
[ille
gibl
e si
gnat
ure]
I, HUMBERTO ESTEBANEZ MARTIN, LAWYER, GENERAL SECRETARY OF
THE ILLUSTRIOUS BARAKALDO CITY COUNCIL (VIZCAYA)
DO HEREBY CERTIFY:
That according as is recorded in the documentation held at the
department of Municipal Services of the Urban Planning and Municipal Services
Area, the Company DORNIER, S.A.U. is the concessionaire of the Contract for
the Time Control Service at the Car Park and the Vehicle Towing, Pound, and
Immobilization Service in within the Municipal District of Barakaldo, regulating a
total of 11,674 parking spaces and in possession of a fleet of 5 tow trucks.
That the said Services have been provided since 1 April 2004, and were
awarded following a resolution by the Governing Board no. 12/2004 of 22 March
2004, for a term of two years.
In witness whereof, at the request of the interested party, DORNIER,
S.A.U., and for the purpose of the classification of service companies, I hereby
issue these presents with the counter-signature of the Mayor, in Barakaldo, on 6
July 2005.
counter-signed
THE MAYOR [illegible rubber stamp]
[illegible signature] [illegible flourish]
[on the headed notepaper of the Safety and Regional Services Governmental Area
(Madrid) – Vehicle Parking on the Public Highway Department]
I, Mr. Miguel Angel Milla Hernandez, Assistant of the Vehicle Parking on the Public
Highway Department of the Most Excellent Madrid City Council, which is the licensor
body for the Regulated Parking Service (S.E.R.) in Madrid
DO HEREBY DECLARE:
- That the company DORNIER, S.A., the contractor of the said services in the so-
called Zone III, commenced performance in November 2002 in the first tranche and
with the following characteristics:
- The term of the service shall be for eleven years commencing as from the date
the contract is executed.
- The annual price of the contract corresponding to the first tranche: four million,
two hundred thousand euros (€4,200,000.00), including VAT.
- Number of spaces corresponding to the first tranche: 12,232 spaces.
- That the company DORNIER, S.A., on 1 June 2004, has implemented and is
managing the first expansion, within the zone awarded to it, and with the following
characteristics:
- Annual price of the contract corresponding to the first tranche: five million, six
hundred and eighty thousand, five hundred and eighty euros, thirty euro
cents (€5,680,580.30), including VAT.
- Number of spaces corresponding to the first expansion: 14,735 spaces.
- That the services consist in:
- Issuing the corresponding penalty notices for infringements of the highway code
and the by-laws regulating restricted parking.
- Controlling all vehicles that park within the zone awarded to it, verifying that
they all comply with the duty to display the necessary ticket, without exceeding
the maximum time allowed, or that they display the residents’ parking permit,
within the appropriate district.
- Attending to requests for information by users and the general public.
- Verifying and ensuring the correct functioning of the ticket machines, including
their preventive and corrective maintenance.
- Upkeep of all vertical and horizontal signage, including the repainting of
horizontal markings and the replacement of vertical signs.
- That DORNIER, S.A. has been managing the Service in strict compliance with the
Schedule of Conditions, the Municipal By-laws, and to the full satisfaction of this
Authority.
In witness whereof, at the request of DORNIER, S.A., and for the purpose of the
classification of Service companies, I hereby sign these presents in Madrid on 24 June
2005.
THE ASSISTANT OF THE VEHICLE PARKING
ON THE PUBLIC HIGHWAY DEPARTMENT
[illegible signature]
Signed: Mr. Miguel Angel Milla Hernandez
[rubber stamp of the Safety and Regional Services Governmental Area (Madrid) –
Vehicle Parking on the Public Highway Department]
Ajuntament de Palma
I, JOSE MARIA MIR DE LA FUENTE, GRADUATE IN LAW, LOCAL ADMINISTRATION SECRETARY, HIGHER CATEGORY, WITH POWERS TO ACT NATIONALLY, CURRENT SECRETARY OF THE MOST EXCELLENT PALMA DE MALLORCA CITY COUNCIL
DO HEREBY CERTIFY:
That at the plenary session of the Palma City Council, at the meeting held on 27-07-2000, the Contract for the Concession of the Technical Assistance, Supply, and Maintenance Service for the installations and proceeds of the ticket machines related to the public municipal service for the regulation of parking on the public highway (ORA) was awarded to DORNIER, S.A. by way of a public tender process. That the award was for a term of four years with expected annual extensions up to a maximum total for the Contract of six years. That at the plenary session of the Council held on 13-07-2001, it was resolved to award DORNIER, S.A. an extension to the Contract, which entailed an increase in the number of spaces managed, as well as of ticket machines installed, with the same conditions being applicable to this extension as to the initial Contract, and with the same expiry date. That the initial award and extensions include the following number of spaces and ticket machines: Award dated 27-07-2000 2,737 spaces and 275 ticket machines Award dated 13-07-2001 690 spaces and 34 ticket machines ----------------- ---------------------------- Total 8,427 spaces and 309 ticket machines That the start dates for the Service were 01-10-2000 and 01-10-2001, respectively, and their expiry date 30-09-2004, with a possible extension to 30-09-2006. That during the time that DORNIER, S.A. has been managing the Contract, it has done so in strict compliance with the Schedule of Conditions, the Municipal By-laws, and to the full satisfaction of this Authority. In witness whereof, at the request of DORNIER, S.A., I hereby issue this certificate with the counter-signature of Her Excellency the Mayoress, in Palma de Mallorca, on the twenty-ninth day of June 2004. COUNTER-SIGNED [illegible signature] THE MAYORESS [rubber stamp in Catalan] Signed: Catalina Cirer Adrover
[on the headed notepaper of the Pamplona City Council – Citizen Protection Area – Management]
I, JESUS MARIA SALINAS ANDUEZA, TECHNICAL SECRETARY OF THE CITIZEN PROTECTION AREA OF THE MOST EXCELLENT PAMPLONA CITY COUNCIL DO HEREBY REPORT: That the Plenary Session of the Pamplona City Council, at its meeting held on 3 October 2002, awarded the contract for the towing of vehicles from the public highway, subsequent custody thereof, and support to the Municipal Police Force and Civil Protection Brigade, to Dornier, S.A.. The service was awarded for the year 2003, with the possibility of five extensions of one year each unless one of the parties should repudiate. That the service includes:
- The towing of vehicles from the public highway at the request of the Municipal Police Force or of the traffic wardens covering the regulated parking zone, in order to transport them to the municipal pound or to such place as may be indicated.
- The custody of the vehicles deposited at the municipal pound. - To support the Municipal Police Force in the tasks of collecting the fees for
towing vehicles from the public highway, the collection of fines, and the service of the penalty notices issued to vehicles prior to being towed away.
That in order to provide the service, Dornier, S.A. places three Nissan Cabster tow trucks and eight Nissan Patrol tow trucks at the disposal of the Pamplona City Council. That the service is provided correctly and in accordance with the provisions contained in the schedule of administrative and technical clauses. In witness whereof, this report is issued at the request of Dornier, S.A. in Pamplona, on the twenty-eighth day of June two thousand and four. [illegible flourish] [rubber stamp of the Pamplona City Council – Civil Protection Area]
[on the headed notepaper of the Pamplona City Council – Citizen Protection Area – Management]
I, JESUS MARIA SALINAS ANDUEZA, TECHNICAL SECRETARY OF THE CITIZEN PROTECTION AREA DO HEREBY REPORT AS FOLLOWS: That at the Plenary Session of the Pamplona City Council, in accordance with the resolution of the Local Government Meeting dated 11 October 2005, the contract for the management of the service for the regulation of time-restricted parking on the public highway in the districts of Iturrama, La Milagrosa, and San Juan, in the City of Pamplona, were awarded to Dornier, S.A.. The term of the contract is ten years, expiring on 31 December 2015, which may be extended for a maximum of five years. The number of spaces included within the regulation scope of the said contract is 7,365 spaces. The number of ticket machines covered by the said contract is two hundred and two. It is expected that the service will commence in the coming month of January 2006. Hitherto the process for the implementation of the service is being carried out in accordance with the Schedules of Conditions in force and the offer presented to Pamplona City Council by Dornier, S.A..
Pamplona, 12 December 2005
[illegible flourish]
[rubber stamp of the Pamplona City Council – Civil Protection Area]
[on the headed notepaper of the Pamplona City Council – Citizen Protection Area – Management]
I, JESUS MARIA SALINAS ANDUEZA, TECHNICAL SECRETARY OF THE CITIZEN PROTECTION AREA DO HEREBY REPORT AS FOLLOWS: That at the Plenary Session of the Pamplona City Council, at the meeting held on 28 August 1998, the contract for the management of the service for the regulation of time-restricted parking on the public highway for a part of the City of Pamplona, was awarded to Dornier, S.A.. The regulated parking service commenced operation on 11 January 1999. The term of the contract is ten years, which may be extended for a maximum of five years. The number of regulated spaces as at today’s date is approximately 5,500 spaces. The number of ticket machines installed amounts to two hundred and five. Hitherto the service has been provided in accordance at all times with the Schedules of Conditions in force and to the full satisfaction of the Citizen Protection Area of the Pamplona City Council.
Pamplona, 12 December 2005
[illegible flourish]
[rubber stamp of the Pamplona City Council – Civil Protection Area]
[on the headed notepaper of the Toledo City Council – Local Police Force]
I, MR. JOSE MARIA SANCHEZ ALBIÑANA, IN MY CAPACITY AS INTENDANT – HEAD OF THE LOCAL POLICE FORCE OF THE MOST EXCELLENT TOLEDO CITY COUNCIL DO HEREBY STATE AS FOLLOWS: That the company DORNIER, S.A. is the concessionaire of the Management of the Service Regulating the Parking of Vehicles on the Public Highway, and the Service for the Immobilization, Towing, Transport, and Deposit of vehicles on the public highway and their subsequent custody at the TOLEDO vehicle pound, in the form of an Administrative Concession with the following characteristics: Date of execution of contract: 7 April 2005 Term of concession: 10 years With the possibility of extensions: 2 years Number of space regulated as at today’s date: 8,262 Number of ticket machines installed: 245 Stelio model Tow trucks: 2 Nissan Trade and 1 Iveco 50 C13 Hitherto the service has been provided in compliance at all times with the schedules of conditions in force and the offer presented and to the full satisfaction of this Authority. In witness whereof, at the request of the concessionaire, these presents are signed at:
Toledo, 24 March 2006
[illegible signature] [illegible rubber stamp]
[on the headed notepaper of the Zaragoza City Council – Public Services Area]
File no. Ref. 25/06 I, MR. ANTONIO RAMOS MARTOS, Civil Engineer, College No. 3453, and Head of the City Mobility Service (Public Services Area) of the Most Excellent Zaragoza City Council DO HEREBY CERTIFY:
- That the company Dornier, S.A. has been awarded the concession for the provision of the Service for the Regulation of Parking on the Public Highway in the City of Zaragoza, as from 30 October 1992, and expiring in June 2008.
- That it commenced provision of the Service on 10 February 1993. - That it has currently installed 327 ticket machines, model DG-4, to regulate
6,777 parking spaces, equipped with magnetic-card readers, and we consider the functioning thereof to be satisfactory.
- That the staff of the said company co-operates in very positive manner with
the various departments of this Council, and in particular with the City Mobility Service in technical management, and with the Local Police Force in the performance of their duties on the public highway.
The City of Zaragoza, 18 May 2006 THE ENGINEER HEAD OF
THE CITY MOBILITY SERVICE
[illegible signature]
[rubber stamp of the Zaragoza City Council – City Mobility Service]
[on the headed notepaper of the Vitoria-Gasteiz City Council]
I, Mr. Juan Ignacio SAGARDOY BRIONES, as Head of the Mobility and Transport Service of the Vitoria-Gasteiz City Council, which is the licensor for the Installation, start-up, maintenance, and technical assistance for the functioning of O.T.A. ticket machines DO HEREBY CERTIFY: That the company DORNIER, S. A. contractor for the said services in Vitoria-Gasteiz since 14 January 1999 and up to 31 December 2005, in accordance with a number of consecutive contracts and with a total number of regulated spaces of 4500. The services have consisted in: - Verifying and ensuring the proper functioning of the ticket machines with a
centralized alarm transmitter via GSM, including their preventive, corrective maintenance and proceeds. Monthly statistics. Occupation, rotation, average stay, weekly vehicle survey, collection and service of penalty notices cancelled per week.
In witness whereof, I issue this certificate in Vitoria, on the third day of November two thousand and five.
[illegible flourish] Iñaki Sagardoy Briones
Head of the Mobility and Transport Service
[on the headed notepaper of the Valladolid City Council – Safety and Highways Area – City Mobility Committee]
Reference: Entry: Date: 26 March 2002 I, MR. ROBERTO RIOL MARTINEZ, Head of the City Mobility Committee of the Valladolid City Council, as Licensor of the “CONTRACT FOR THE MANAGEMENT OF THE PUBLIC SERVICE FOR THE REGULATION OF VEHICLE PARKING ON THE PUBLIC HIGHWAY IN THE CITY OF VALLADOLID, BY WAY OF AN ADMINISTRATIVE CONCESSION”, awarded to the company DORNIER, S.A., and formalized on 26 December 2001, with commencement of the service on 1 January 2002, DO HEREBY REPORT: 1. That in accordance with the information contained in the file, the company
DORNIER, S.A. is the concessionaire of the O.R.A. service in Valladolid. The term of the concession has been set at ten years, with the possibility of two one-year extensions.
2. The total number of spaces to be managed, in accordance with the information
contained in the project, is 6,446, with 846 being in City Discouragement Car Parks, and 5,600 in the traditional blue zone with a maximum permitted stay of 2 hours.
3. The make and model of the ticket machines on offer is SCHLUMBERGER Stelio.
The number to be installed in accordance with the offer presented by the company is 239.
4. The free improvements offered by the concessionaire include a tow truck, the make
and model of which is Iveco 50C15, including the staff necessary for the use of the said vehicle within the scope of application and the times of operation of the O.R.A.
5. The concessionaire is the same as for the previous contract, the term of which was
from 6 November 1989 to 31 December 2001, managing a total of 3,715 parking spaces with 170 ticket machines installed on the public highway. The service was provided at the full satisfaction of the municipal technicians in charge of its supervision.
In witness whereof and for all pertinent effects, I hereby sign these presents at Valladolid on the twenty-sixth day of March two thousand and two.
THE HEAD OF THE CITY MOBILITY COMMITTEE
[illegible signature] Roberto Riol Martinez
[rubber stamp of the Valladolid City Council – City Mobility Committee]
AJUNTAMENT DE VALENCIA
I, PEDRO GARCIA RABASA, LOCAL ADMINISTRATION SECRETARY, HIGHER CATEGORY, DEPUTY SECRETARY OF THE VALENCIA CITY COUNCIL DO HEREBY CERTIFY: That in file no. 01801/2007/519, of the Traffic and Transport and Infrastructures Service, opened at the request of the company DORNIER, S.A., there exists a report by the Head of the Traffic Regulation Section which states as follows:
‘That the company DORNIER, S.A., concessionaire of the “CONTRACT FOR THE MANAGEMENT OF THE PUBLIC SERVICE FOR THE CONTROL OF VEHICLE PARKING ON THE PUBLIC HIGHWAY BY WAY OF TIME CONTROL, HORIZONTAL AND VERTICAL SIGNAGE, THE PROGRAMMING OF THE ITEMS THAT MAKE UP THE SAID SERVICE, THE STEPS FOR COLLECTING THE FEE, AS WELL AS CO-OPERATION IN THE MANAGEMENT OF THE PENALTY NOTICES ISSUED FOR INFRINGEMENTS, AND THE MANAGEMENT OF COLLECTION FOR CANCELLATION OF THE SAID PENALTY NOTICES”, with the following characteristics: - Date of commencement of the service or execution of the contract: The
commencement of the activity occurred on 30 May 2006. The contract was executed on 22 May 2006.
- Term of the concession: It is for 5 years starting from the signing of the Minutes for the Commencement of the Activity.
- With the possibility of two extensions of one year each one. - Annual contract price: €2,865,000.00 - Number of spaces regulated as at the date of the last annex to the
Reformulation Minutes of 1 September 2006:
PAY SPACES 4,551 LOADING BAYS 365 DISABLED SPACES 169 FREE SPACES 2,012 TOTAL SPACES 7,097 MOTORCYCLE SPACES 768
- Number of ticket machines installed: 293 Stelio ticket machines, new,
autonomous, equipped with Magic500 microchip-card readers including banking licences.
- That the population of Valencia currently has a population of 807,396 inhabitants.
In witness whereof, and for the purpose of the Classification of Service companies, I hereby issue these presents with the counter-signature of the Lady Mayoress in Valencia, on 30 March 2007. countersigned THE MAYORESS [illegible signature] [illegible signature]
Appendix6 - Safety and Security
Summary:
Application of Equipment and Materials in On-Street Parking Facilities
Knowledge of Parking and Public Safety and Security Techniques and Methodologies
Experience in Emergency Response Support
Expertise in relevant On-Street Parking Engineering Standards, Specifications, Policies and Practices
1
APPLICATION OF EQUIPMENT AND MATERIALS IN ON-STREET
PARKING FACILITIES.
Cintra Parking/Dornier is committed to install first quality equipment in its service facilities
to ensure high standard operations and offer its users high quality and reliability in the
services provided. This also enables us to offer our users the latest technical innovations
available in this business in Europe and Worldwide.
On-Street Parking Service Equipments are all leading European and international brands,
and feature the latest hardware and software upgrades. Our on-street parking facility
operations are therefore highly efficient and reliable, failure rates are extremely low and
the advanced features available allow our users to tailor our services according to their
needs.
Cintra Parking/Dornier works closely with technology development and maintains
updated efficiently undertaking innovative technology and other improvements of the
Market. Moreover, on the technological structure side, our IT Department works for the
development of new products and features, upgrading existing ones, or including new
ones that might contribute to improve our operations and offer our users a better service.
All these equipments are acquired through our team of engineers in our Maintenance
and On-Street Parking Equipment Department, who are responsible for elaborating the
technical bidding specifications and invite all the above suppliers to submit their best
technical and financial solutions, every time a purchase process is initiated. Once the
offers have been received, Cintra Parking/Dornier analyzes the technical and economic
aspects, post-sale services and corporate background of all tenders submitted and
awards the bid to the nominated supplier.
2
KNOWLEDGE OF PARKING AND PUBLIC SAFETY AND SECURITY
TECHNIQUES AND METHODOLOGIES.
Two of Cintra Parking/Dornier major concerns, as an operator of a high number of
facilities with a large number of users and vehicles, are Safety and Security. The
company is fully concerned with this and consequently has developed and
implemented policies, procedures and plans to guarantee the maximum achievement
and performance in these fields.
Safety Delivery
As mentioned before Cintra Parking/Dornier, by means of the ISO:9001 Quality
Management System and ISO:14001 Environmental Management System, has
implemented procedures to be updated to the newest regulations in Environment,
Health and Safety, applicable to facilities under design and construction, and also in on-
street car park facilities operation.
Cintra Parking/Dornier is fully committed to the responsibilities entailed by the
ENVIRONMENT, HEALTH & SAFETY at all our installations and in all operations of the
company, which enables us to eliminate risks by evaluating any accident or incident
that could cause damages to our Employees, to Company property and to the
Environment. In line with this, the company has an EH&S Policy and Plan widely
implemented at all levels and working sites. The Risk Prevention System is based on the
EH&S Policy, approved by the Management Board and certificated by AENOR. The main
guidelines of this policy are:
• The creation and establishment of a Risk Prevention corporate culture
• The development of the best Preventive Practices to minimize labor risks and favor
the continuous improvement in the Risk Prevention Activity
• Education & Training. All these goals are achieved mainly thanks to an Education &
Training Plan implemented across the Company and especially among the site
3
personnel of the On-Street Car Parks. The E&T Plan tackles matters such as first aid
training, first response to an accident, etc.)
• The compromise and involvement of all staff in the design, implementation and
control of the established processes, procedures and norms.
This policy is necessarily observed by all employees and in all Cintra Parking/Dornier
installations and will be notified to all members of our workforce, including those who
may be subcontracted. The EH&S are given the same importance and efforts as all other
operations in our business areas. Accordingly, when decisions are adopted by the
different departments, the EH&S program will be born in mind before making any
acquisition or developing any product, thinking always of the continued improvement of
EH&S and without ceasing to be competitive.
At the present time, we are achieving positive results after our EH&S System
Implementation, which are clearly reflected in the low labor accident rates obtained in
the past few years. However, the Company has contracted an accident insurance
policy in order to meet indemnities that may become payable to service workers due to
an accident, in the event of permanent disability and according to any national and
local regulations.
Appendix 2 includes Cintra Parking / Dornier’s EH&S Policy.
Security Delivery
When developing a new site, a case by case study is carried out and first quality
equipment is provided for the Secure On-Street Car Park Service operation.
We study the demand profile of every new project to assess the number of employees to
be assigned and the different schedules to comply with the operating and surveillance
shifts.
One of the key processes is that we have pioneered the development of new
technologies and systems for massive usage rates service operations, communication
and location, in which safety and security are number one constraint and objective.
4
Finally, in the event of accident or crime detection a protocol is activated in order to call
for Police or Emergency Services, and also notify to the Company to assure the safety
and the security of our service workers.
5
EXPERIENCE IN EMERGENCY RESPONSE SUPPORT
Internal Procedures
The growth in of our Team’s volume of activity and size, combined with its progressive
diversification, increases the opportunities for risk and situations capable of triggering a
crisis of significant consequences.
During the moments immediately following a crisis, adequate communication within and
outside our organization becomes crucial. We have therefore considered necessary to
establish a formal procedure for the notification of such situations, to prevent the
adverse consequences of information that is unreliable, untimely or released by the
wrong person.
The Procedure for Internal Communication during Crises has been formally approved
and applied throughout Cintra Parking/Dornier. This Procedure attempts to empower the
organization with a tool that, in the event of a crisis, will ensure that the different
management levels will have access to reliable information in the shortest span of time
possible.
It covers the following aspects:
1. Basic guidelines for action
2. Internal communication of the critic situation
3. Communication mechanisms
4. Catalogues on crisis situations
5. Procedures for taking action during emergency situations
Contingency Plans / Emergency Plans
Cintra Parking/Dornier is well aware of the fact that potential abnormalities and situations
that might develop on street service are many and varied, and endorsed by its
experience over the years in this business, it analyzes all possible emergency situations
that could develop at each concession in terms of the type of services offered, the
actions to be taken and how they should be solved.
6
This analysis is then summarized in a Contingency Plan or Emergency Plan that includes
the technical fundaments for the following goals:
• To be acquainted with the service facilities, their installations and possible effects
consequences
• To guarantee the reliability of all equipment and installations in the service and
ensure their correct serviceability levels at all times.
• To avoid all potential sources for emergency situations
• To have organized, trained staff capable of ensuring speed and efficiency in the
performance of both routine procedures and actions to be taken for emergency
control.
• To keep all users and workers informed of how to act in the event of an
emergency and under normal conditions to prevent emergencies from
occurring.
This plan envisages the different emergency hypotheses, further to defining the order of
actions to be taken for an early control of emergencies, indicates who, how and when
they will be taken, and plans for people organization with the possible resources. It is
important to point out that Contingency Plans are live documents that should be
updated throughout the time a contract is in force.
The typical contents of a Contingency Plan or Emergency Plan are the following:
• Staff qualifications
• Contingency Classification
− Incidents with clients
− Equipment and installation failures
− Security related issues
− Environment related issues
− Staff issues
− Possible client fraud
− Miscellaneous incidents
• Guidelines to follow in the event of certain contingencies
• Incidents with clients
7
− Treatment by a client
− A client claims he has lost his ticket
• Equipment and installation failures
− Ticket dispenser failure
− Inconveniences with payment
− Not enough change at a ticket dispenser
− Failure in management and collection software system
− Failure in database management software
− Power outage
− Failure in any other installation
• Security related issues
− Vehicle collides with a ticket dispenser or into another vehicle, with no serious
consequences, impending risk of explosion or casualties
− Vehicle runs over a user– no casualties
− Focused fire, small in degree and easily fought with an extinguisher
− Serious or multiple vehicle collision with critically injured victims
− Presence of a driver or user whose behavior threat the physical integrity of
users
− Fire, with impending risk of explosion
− Threat of explosive devices
− Artifact explosion
− Notification of an individual on the facilities with a suspicious behavior
• Staff issues
− Service staff on strike
• Possible client fraud
− Clients who do not pay
• Miscellaneous incidents
− Presence of a vehicle parked inadequately
Training
Cintra Parking/Dornier, by means of the EH&S Management System, makes an important
effort in training courses to all employees for emergency response. The annual plan sets
and budgets the training course Schedule.
8
Continuous improvements are made in this field, with many different Training Courses
about First Aid, Risk Prevention, Accident Investigation and Coordination, Self Protection
Manual, and Customer Service Course.
9
10
EXPERTISE IN RELEVANT ON-STREET PARKING ENGINEERING
STANDARDS, SPECIFICATIONS, POLICIES AND PRACTICES
Cintra Parking/Dornier has an Engineering Project Department with senior staff and large
experience in the design and construction management of on-street parking facilities.
This Department conducts on-street parking feasibility studies, blue print projects and
construction projects, construction quotations and improvement and refurbishing
projects. This Department’s work lasts throughout the life of each concession (starting
from the initial assessments, outline designs for the new service facilities, execution
projects, management of the project during the operation and during repairs and
refurbishment works).
All design and construction tasks at Cintra Parking / Dornier comply with the
International ISO:9001 and ISO:14001 Standards, and are supported by operating
procedures defining the steps to follow throughout each and every phase (identification
of initial requirements for the designing, planning, control, operation, review and
verification).
A truly important effort is made from this Department to keep updated the database on
standards, manuals, recommendations, specifications, and requirements to design and
operate on-street parking facilities. For every new project, technical specifications are
defined and all applicable standards are identified.
Cintra Parking/Dornier also has its own designing requirements that have proven to be
efficient throughout our years of experience pursuing enhanced comfort for our users. At
all service facilities and equipments designed by Cintra Parking/Dornier, regardless of
them being new constructions or the refurbishing of existing facilities, it is mandatory to
consider all corporate requirements as well as standards applicable by federal,
municipal and regional agencies, especially in terms of Environment, Health and Safety.
Appendix 7 – Bios-Profile description of Key Personnel
Leopoldo del Pino
Javier Mateos
Carlos Ugarte
Jorge Gil
Pedro Losada
Gabriel Gutierrez
Nicolas Corral
Leopoldo del Pino General Manager – Cintra Aparcamientos, S.A. (Cintra Parking) In 1998 Mr. Del Pino joined Cintra Aparcamientos as Regional Manager of Madrid. Since May 1999, when he was promoted to General Manager of Cintra Aparcamientos, Mr. Del Pino has been responsible for the management and development of the car park business of Cintra. The continuous success of Cintra Aparcamientos during this period of time has significantly increased the number of parking spaces operated by the Company (243.000 parking spaces in May 2006 vs. 113.000 parking spaces in May 1999), being today Cintra Aparcamientos by far the biggest company in Spain in the car park sector in terms of number of spaces. Mr. Del Pino is also CEO of Aparcaments Escaldes Centre (Andorra), Vice-Chairman of EULSA (the On-street Car Park Company of the City of León, Spain) and member of the Board of SMASSA (the Car Park Company of the city of Málaga, Spain) and AUSOL (concessionary company of the 105 kms. long highway between the cities of Málaga and Guadiaro, Spain) He has been CEO of ESLI (Portuguese car park company), President of ANERE (Spanish National On-street Companies Association) and Vice-President of AEGA (Spanish Car Park Companies Association), as well as member of the board of the car park companies EGUISA and AUSSA, both in Spain. Mr. Del Pino began his professional career working on site in different highway and railway projects and, prior to entering the car park business, worked for a while for the Public Administration, being appointed in 1996 (when he was 33 years old) Director General of Industry, Energy and Mining of the Province of Madrid, General Manager of ITV S.A. and Member of the Board of the public companies Avalmadrid, Gedesma y Cetema. Leopoldo del Pino holds a Master Science Degree in Civil Engineering by the Polytechnic University of Madrid and a Master in Business Administration by INSEAD (the European Institute of Business Administration, France). He is married and father of one son.
Javier Mateos
Chief Operating Officer – Cintra Aparcamientos, S.A. (Cintra Parking) Mr. Mateos has over twenty three years of experience in the car park business. He has been Chief Operating Officer in Cintra Aparcamientos from 1988, and has a broad experience, national and international, in the design, start-up and operation of all kind of car parks, developed either for public or private clients. He has acted as lecturer in many symposiums and seminars in the sector, such as Parkópolis (Paris,Reims, Nice,), Intertraffic (Amsterdam), TEM (Madrid), International Car Park Symposium, Spain, Master Program for Urban Mobility of Polytechnic University of Madrid, etc. He has actively promoted the creation of the Spanish Association of Parking Operators in which he has acted as president and currently is vice-president. From 1983 to 1988, he was General Manager of Aparcamientos Concertados S.A (Car Parks Division of FCC Group). From 1979 to 1983, he was head of the geotextiles division of Uralita. From 1974 to 1978, he acted as engineer in the hydrology division of Bilbao-Zaragoza Highway. Mr. Mateos holds a Degree in Civil Engineering, from Polytechnic University of Madrid.
Carlos R. Ugarte
Department Head for US Business development – Cintra Mr. Ugarte has over 19 years of financing and managerial experience, in Chile and abroad. Since May 2006 Mr Ugarte is the Department Head for US Business development for Cintra prior from 1998 to March 2006, Mr. Ugarte was the CFO of Cintra Chile, a leading infrastructure concessions holding in Chile with investments over USD 1.5 billion. He has been responsible for the finance and administration of Cintra Chile and its subsidiaries; also he has been responsible for the design and implementation of the business model adopted by Cintra Spain to administrate its 5 concessions in Chile. While working in Cintra he has design, led and implemented the start-up Operational Holding Structure and the final business model implemented at the beginning of 2004, by which Cintra Chile operates and manages on a consolidated way, its investments in concessions in Chile. Also Mr. Ugarte has led several financial operations, including complex project financing transactions, some of which are cornerstone solutions for Project Finance Industry world wide, among these is Autopista del Maipo Project Finance (USD 421 million, UF 6 million and a Cross Currency Swap for USD 700 million) that has been awarded two international prices (Latin American Refinancing Deal of 2004 from Project Finance Magazine and Best Project Finance Deal of 2004 from Latin Finance Magazine). From 1986 to 1989, Mr. Ugarte worked for the Ministry of Finance of Chile, where he was part of the team that led most of the economic reforms that are the base of today’s Chilean economic success. From 1992 to 1994, Mr. Ugarte worked at Credit Lyonnais Securities New York, being responsible for the structuring of debt (144A bonds) and equity transactions (ADRs) for Latin American companies. Before joining Cintra in 1998, Mr. Ugarte was CFO at Soquimich Nitratos S.A., a world leader of specialty chemical and fertilizers at which Mr. Ugarte manage more than 30 subsidiaries around the world with more than 200 people reporting to him. Mr. Ugarte holds a degree in Economics from Universidad de Chile, a Master in Business Administration and a Master in Science and Business Administration with concentration in finance, both from University of Southern California, Los Angeles.
Jorge Gil
Corporate Development Director - Cintra Mr. Gil He joined Cintra in 2001 as a Project Manager in the Project Finance Department of Cintra, and was responsible for the financing of toll roads and airports. He carried out the financial analysis during the bidding process and designed and negotiated a customized financial structure in each project. In 2002 he became Project Finance and Treasury Director of Cintra and Ferrovial Infraestructuras. He is responsible for the financing of toll roads, airports and car parks. He is involved in the transaction and also supervises a team of project finance managers that finance acquisitions and refinance the existing portfolio. His responsibilities also include managing treasury operations of Cintra In Spain, and those of the portfolio projects in USA, Canada, Chile, Ireland and Portugal. He has led the following transactions: Indiana Toll Road Acquisition in 2006 (3.8 USD blln.), the Chicago Skyway Concession Refinancing, wrapped bond – deal of the year 2005- (1.5 USD blln), the Bristol Airport (UK) Syndicated loan in 2005 (GBP 0.5 Blln.), the Chicago Skyway Concession – deal of the year 2004 – (1.2 USD blln), the Texas TTC 35 in 2004, the syndicated loan for Ocaña la Roda Toll Road - Spain in 2004 (0,5 EUR blln), the Maipo Toll Road wrapped bond (Chile) – deal of the year 2004 – (UF 8 Mlln), the Autopista Madrid Sur – Radial 4 - Spain in 2003 (0,5 EUR blln), the Belfast Airport (UK) syndicated loan in 2003 (GBP 37.7 Mlln), the N4-N6 Toll Road (Ireland) financing – dela of the year 2003 – (EUR 0.3 Blln), the Norte Litoral Shadow Toll Road (Portugal) syndicated loan in 2002 (0,3 EUR Blln), the Sydney Airport (Australia) syndicated bond in 2002 (AU$ 4 Blln.), the Santiago – Talca Toll Road, (Chile) $USA bond issuance wrapped by MBIA – deal of the year 2001 – (USD 0.4 Blln), the Algarve Shadow Toll Road (Portugal ) EIB wrapped bond in 2001 (EUR 0.3 Blln), the Bristol Airport (UK) syndicated loan in 2001 (GBP 0,1 Blln.), and other. Currently, in the Investor Relations area, he supervised a team of three people with responsibility on the relationship with the stock exchange analysts and the investors in the shares of Cintra, on the follow up of the performance of the stock vis a vis the market and its key competitors, and on the preparation of the annual report and of the General Shareholders Meetings of the Company. Cintra is part of the IBEX 35 index, comprising the 35 largest Spanish stocks. From 1997 to 2001 Mr. Gil worked at The Chase Manhattan Bank in different areas, including M&A and Corporate Finance, Credit Risk, and auditing. Mr. Gil holds a degree in Law and Business Studies from the Universidad Pontificia de Comillas – ICADE in Madrid, Spain.
Pedro A. Losada Project Finance and Treasury Director – Cintra Mr. Losada joined the Treasury and Project Finance Department of Cintra in 1998. He has been actively involved in the treasury management of Ferrovial Infraestructuras, Cintra and their subsidiaries, including their international operations. In particular, his work involves the financial assessment of the projects during the bidding phase, as well as the design of the most profitable financing structure. He also participates in the negotiation of the financial terms of a transaction prior to reaching the financial close. He has been directly involved in managing the financial bidding team in more than 12 deals completed worldwide. Specifically, he was co-leader of the issuer’s team for the financing process of the Chicago Skyway (USA) and of the acquisition of the Indiana Toll Road (USA). In addition, he has designed the financial structure, of more than 10 projects per year, including highways, car parks and airports. It is worthwhile mentioning his participation in projects such as the Indiana Toll Road Acquisition in 2006 (3.8 USD blln.), the Chicago Skyway Concession Refinancing – deal of the year 2005- (1.5 USD blln), the Chicago Skyway Concession – deal of the year 2004 – (1.2 USD blln), the Texas TTC 35 in 2004, the syndicated loan for Ocaña la Roda Toll Road - Spain in 2004 (0,5 EUR blln), the Madrid South Toll Road – Radial 4 - Spain in 2003 (0,5 EUR blln), the Belfast Airport (UK) syndicated loan in 2003 (GBP 37.7 Mlln), the Norte Litoral Shadow Toll Road (Portugal) syndicated loan in 2002 (0,3 EUR Blln), the Santiago – Talca Toll Road, (Chile) $USA bond issuance wrapped by MBIA – deal of the year 2001 – (USD 0.4 Blln), the Algarve Shadow Toll Road (Portugal ) EIB wrapped bond in 2001 (EUR 0.3 Blln), and the Cintra, S.A. syndicated loan in 2000 (EUR 0.3 Blln). After his successful track record in the Chicago office he was recently appointed head of the Project Finance department Mr. Losada holds a degree in Economics from the Universidad Complutense (Madrid, Spain) and a Master in Portfolio Management from the Options and Futures Institute (Madrid, Spain).
Gabriel Gutierrez
Project Manager, Corporate Development – Cintra Mr. Gutierrez joined Cintra in January 2006, as a Project Manager of the Corporate Development Division. His responsibilities include the management of projects related to strategic transactions such as the acquisition of portfolios or assets in the infrastructure sector, or bidding for concessions in public processes. Previously, he had worked for 5 years in a Private Equity firm, Marco Polo Investments, where he had been a member of the founding team. He was involved in all aspects of the transactions “from cradle to grave”. He took part in the origination of transactions, both in public processes managed by financial and legal advisors, and in proprietary self originated projects. He was fully responsible for the financial, commercial and technical due diligence of the potential investments, and managed third parties involved in the transaction. Furthermore, he structured the deals, and negotiated all aspects of the deal with the owners of the potential investments, the management, and other relevant stakeholders. He was not only involved with the specific transactions, but with the overall management of the deal flow, and assisted in the reporting and management of the portfolio. He reported to the Principal of Investments. He also was involved in the exit of the portfolio, and managed the business and financial aspects of the sale of the first major investment of the Private Equity company. The asset was sold for three times its investment value after a period of 4 years. From 1995 to 1998 he worked for PricewaterhouseCoopers as an auditor of Financial Institutions and Technology and Media companies. In addition to the audit work, he also participated in consulting projects, such as a best-practices project for a chemical multinational, as well as in due diligence processes including a financial institution and a commercial company. Mr. Gutierrez holds a degree of Business Administration from the University of Warwick, United Kingdom, and an MBA form Georgetown University.
Nicolás Corral Business Development Director, Cintra Parking/Dornier Aparcamientos Currently Cintra's Director for International Markets Development, Nicolas has an engineering and financial background, earned through ten years of professional experience in the Infrastructure development sector. Graduated at University of Cantabria (Spain) in 1998 as Ms. Sc. in Civil Engineering,he started working as a construction site manager for one of the spanish biggest contractors in Spain: FCC Construccion. He continued his education earning a Master in Business Administration ("MBA") from one of the world's top ranked business schools: IE Business School in Madrid,Spain. After that,he joined Cintra in 2002,and since then has worked in a large number of Infrastructure deals all over the world, with a special focus on the US. He has analyzed and worked in the US market since the "PPP boom" in 2004 (including the start-up of Cintra's US head office in Austin,TX, and the Indiana Toll Road deal in 2006). He also brings an extensive experience in the Car Park industry, having been Cintra Aparcamiento's Business Development Director during the relaunching of it's expansion in 2007. Nicolas is currently in charge of Cintra Aparcamiento's international expansion,as well as of the overall strategy of Cintra S.A. towards Latin America &Asia-Pacific.
Appendix 8 – WINID
Summary
Introduction
General Operation
Preparing the Application
Working with the Application
1
INTRODUCTION
WINID is an application for processing fines.
WINID performs several operations on the fines reported. First, it receives them from the
terminals used by controllers to record the data of each report to the exporting of the
accusations or a file for the subsequence treatment of them with another application.
During the time between receiving the reported fines and exporting them, the
application also takes charge of processing them and processing all the data
associated with the reports. These data may be the registration plates of the vehicles
reported, the make of that vehicle, the coour, the street where the report was made, the
province, the country of the vehicle, etc. These values can be calculated in the
controllers’ terminales through WINID.
WINID also performs maintenance work on the application database, such as making
backup copies.
The application also allows reports to be drawn up for helping to optimise operations.
The basic solution provided by the application is described below.
The WINID application is based on the Windows standard. This section gives a general
explanation of the application interface with the intention of giving users an idea of the
environment used for operating it.
MENUS
The application has several menus, divided into topics. These menus are Operations,
Functions, Utilities, Maintenance, Reports and Parameterisation. There is also a menu
entitled About... that is merely informative.
Operations. These are the operations that can be performed in the
window in which the user is located. Initially, only the exit option is
2
enabled. When a window is opened, the authorised operations are
enabled, depending on the profile of the user making the connection. In
addition, the operations may vary, depending on the action performed in
the active window.
3
Functions. These are the windows most often used to operate the application.
Utilities. They form part of the everyday routine, but are not used as frequently.
Maintenance. Windows that perform the maintenance work of the entities.
4
Reporting This window contains the application reports.
Parameterisation. The fuctions that parameterise the system operation.
5
The main window of the application also has buttons for fast access to the main
functions and operations.
WINDOWS
Each of the options in the menu Functions, Utilities, Maintenance, Reports and
Parameterisation in this application will open up a different window. These windows are
comprised basically of flaps. To make it easier to under this, we will start by explaining
what a flap is.
FLAPS
Basically, the flaps are a method of dividing up the information shown in the windows of
the WINID application. There are three types: Criteria, Results and Previewing.
Criteria Flap
The criteria flap is the one where the screening values are entered, which must then
comply with the results shown in the window.
6
Results Flap
After entering the desired values in the criteria flap, to pass on to the results flap users
must click on that flap or do the same with the button Accept (Yellow smiling face).
The results flap shows the data complying with the values entered in the criteria window.
The data in this flap are usually shown in three modes.
The first mode shows the information in the form of a table with many lines, as shown in
the image.
7
Another results flap mode is the single mode, which shows the information in two different
bodies, as shown in the image.
8
One aspect that must not be forgotten is that, depending on the flap in which the user is,
a specific series of authorisations will be enabled in the menu. It should also be
remembered that these options also depend mainly on the authorisations assigned to
the specific user profile.
Authorisations enabled in
the results flap.
Authorisations enabled in the
criteria flap.
9
Printing and exporting show a window in which users must select the information they
want to export or print, with the option of selecting the current row, all the rows or
selected rows.
Importing will show a window in which the route and name of the file from where the
data will be imported are selected. The importing of text files separated by tabulators
(*.txt) or Dbase II and III (*.dbf) files is permitted.
The last type of results flap is the multiple one. This type of flap is basically the
same as the single results flap, but with the peculiarity that instead of having two parts, it
has three. The third body of the flap is comprised of data associated to the row that is
being viewed. This type of window offers the option of performing the same operations
as those in the single results flap.
10
Data associated with the
selected row.
Previewing Flap
The last flap remaining to be described is the previewing flap. The only thing this flap does is show the data it has in results, as they will be printed out by the printer in the event of printing them. This flap does not show the data as fixed, since the changes made to the results will also
be made in this flap.
11
Having explained what a flap is, and the types of flaps in the application, we will now
return to describing the windows.
The windows of the application can be divided, depending on the flaps that they
display.
Windows that only have the results flap.
These are windows which, given the volume of data they handle, do not require search
criteria to work comfortably with the data. These windows do not show the criteria and
previewing flaps. When opened, the results flaps can be viewed directly, with all the
data maintained in that window. The windows do not lose any of the options explained
above and data multiselection, ordering, printing and other operations can all be
carried out. Examples of this type of window are the colours and countries maintenance
windows.
Window with
only the
results flap.
12
Windows with criteria and results flaps.
These are windows whose volume of data requires a criteria-based search to be
made in order for the user to work correctly and easily. If this is not considered
necessary, users may decide not to enter the search criteria and go straight to the results
flap, where in this case, all the possible data appear. The operation is the same as for a
window with all three flaps. I.e., the window shown with the criteria flap selected. After
entering the criteria they can be changed to the results flap where the operations
already commented on can be performed, in other words: modification, insertion,
erasing, multiselection, printing and exporting of data. It must be remembered that the
possibility of performing these operations depends mainly on the authorisations of the
user with respect to the application. Some examples of this type of window are the
Makes and Registrations maintenance windows.
13
Windows with the criteria, results y previewing flaps.
This type of window is only present in the reports. The peculiarity of these windows is that,
as already mentioned, the results flap does not allow the data it shows to be modified,
and in addition these are shown in the form of a table.
Examples of this type of window are all kinds of reports.
14
ACCESSING THE APPLICATION
On starting up the application a window will appear where users should enter their login
and password. The system checks whether that user can access the application and
what authorisations he/she has, and enables the active menu options for that user
profile.
The login and password are entered, and then the accept button is pressed.
15
PREPARING THE APPLICATION.
This section described the steps necessary for configuring WINID to suit your needs. The
application has a a series of general predefined values for operation, but it must be
configured with the most appropriate values for your system. In addition, the necessary
data must be entered in your database, to correctly process the the fines reported that
are received in the terminals.
To execute the operations we have commented on above, the Parameterisation and
Maintenance menus hould be used, the options of which we shall now describe.
PARAMETERISATION
Upgrades
This window enables you to select a text file continain a first identification line, and the
rest of the contents are SQL rulings separated by a dot and comma. This will serve to
make upgrades of large quantities of values in your database quickly and easily.
As can be seen, this window has no flaps, as it is a window that does not display the
application data.
16
Fine Reports File
This window takes charge of parameterising the file format to which the reports will be
exported through the Reports Export function. In other words, the Reports File format that
will later be exported can be designed in it, so that it can leave it inthe most useful mode
known for subsequent processing with that file.
Erase detail. Enter detail.
Enter and
erase by
pressing the
RIGHT HAND
button
System parameters
This window is the configuration window of the application. Here, for example, users can
configure the route where the files are that the application must use for operating with
the terminals, the period of time for making backup copes in the database, the route
where the errors file is located in which errors occurring in upgrades will be stored, etc.
17
User Profiles
Maintenance of the user profiles. A user profile is a set of authorisations for using the
application. I.e., when creating a user profile, it defines what the users with that profile
can do in WINID.
18
Types of Terminal
Maintenance of the available types of terminals. This window is responsible for controlling
all the types of terminals that will be connected to the application, in order to transfer
the fines imposed with them and also those with which the application will be
connected for updating the data stored in them.
Users
Maintenance of users who can access WINID. The users are associated to profiles based
on which their authorised functions are defined as well as the operations they can
perform as part of those functions.
MAINTENANCE
Fines Reports Articles
Storing of fines articles sent to the terminal. Here users can define, modify and erase the
types of fines available in the terminals for executing the reports.
Streets
Maintenance of the streets that the terminals will have available, i.e., the different street
the terminals can use to associated the fines imposed.
Colors
Maintenance of the different colours in the database which are sent to the terminals.
This window has no search criteria flap.
19
Agents
Maintenance of controllers (and agents and inspectors, depending on the system
configuration) using the terminals. Here the controller data (and data of the agent or
inspector, depending on the system configuration) used by a specific terminal can be
defined. These data are the name, date of incorporation as a controller and an
identification code.
Makes
Maintenance of the makes of vehicle in the database that are sent to the terminals for
use when defining the fines data imposed on the vehicles. This maintenance has no
criteria flap.
Registrations
Maintenance of vehicle registrations in the database.
The registration format is determined by the type of associated registration it has. When
modifying or inserting a registration, the system will make a series of validations,
depending on the type of registration.
Terminals
Maintenance of the terminals with which the application operates. Here the terminal
characteristics can be defined and the controller to whom it is assigned, the time at
which that terminal is operating, the zone in which it is operating, etc.
20
WORKING WITH THE APPLICATION.
In this section the most usual operations performed with the application are shown. To
make a clearer distinction we shall divide them up into three parts: Functions, Reports
and Utilities.
FUNCTIONS
These are the most common operations in routine work. In explaining them, we will follow
a logical order which will be the most common one in executing routine operations.
Synchronisation
This function is used to synchronise the terminals. Synchronising a terminal is divided up
into two clearly different parts: sending and receiving. The sending part is done from the
application to the terminal and through it, the data corresponding to the coloured files,
streets, makes, etc. can be sent to the terminal. This is a method of updating the
information used by the terminal to perform its operations on the fines. The receiving part
refers only to the fines, and if applicable, (depending on the system configuration) the
photos associated with each fine. In other words, the fines and the photos associated
with them which the controller has taken with the terminal are transferred to WINID for
processing and storing in its database.
If the terminal data are modified, it is necessary to send the new configuration to the
terminal and no deviations are allowed.
Once the synchronisation operation has been executed, a screen is shown with the tasks
executed, together with an icon informing the user whether the task was correctly
performed or not.
21
Task performed
correctly.
Task not performed
correctly.
After completing the Synchronisation and showing the tasks executed with their
respective execution information icon, the user presses the button (accept) that is shown
after the tasks. Depending on the number of tasks performed, this button may or may not
be visible, for which reason if it is not visible, it must be moved downwards with the shift
bar in order to be pressed.
Integration of the Fines Reports
The aim of the Fines Reports Integration process is to enter the fines coming from the
terminals and entering WINID. The fine reports received from the terminals are established
as pre-reports, i.e., they are not yet fines reports inside the WINID database. This
maintenance process takes charge of changing the report from a pre-fines report to a
fine report for storing in the application. To perform this task, all the pre-fines report data
are validated.
Fines reports
Maintenance of fines reports that have been integrated into the system and have not
yet been exported.
22
Mass cancellations and declarations operations can be performed on the fines reports
through the multiselection option and by pressing on the declarations or cancellations
options. In the case of cancellations, the application will ask for confirmation of the
operation. In the case of declarations, it will request the number of the agent declaring
the fine. The fines selected will be the ones that are cancelled or declared.
All modifications made to the fines are recorded in the fine reports log.
It is possible to erase fines reports if the user is authorised to do it.
Photographs can be added or erased if entering or modifying a fines report.
Exporting Fines Reports
A window with no flaps in which no modifications can be made. Only exporting entries
or eliminations can be made. The Exporting of Fines Reports creates a file that can be
used for subsequent processing by another application.
Past Record of Fines Reports
A list of fines reports already exported and which are therefore transferred to the fine
report record table. It is operated in the same way as the fines report maintenance, but
users cannot make any modifications, entries or eliminations. The difference between
23
fines reports that have not yet been exported and those that have already been
exported is in the transfer process that first recorded the fine and the date on which that
fines report was exported.
REPORTING
Reports are a very useful tool in consulting different data on the operations performed
with WINID, and the data in its database.
Modification of Fines Reports
A report showing the modifications made, regardless of whether they are already
previously recorded.
Blacklist
A report showing the registrations of vehicles with previous fines reports.
It has the following selection criteria:
• Date from.
• Date to.
• Minimum number of fines reported.
• Origin of the Data. May be Fines Reports, Historic Fines Records, or both.
Statistics
A report showing the statistics combining criteria established by the user. Its objective is
to display the information related with the fines package graphically (Fines reports and
24
Historic Fines Reports). If it combines less than three criteria, the report can be shown in
graphic form.
The combination criteria it has are:
• Street.
• Article.
• Controller.
• Registration type.
• Day.
• Time.
• Month.
25
Configurable elements
Reports in which the selection criteria and columns to be shown can be parameterised.
I.e., the information that is to be shown can be defined in the reports, for the purpose of
making customised reports for viewing the data of the fines package.
General Log A report showing the data that has been recorded in the general log as the operations
are exacted with WINID.
26
UTILITIES
Backup Copy This function is used to make backup copies of the user database in the destination
indicated in the system parameters. If the destination used is a disk unit, the application
will ask for as many diskettes as are necessary for making the backup copy.
Depending on the system configuration, the backup copy will, in addition to the
database, contain the photos of the directory indicated in parameterisation, for storing
the photos already integrated and those remaining to be integrated.
Purging This function erases fines from the historic record, fines that have already been exported
to the file.
Appendix 9 – Pocket WINID
Summary
Introduction
Infraction reporting module
Analysis and presentation of screens
GIS tracking system for controllers
Messaging Module
Digital Signature
Online Authentication
Online Attesting
Panic Button
1
INTRODUCTION
Based on its experience in on-street parking management, along with its knowledge of
new information technologies, Cintra Parking/Dornier is convinced of the management
improvements and advantages that are generated through the application of new
technologies to the daily work of an ORA center.
Cintra Parking/Dornier has therefore developed the MOBILITY System, which is designed
to be a basic support tool for controllers on the street.
The System can include three main modules:
Infraction reports. Its main objective is to issue voluntary infraction reports using a
terminal with PocketPC technology, which is linked to the central server via
GPRS and/or cable. As it is an Open System, it is possible to provide options such
as electronic signatures, printed barcodes, etc.
Positioning. The intention is to combine the Global Positioning System (GPS) with a
custom-designed Geographical Information System (GIS), to locate reported
vehicles on cartography, controller routes, and other similar applications.
Communication or messaging. It offers permanent two-way GPRS communication
between the Mobile Units (controllers) and the Central Station, as a
technological alternative to the conventional system via walkie-talkies. The
sending of images means that other new applications can be used such as the
location of people in searches, representation of maps, etc.
Furthermore, the possibility of using coded text messages leads to a range of
new prospects in terms of the management and operations of an ORA center.
The proposed system is based on a communications server that interacts with the
applications on both sides.
2
The applications are grouped into:
• Internal or fixed applications:
o WINID or another application for processing infraction reports.
o Messaging, message management and control database.
o GIS representation.
• External or mobile applications:
o Infraction reports for the mobile terminal.
o Messaging for the mobile terminal.
o GPS location.
It has thus been possible to achieve a structure with which new requirements may be
covered without having to make substantial changes to the operational and
communications system. An effort has also been made to ensure that the System is not
conditioned to the hardware or physical elements used. This means that the system works
independently of the manufacturer or brand of the chosen mobile terminal.
One of the most sensitive aspects of voluntary infraction reporting applications in blue
zone articles is synchronizing the clocks of mobile devices. Cintra Parking/Dornier is
aware of this problem, and has devised and developed a system for synchronizing the
clocks of all the mobile terminals with the server. The terminals’ clocks are checked and
updated by the central server each time any of the following events occur:
o The PDA (Terminal) is switched on, at the beginning of the work shift.
o A message is sent from the Terminal to the central station.
o A message is sent from the central station to the Terminal.
o An infraction report is sent.
o Catalogs are updated.
A remote ratification solution has been developed as part of the ON LINE infraction
reporting application, POCKET WINID, the implementation of which must be agreed upon
with the City Hall. Because this subsystem is so new and it has been developed
exclusively for the City Hall, it will be explained in a separate section of this document.
3
Details will be given below of each of the main modules of the POCKET WINID System,
together with any improvements that could be made to the controller system of the
company that provides the ORA service.
4
INFRACTION REPORTING MODULE
The proposed infraction reporting module offers all the necessary functions for the
controllers of the ORA service to issue infraction reports at all stages:
o Application of the infraction reporting terminal or mobile unit (POCKET
WINID).
o Communications System between the mobile terminal and the central
infraction reporting software (WINID).
o WINID Central Infraction Reporting System.
The proposed infraction reporting application offers the basic functions required for
issuing infraction reports in the street. The agent can issue a new voluntary infraction
report by entering data into the mobile terminal.
The required information includes the vehicle license plate number (first selecting the
type of license plate), vehicle type, make, model, color, the place where the infraction
was committed, the closest door number as a reference in the street, the door type, the
situation, the article violated and any comments to add to the infraction report.
The agent may then print the infraction report form or ticket to place under the
windscreen wiper of the vehicle and obtain as many copies as necessary.
Other options on the main menu will make it possible to modify the information about an
existing infraction report, to cancel a report that has already been issued, to reprint
infraction reports stored on the terminal, and to enter the program’s advanced options.
It is important to bear in mind that infraction reports can be cancelled by the controller,
but never deleted. They will therefore be recorded and the reason for the cancellation
may be asked, although it is also possible to disable the cancellation option (button).
5
Other functions include:
o Automatic notification of tow truck (depending on the article for which the
infraction has been reported).
o Inclusion of a digital signature in the infraction reporting process.
o Possibility of On-Line authentication by the local police.
o Possibility of allowing a second controller to attest to the infraction.
The program’s advanced options include: advanced configuration function, controller
selection, information about the battery charge state and the options for uploading and
downloading data using the cradle, an SD memory card or ON LINE (via GPRS-based
mobile communications). The program requests a password in order to enter the options
on the advanced options menu.
The mobile terminal application is developed on the PocketPC platform with the
Windows 2003 Mobile Operating System, using all the necessary business logic to
correctly carry out the task for which it is designed.
The fixed operating data and data entered by users will be stored locally on each unit,
using a SQL Server CE Database manager, which provides greater operating speed and
replication and synchronization systems with centralized data repositories, thus always
ensuring the use of local data and correct handling, transfer and integrity when they are
transferred to a central repository for their insertion and integration into the WINID Private
application (or if necessary in another system or platform).
It was developed on .NET Compact Framework and using Embedded Tools as an
implementation language between Visual Basic, Visual C++ and C# according to the
degree of complexity required by each of the parts of the System.
The software’s basic functions are specified below.
6
ANALYSIS AND PRESENTATION OF SCREENS
In principle, the infraction reporting application offers the basic functions required for
issuing infraction reports in the street.
This System’s Client offers different functions:
o Editing infraction reports.
o Printing infraction reports.
o Synchronizing with WINID:
• Using the PDA’s cradle.
• Using a Secure Digital card.
o Sending infraction reports via GPRS.
o Editing messages.
o Attaching digital signatures to infraction reports.
o Sending digitally signed infraction reports.
o Automatically updating the catalog files.
When the application starts up, a main menu is displayed with different options. The
screen that is then displayed offers said options, as well as displaying the information
about the chosen controller’s code, the terminal number, the software version, the date,
the machine’s address and the current time.
The following options are available:
7
NEW – This makes it possible to issue a new infraction report.
PENDING DELIVERY – This displays the infraction reports that have not yet been
sent to the Central repository, due to lack of coverage, loss of GPRS connection,
etc.
PRINT - This option offers the possibility of reprinting infraction reports that have
already been issued and which are stored in the terminal’s internal memory.
ADVANCED OPTIONS - This option displays an advanced options menu, with
advanced configuration options, user selection, communications and battery
charge state.
MESSAGES - This option is used to enter the two-way messaging part of the ORA
Controller system.
NEW OPTION
When the NEW option is selected, a first screen is
displayed for selecting the License Plate Type, as
shown below. This screen displays masks that limit
the type of data entered when collecting license
plate information.
The following mask characters are available:
A - Obligatory character from A to Z.
a – Optional character from A to Z (can be left
blank).
N - Obligatory numeric digit from 0 to 9.
X – Free alphanumeric character.
Once the type of mask has been chosen, another
screen is displayed to enter the license plate number, which specifies the chosen mask
8
type, requests that the license plate number be entered and provides the option of
marking the existence of a tow hook on the vehicle.
9
Another screen is then displayed requesting the following data about the vehicle: Type
of vehicle, Make, Model (the data about the model depend on the make that is
selected) and Color. All the data belonging to these lists is obtained from data files that
can be configured using the management and administration application.
When the VEHICLE TYPE field is selected, the vehicle type selection screen will be
displayed, and by pressing the correct option it will return to the VEHICLE screen.
Make selection screen.
Model selection screen.
Color selection screen.
Once the data defining the vehicle have been selected and it has been ensured that
they are correct, the Next button must be pressed.
10
The data relating to the place where the infraction was committed will be requested.
The Street or place is selected from a list of data such as those mentioned above.
Likewise, the available data are taken from a table that can be configured using the
management and administration application.
Lastly, data are requested to gain a more accurate definition of the place where the
infraction was committed.
These data are the Number on the selected street, the Door Type which is selected from
only 4 possible options, and the Situation which is selected from only two possible options.
11
The following screen, REASON, requests the selection of the violated Article for which the
infraction report is issued. To assist the agent’s task, the Full infraction code and the Text
or Definition of the infraction are shown on screen.
12
One of the following methods may be used to search for the article:
Sequentially – Using the forward and back keys it is possible to view the next or
previous article, respectively.
Simple code selection– By entering an easily remembered three-digit code that
takes us directly to the specified record and shows us the data about the selected
article. The application will not accept a wrong code and will inform the controller in
an explanatory window.
Articles – The whole list of articles will appear by pressing the articles option.
The following screen requests other information about the infraction report, provided that
these options are activated in the configuration table in the terminal’s SQL Server
Database.
13
The following data are requested:
Authentication by Inspector – This displays a check box that will be activated if
the infraction report is authenticated by an inspector. Should it be activated, a
data list of the available inspectors is displayed in order to select the one who has
authenticated the infraction report.
Tow truck notification – This displays a check box that will be activated if a tow
truck has been notified. Should it be activated, a data list of the available tow
trucks is displayed in order to select the one that has carried out the service for
the infraction report. This notification will be automatically integrated into the
pending notifications of the Tow truck application.
Photographs assigned option – A text entry box for a 4-digit number will be
displayed so that the controller can, if necessary, assign up to 10 photographs to
the infraction report.
If the article for which the infraction is reported must be ratified by the Local
Police, the photograph option will be obligatory.
14
Lastly, if the agent wishes, it is possible to add a Comment to the infraction report. This
can be done either by typing in free text up to 255 characters or by selecting a standard
comment from a frequent comment file.
The latter option will be selected from a data list that will show the standard comments
available from a data file that can be configured using the management and
administration application.
The next screen is the Infraction report signing screen, on which all the data that has
been entered can be revised, and once it has been validated the PIN number must be
entered using the keypad, thus completing the process.
Before signing the infraction report it is possible to read a legal warning about this
process.
15
The signing process involves three parts of the system:
Pocket Winid.
The printer’s SmartCard reader.
SmartCard with CERES 2.0 operating system.
The following screen displays a summary of the written infraction report. If the Finish
option is pressed, the infraction report will be stored and the user will be informed by an
informational screen. If the infraction report requires ratification, the application will
remain on hold until the local police send their approval or rejection.
Once the infraction report has been stored, the notification of the infraction report will be
printed out using a BlueTooth thermal printer.
PENDING DELIVERY OPTION
To access this option the Pending Delivery button must be selected from the main or start
screen.
16
This option displays the information about the last infraction report that was issued but not
sent. It is possible to browse through other infraction reports using two keys, previous and
next, until the relevant infraction report is found. The infraction report may also be
located directly by entering its code into a search data box, using the license plate
number. The infraction reports available are those issued by the controller during that
same working day and not yet sent to the central office (in the case of ON LINE
communication).
The agent will select the infraction report to be viewed and the corresponding data will
be displayed.
CANCEL OPTION
To access this option CANCEL must be selected from the main screen: Initially this
function is not Activated.
17
PRINT OPTION
To access this option PRINT must be selected from the main screen.
This option displays the information about the last infraction report that was issued. It is
possible to browse through other infraction reports using two keys, previous and next, until
the relevant infraction report is found.
The infraction report may also be located directly by entering its code into a search data
box. The infraction reports available are those issued by the controller during that same
working day.
The agent will select the infraction report to be printed, and the print screen will be
displayed, making it possible to print as many copies of the chosen infraction report as
necessary.
18
ADVANCED OPTIONS OPTION
To access this option ADVANCED OPTIONS must be selected from the main screen.
When this option is selected, an advanced options submenu screen will be displayed
with nine available second-level options, which are:
The controller may only modify the data included in the following sections:
ZONE.
SUMMARY.
19
The other options will require a password that only the inspector must have access to.
When a protected option is selected, a password is requested to prevent any
unauthorised user from accessing this area and making undesired changes to the
application’s configuration.
To ensure this restriction each mobile terminal is equipped with a password that may be
changed by the system administrator as often as necessary.
Additionally, each terminal may have a different password.
20
CONFIGURATION – This makes it possible to configure the information about this terminal.
APPLICATION – This makes it possible to configure the application parameters.
CONTROLLER – This makes it possible to select a different agent to the agent selected by
default.
ZONE – This makes it possible to select the work zone or route.
CHANGE PASSWORD – This enables the inspector to change his/her password.
PDA - the following tasks may be performed:
Date_Time.
Assignation of the Serial Port (For BlueTooth printing).
Messaging.
Communications server IP.
Port.
Device name.
21
FTP.
User Name.
Password.
Port.
Deletion of data from the PDA’s Database.
BATTERIES – Shows the battery charge status of the PDA and the Printer.
COMMUNICATE - This option makes it possible to upload the tables needed to issue
infraction reports and download the data about the infraction reports that have been
issued, using a cradle connected to the control PC, GPRS communication or BLUETOOTH.
22
SECURE DIGITAL - This option makes it possible to transfer the data about the infraction
reports onto a memory card, so that an inspector may collect the data about the
infraction reports that have been issued by several controllers directly from the devices.
SUMMARY – With this option, which can be viewed by the controller, a summary of
information can be obtained about:
Controller:
o Name.
o ID number.
o CODE.
Infraction reports pending transfer:
Total no. of infraction reports.
Total no. of valid infraction reports.
Total no. of cancelled infraction reports.
List of articles infringed.
23
24
GIS TRACKING SYSTEM FOR CONTROLLERS
Should it be required by the City Hall, within the Mobility hardware, the ORA controller
may be equipped with a Global Positioning System (GPS) device that works with a
Geographic Information System (GIS) to locate all the controllers on the street from the
central office, thereby providing the service with very important information. DORNIER,
S.A. has not included this option in its basic offer.
The same central application is used for the GIS system as for Mobility Grúa, although
with different parameters, as different elements are to be tracked: in this case humans
and in the other case tow trucks.
In the Annex of this document entitled: “Mobility Grúa” the basic functions of the
proposed GIS system are specified.
The geographic coordinates detected by the GPS device will be sent to the central
station via the GPRS network.
The GPS device will be a portable device with a BlueTooth connection.
25
MESSAGING MODULE
The MOBILITY System includes the option of a specific messaging module so that
controllers do not have to carry walkie-talkies.
The purpose of this module is to establish continuous two-way communication between
controllers and the central station operators.
The messaging system includes:
• Broadcasting of emergency messages (from the Central station to Controllers).
• Broadcast messages from the control station to a group or to all of the controllers. • Messages from a controller to the Central station.
• It must allow export with predefined options to Access databases, Excel, etc.
• This must be a tool that can be easily integrated with other existing applications,
such as the tow-truck call application.
According to experience in similar centres, more than 95% of the estimated transmissions
are encoded. On the other hand, un-encoded information transmission, and even the
incorporation of voice in closed user groups must always exist.
The types of messages sent can be grouped under three concepts:
Dispenser maintenance. A notification is sent indicating the dispenser and the type of
malfunction. These messages can be fully transferred to the proposed system
because the use of voice is not required.
Tow-truck notifications. This situation is very similar to the previous one. The location and
identification of the vehicle, the infraction being committed, and the level of
urgency of the tow truck are sent .
Service. These are open-format messages that in theory are more difficult to encode and
replace with voiceless messages. The calls normally come from the local police or
an ambulance, or another type of emergency service, people rescue services, etc.
26
Regulated Spaces: Sending Messages with information regarding parking space
occupancy, either by construction disposal containers, building works, etc.
In the appendix: "Appendix: Central Messaging Application" of this document, the
functionalities of unified messaging are described in detail.
27
DIGITAL SIGNATURE
DEFINITION
The digital signature is a block of characters accompanying a document (or file) that
verify the author (authentication) and confirm that no manipulation has been performed
subsequently on the data (integrity).
In order to sign a digital document, the author uses a secret key (asymmetric
cryptographic system), to which no one else has access, and which prevents the author
later denying authorship (non-repudiation). In this way, the author is linked to the signed
document.
Also, the validity of this signature can be checked by any person obtaining the public
key of the author.
For issuing infraction reports by mobile devices, DORNIER, S.A. considers that it would be
very interesting to include the controller's digital signature and will use such technological
solutions for this purpose.
PROCESS DESCRIPTION.
The following system functions are involved in the digital signature process:
Pocket Winid.
Zebra Cameo 2 SC SmartCard reader. This reader implements the T=0 protocol.
SmartCard with CERES 2.0 operating system.
28
The process uses the following steps:
1.- Issuing an infraction report.
2.- Verification of the card user PIN.
3.- Reading of the following fields of the digital certificate held on the card:
Name.
Surname 1.
Surname 2.
NIF (Tax Id.).
4.- Generation of an XML document containing the data of the infraction report. The
format of this XML document has been defined by the City Council. We will call this
document the "tique_xml”.
5.- Calculation of the SHA-1 hash of the "tique_xml" document. The hash is calculated on
the PDA using the Crypto API.
6.- Generation of an XML document according to the XML Signature recommendations,
which we will now call "signed_xml". The "tique_xml" and the previously calculated
"tique_xml" hash will be stored in the "signed_xml".
29
7.- Signature of the element <SignedInfo> (calculation of the hash and encryption with
the private key). The hash is calculated on the PDA using the Crypto API.
8.- The signature is stored as the content of element <SignatureValue> of the "signed_xml"
document.
9.- Storage of the "signed_xml" document in the "signed_xml" table in the Pocket Winid
database.
30
31
ON-LINE AUTHENTICATION
INTRODUCTION
The Ratification or on-line authentication system is one option within the POCKET WINID
application that simplifies or reduces the number of resources that citizens may use
when a controller or O.R.A. service officer issues a voluntary infraction report on
certain municipal ordinances, especially those related to the removal of a vehicle.
The functioning of the process of issuing voluntary infraction reports without including
on-line ratification is:
O.R.A. Controller detects a vehicle
committing and infraction
The infraction report is sent to the
DORNIER, S.A. base and it is printed
Infraction report stored in DORNIER,
S.A. database pending being sent to the
City Council
A file of infraction reports (both from
O.R.A. and others) is generated for the
City Council
The City Council includes these
infraction reports into its normal process
32
The problems implicit in this process is the possibility that an infraction report not linked
to O.R.A. is not ratified by local police; this is clearly an inconvenience when this
infraction report is challenged.
The solution proposed by DORNIER, S.A. (for those infraction reports with special
treatment) for the City Council is:
O.R.A. Controller detects a vehicle
committing and infraction
The information for the infraction
report is sent to the Local Police
with photographs
The Police
approve the
infraction re
port
YES
No The controller does not store the
infraction report
Local Police digitally sign the
infraction report
The infraction report is stored in the Local
Police intermediate database with the
signature of the police officer ratifying the
infraction report and the code of the
controller who issued it
An OK is sent to the controller who
prints the infraction report
The infraction report is stored in the DORNIER, S.A. database but is not
sent to the City Council as it is already stored by the Police
33
The main advantages of this model are:
Infraction reports are always ratified by the agents of the authority.
The physical presence of local police at the place of the infraction is not
necessary.
There is the possibility of increasing the number of ratified infraction reports
with fewer assigned police officers.
Incorporation of the official digital signature for the legal validation of the
ratification.
SYSTEM FUNCTIONALITY
Management of O.R.A. Infraction Reports
Management includes the following points:
Writing, modification and cancellation (in the case of the Palma de Mallorca
O.R.A. service, the cancellation option is disabled) of infraction reports.
Printing of infraction reports.
Sending infraction reports via GPRS.
Downloading of infraction reports by means of the cradle or a Secure Digital
card.
The infraction reports received by the communications server are inserted
automatically into WINID database.
Management of Infraction Reports needing a Police Officer's Authorisation
Management includes a system that allows the issuing of infraction reports requiring a
police officer's authorisation. This systems enables a dialogue between controllers and
police officers to be established so that the police, in view of the reports that they
receive from the controllers, have enough information to authorise, or disapprove, the
issuing of an infraction report. The reports written by the controllers normally include
photographs.
34
All the messages exchanged in the dialogue are stored in the server database. The
police officers use the WEB application as the interface to communicate with the
controllers. Once the process has completed and if the infraction report has been
authorised, it is automatically integrated into the WINID database.
Writing and Sending Messages
Writing and viewing message on the PDA.
Writing, viewing and finalising message from the WEB.
Transmission of messages between PDAs and communications server.
Remote Update of Catalogues
Catalogue files that are used in writing infraction reports are generated in WINID. A
system will be implemented so that the PDAs can download the latest versions of the
catalogue files. This system will have the following characteristics:
It will be possible to create, cancel and review status of download orders
from the WEB.
When a PDA receives a download order, it will connect to the FTP server and
download the required catalogues.
PDAs will send messages to Central in order to communicate:
o Attempts at downloading catalogues.
o Download completion.
This information will be viewable from the WEB application.
One download order may contain many catalogue download orders.
APPLICATION SCREENS
The screens of the authentication application are shown below.
35
36
37
ON-LINE ATTESTING
INTRODUCTION
The on-line attesting system is an option within the POCKET WINID application that
simplifies and reduces the number of resources that citizens may use when a O.R.A
service controller or security guard issues a voluntary infraction report.
By means of attesting, a second controller can check in situ the infraction report that a
colleague has made and digitally sign it.
Cintra Parking/Dornier have planned for two distinct possibilities:
in situ attesting process by a second controller in the street, following the basic
schema attached.
On-line attesting process. This option, a variant of on-line authentication, allows
an infraction report issued by a controller to be viewed automatically on the
Intranet WEB (information of the infraction report and photographs).
An appropriately qualified person in the Cintra Parking/Dornier office will be checking
all the infraction reports issued and will sign each one when everything is correct.
In the specific case of the O.R.A. proposed to the City Council, the first option is
recommended in the first instance as it matches the existing procedure more closely.
In any case, Cintra Parking/Dornier is working on both alternatives and will provide the
option preferred by the City Council.
38
39
PANIC BUTTON
The implementation of a security system and automatic notification to Central
safeguards controllers' security and physical integrity. This issue, very necessary for the
high profile work performed by the controllers, is often not implemented in the majority
of GPRS-based systems as it is inherent in communication systems based on WALKIE-
TALKIES. DORNIER, S.A., being aware of the problems of working on the streets, has
made an significant effort to implement a secure system that is easy to use.
By the implementation of the "Panic Button", the Mobility system is provided with the
following functionalities:
When a user presses a hardware button, the following actions are performed:
1. A GPRS alarm message is sent to the communications server.
2. A SMSa message is sent to the PDA Central. The PDA Central communicates
with the communications server by the exchange of frames over TCP/IP. This
PDA must be connected to the machine on which the communications server is
executed by a trustworthy and robust physical connection, preferably through
the ActiveSync cradle. 3. A telephone call is made automatically.
The configurable parameters are:
• Hardware button that initiates the chain of events. One of the following
buttons can be selected: o Contacts.
o Calendar.
o Camera.
o Voice recorder.
• Telephone number to which to send the SMS message.
• Telephone number to which to make the call.
Actions to be performed when the hardware button is pressed.
Each action can be activated or deactivated independently.
40
41
1. When the communications server receives a GPRS alarm message, it stores it in
the WEB database and forwards it to all the connected PDAs that are on routes
adjacent to the routes belonging to the PDA that generated the alarm message.
2. When the PDA Central receives the alarm SMS, the following actions are
performed:
• The Central PDA notifies the server that it has received an alarm SMS
message.
• The server stores the SMS in the database so that it can be viewed
from the WEB.
• The server obtains the telephone numbers of all the PDAs on
adjacent routes to those belonging to the PDA that generated the
alarm message.
• For each telephone number obtained, the server sends an order to
send an SMS to the Central PDA.
• The Central PDA sends an SMS message for each order it receives
from the server.
3. A process is implemented on the server to check that the Central PDA is operational.
If the Central PDA fails to respond to server instructions of the server, this generate a
message of "Central PDA not operational" on the WEB. The activation of this check will
be configurable by a configuration file on the server.
4. The administration of adjacent routes and the telephone number of the terminals is
performed via the WEB.
Appendix 10 – Resident Management (CERES/Mobility)
Summary:
Description
Integration with applications (Mobility)
Hardware Elements in the RFID solution
Planned improvements
Appointment Reservation Web page
1
DESCRIPTION
Cintra Parking/Dornier, manages the assignment of Resident stickers in several Spanish
cities, and has detected the problem generated by the counterfeiting of the stickers by
a certain number of users, and the complexity of the annual renewals and delivery of the
stickers.
In its search for solutions to the different problems, it has implemented a hardware and
software system (CERES SYSTEM) with the following main characteristics:
• Centralized SQL Server Database.
• Maintenance and query web application (intranet).
http
Consultation, inspection and modification of data.
Server Web
SQL Server: Database of Residents
Client Web
• Resident sticker based on RFID technology and that also includes a barcode.
• Possibility of incorporating an RFID reader and integrated Bluetooth with the
infraction reporting terminal.
• Possibility of incorporating a barcode reader.
• Partial local loading of the residents table in the infraction reporting terminals (by
sectors).
• Integration with analysis tool and/or other subsystems.
2
• Integration with the infraction reporting application, since both were created on
the same Mobility platform.
CARD MANAGEMENT MODULE
The purpose of this module is to manage the tracking of a card through its life cycle
and to provide support for the control and handling of the different elements
associated with them.
It is the central module of the application, since its main objective is to manage
cards. For this reason, the system’s other modules are served from the card
management module to obtain the data that allows them to carry out their
functions. The reason for this dependency is because the other modules revolve
around card information. Their existence would not make sense independently, since
its information always makes reference and completes the elements of a card. Unlike
a card, whose existence does not depend on the other modules.
This module will consist of a series of classes responsible for performing the following
functions:
3
Managing the card registration requests, for which all the necessary information will be requested.
Manage the card life cycle, from the registration request to the final stages. The user can change the status of a card, or carry out the actions that trigger the change.
Query cards by applying a series of filters. To see which cards fulfill a series of criteria, or simply to consult cards.
4
Storage of the log of actions carried out on a card, so that it is possible to know who did what and when.
Printing the lost card receipt.
Printing the resident sticker.
PAYMENT COLLECTION MANAGEMENT MODULE This module contains the elements needed to manage all of the payments
associated with a particular card. The following functions are associated with it:
Consult the characteristics of a specific payment. This section will specify the
elements that make up the payment: method of payment, amount paid,
date, etc.
Generation of payment receipts at any time. These receipts will be generated
in PDF format and may be printed or stored on the local machine. (Common
format for all centers pending definition).
DOCUMENT MANAGEMENT MODULE
The purpose of this module is to manage the documents associated with a card and
that are required for a card to be issued. This module is used to open and read the
physical documents provided during the registration process, for later storage in the
database. This module also interprets the stored content, and allows content to be
viewed through the web application, regardless of whether they are PDF files or
image files.
WORK CENTER CONFIGURATION MODULE
The function of this module is to manage and allow the configuration of the city’s
Regulated Parking Service center. The module is used to determine its operating
options. The following elements can be configured through this module:
Documentation allowed to manage a card registration.
5
Management of the zones associated with the Regulated Parking Service
center. The zones for which the card is issued can be created, deleted, and
modified.
Duration of the period activated for renewal.
Management of accepted payment methods.
6
REPORT GENERATION MODULE
The function associated with this module is to generate a series of reports on the
activities carried out in the system. This module will not have direct access to the
data stored in the DB, but rather will use the data in the card management module
and the payment module to obtain the information that will form part of each one of
the reports. These reports will be a synthesis of the operations carried out over the
course of a particular period of time.
7
Two different types of reports can be generated with this module:
Card management report: This report will include all of the operations carried
out on the cards during the selected time interval. This will give a record of the
management activities carried out (cards issued, cards rejected, etc.). The
form for this type of report is still pending definition.
Payment report: This report is used as a record of the payment collection
operations completed during the selected time. It will make it possible to
determine how much money has entered the system, as well as its source. This
report will also allow specified management operations to be carried out,
such as: calculation of totals, calculation of averages and variances,
comparison of data among weeks of the selected interval, among months of
the selected interval…The format for this type of report has not been defined
yet.
8
INTEGRATION WITH MOBILITY APPLICATIONS
The proposed system is not an isolated system, but rather forms part of a comprehensive
Cintra Parking/Dornier SENA/Mobility solution. Obviously the first integration must be with
the application that the controller carries on the PDA, and it must be integrated with the
infraction reporting application.
How does the daily process of a controller in a city that uses the Cintra Parking/Dornier
residents solution work?
He identifies the sticker, either by RFID, by
barcode or by manually entering the license
plate number into the PDA.
Everything
correct?
Report infraction based on
the corresponding Article The information on the
resident and the location
and time are sent to the
central DB (for later analysis)
END OF THE PROCESS
YesNo
The controller detects a vehicle with a resident
sticker without a ticket
9
How is a new resident registered with this application?
The central application is a web application. The user has to enter the necessary fields:
• Name.
• Last Names.
• Identity card number.
• Street in census registry.
• Vehicle for which the sticker is requested.
• Required documentation to be presented.
• Validity period for the sticker being issued.
• Sector to which it corresponds.
• …
When the sticker is accepted for printing, the TAG or sticker will be recorded with RFID
technology and the code for the tag associated with the sticker will be saved in the DB.
The update for the new resident will be sent to all of the mobile terminals (Controller
PDAs), with just the following data:
• Tag code.
• License plate number.
• Expiration date.
• Sector.
What is the procedure to authorize for another year?
The information for the resident in question is verified in the database. The documents
that have been submitted are specified. When the new year is authorized, the expiration
year just has to be changed in the DB.
All of the local DBs on the PDAs will be updated at that time.
10
If deemed necessary, a sticker can be physically distributed for each year, canceling the
code tag of the previous year’s sticker in the database, and associating it with the one
for the new year. All of this is programmable.
What happens if the RFID reader malfunctions during the workday?
The CERES system takes this possibility into account, and what’s more, it has been
designed to work without RFID communication. To do this, the controller must enter the
license plate number into the PDA application and it will automatically verify:
• The existence of the sticker in the Local Database.
• If it doesn’t exist in the local database, it will check it against the central
database.
At the same time, since there is a local database on each PDA, which is updated daily, if
there is a communication breakdown, the system can function independently.
How can information on resident space occupancy be obtained in real time?
Since the system is totally integrated, as soon as a controller verifies a sticker streetside,
the tag data is sent to the central database, along with the location and time, and this is
stored in a temporary resident table.
Since the database (table) is connected to the Cintra Parking/Dornier web analysis tool,
a wide variety of ratios and statistics to be defined by the City Hall can be generated.
11
HARDWARE ELEMENTS IN THE RFID SOLUTION
RFID PEN
We propose the use of an RFID pen with a large number of functions for the resident
management application.
Main factors and benefits:
Freedom and flexibility of wireless connections. Compatible with virtually any
device with Bluetooth® such as Pocket PC, Tablet PC, Smart Phones, Desktop PC,
etc.
As a pen. Using the RFID reader in pen mode allows users to interact with
PocketPCs and TabletPCs.
Comfortable, ergonomic shape. Typical portable RFID readers are large, heavy,
and difficult to handle. Our RFID reader has an innovative “pen shape”; it’s small
and lightweight, and can easily be carried in a pocket.
Comfortable and easy to use. On-board storage of data allows it to collect the
information from thousands of tags without being connected to a data
processing device.
12
RESIDENT STICKER PRINTER (RFID AND BAR CODE)
A high-performance printer that records with RFID technology is needed to print the
stickers. There are several models on the market with the necessary specifications, such
as the Zebra R110xi, although the selected model will depend on the type of sticker that
is to be issued (size).
LATEST TECHNOLOGY APPLIED
What is RFID?
Radio Frequency Identification (RFID) is a state-of-the-art technology for complete
identification of any type of object, which allows data to be captured quickly and
automatically by radio-frequency. RFID is mainly used in areas in which the level of
performance provided by other technologies is insufficient, such as barcodes (for
example, in logistics, material management, industrial automation, post-sale service,
etc.).
It may seem that barcodes provide the same advantages as RFID, but this is not true.
Some of the differences are listed below.
13
The advantages of RFID with respect to barcodes
• Contactless identification (also functions without visual contact)
• Passes through different materials, such as cardboard, wood, etc.
• Data can be read and written to the memory as needed.
• Identification in less than one second
• Simultaneous capture from multiple transponders
• Resistant to adverse conditions (extreme temperatures, humidity, etc.)
• Transponder shape and size can be adapted to suit needs
• Transponders can be completely integrated into the product
• Increased security thanks to encrypted data transmission / data protection
The benefits of RFID (applied specifically to the logistics sector)
• Automation / optimization of production, storage, logistics processes, etc.
• Error reduction (e.g. thanks to automation of incoming and outgoing materials).
• Faster information flow (“in real time” and “on-demand production” thanks to
availability of information beyond the SCM chain).
• Elimination of all manual scanning processes, with the resulting cost reduction.
• Minimization of theft, deterioration, etc.
• Stock and cost reduction.
What are the functions of an RF Reader?
• Establish a two-way data link.
• Tag inventory and filtering of results.
• Communication with a network of servers.
Why RFID in resident management?
Although RFID technology has historically been strong in the logistics market, resident
management has several similarities.
14
Location of resident vehicles.
Verification that the sticker corresponds to the vehicle.
Verification that the vehicle is parked as a resident in the established area.
Connection with a central database to confirm all data.
Extremely difficult to counterfeit stickers.
Analyzing other solutions, such as barcodes, RFID is the implementation that is
technologically the most suitable.
15
Examples of adhesive RFID devices in other centers managed by Cintra Parking/Dornier:
X.E.R. in Vigo.
O.R.A. in Alcobendas.
16
17
PLANNED IMPROVEMENTS
A smart system of this type gives the City Hall an unlimited range of possibilities. The
following list includes a few:
• Stickers cannot be counterfeited, which is one of the biggest problems facing areas
with these services today.
• There is no need to give out a sticker every year; the same sticker can be used for
several years and the expiration is set by the system.
• Detailed studies can be generated on the frequency of use of the regulated zone by
residents. When the controller verifies whether or not a resident vehicle is parked
correctly, a record is generated in the central database, so that detailed information
on resident occupancy is available online.
• Complete integration into the platform designed by Cintra Parking/Dornier,
SENA/Mobility, with a special relation with the infraction reporting area, and if a
sticker is expired or out of the sector, the infraction will be reported automatically.
APPOINTMENT RESERVATION WEB PAGE
One of the most tedious aspects of the resident management process is the collection
of documents and the issuing of stickers. To facilitate this process, a website will be
created to assign “appointments” to avoid lines at the office where the stickers are
managed. This assignment of turns will be done in the following ways:
• By phone.
• By assignment through the website.
A link to the appointment reservation application can be included in the City Hall’s
website, or in the web page with information on the Regulated Parking Service.
18
Appendix 11 – Tow Truck Mobility
Summary:
General Description of the Solution
Detailed Description of the Tow Truck Mobility System
1
GENERAL DESCRIPTION OF THE SOLUTION
INTRODUCTION
As a product of Cintra Parking/Dornier’s years of experience in management of Towing
Services, it has created the MOBILITY GRÚA system, which uses new technologies to
optimize and minimize response times to remove improperly parked vehicles.
The system is made up of the following modules:
• Geographical Information System (GIS).
• MOBILITY System Software onboard the Tow Truck (SOGG). Vehicle-towing
management application that runs on the PDA terminal in the Tow truck.
• Tow-truck Base Management System (SGBG). Whose databases reside at the
Tow-truck Base or in the tow-yard offices.
• Messaging and Notification Subsystem (Base/Tow truck and vice-versa). This point
is explained in detail in Section: “Appendix 12 – Central Messaging Application.”
in this manual.
The interaction between the system and the police officer who approves the removal of
the vehicle may be done with the police physically present and/or remotely, depending
on the municipal ordinances and the operational functioning the best adapts to the city
or town.
The overall system, though divided into modules, is based on the interconnection of all of
those modules. This interconnection is what makes it possible for all of the functions
involved in the tow service to be viewed as a single system.
A tow-truck call can be generated by:
• Citizens by calling a customer service number.
• Police officers on the street by walkie-talkie or police mobility.
• ORA agent.
• Tow Service personnel.
2
• Other possible methods that the City Hall feels would be beneficial.
Note that it must be possible to know the following at all times:
• What each tow truck is doing.
• The status of each tow truck call.
• Where a particular vehicle has been towed from and the costs
incurred by the owner.
• The current location of each towed vehicle.
• The status of fine payments and the method of payment used.
3
OTHER FUNCTIONS
Mobility Tow Truck includes other functions that are especially interesting for tow truck
management.
• Mechanical immobilization of vehicles. This option is considered as a normal part,
except that the infringing vehicle is immobilized using a boot instead of being
removed to the tow yard.
• Vehicle movement. This option is considered as part of normal vehicle removal,
with the special condition that the vehicle is not taken to a tow yard, but rather
to another nearby street.
• Additions for traffic organization and signaling. This module covers two
fundamental aspects in the management of variable signaling.
Other basic characteristics include:
• Payment at the tow truck, with different methods:
o cash,
o credit card, using a standard EMV GPRS dataphone.
o and also the possibility of making payment via mobile phone.
• Mobility Grúa has also developed the tow-yard management system.
• Another important aspect is refueling management, maintenance of the vehicle
fleet, which results in optimized service and vehicles.
• Identification of vehicle location at all times and the vehicle service status (Free,
Occupied, at Tow Yard).
In addition, there is an analysis tool based on Business Intelligence (BI) technology
that makes it possible to extract crossed information from the tow-truck database for
later analysis. It is a single tool because of its graphics power and ease of use.
4
Integration with other applications
It is very important to note that the Tow Truck Mobility system is an open system that is
ready to be integrated with other information systems developed for the City Hall. Cintra
Parking/Dornier agrees to study the possible interconnection with the different
applications that the City Hall has implemented.
ON-BOARD MOBILITY SYSTEM (SOGG)
The SOGG subsystem or application is the tool needed for the mobile management of a
service to remove vehicles from public roadways, and for this reason, it is considered to
be the main module of the Tow Truck Mobility System. Chapter II of this document
describes the system’s functions and screens.
Analyzing the normal flow of a service for the removal of vehicles from public roadways,
it has been determined that “down” times can be reduced if the Municipal Police officer
can avoid traveling to the vehicle slated for removal. This means that the use of new
mobile technologies would minimize the procedure time, making the service more
effective, without neglecting the fact that the removal of a vehicle from the public
roadway has to be authorized by Municipal Police officers.
As shown in the diagram below, the blue squares are those involved in the Onboard
MOBILITY System (SOGG).
5
The functional layout is:
The police officer authorizes
the tow-truck operator remove
the vehicle.
All of the information is sent via
GPRS to the MOBILITY GRÚA
system installed on the
computer network of the officer
responsible
The MOBILITY GRÚA software
generates all of the information
to send all of the information for
the vehicle removal in question
to the officer online
The tow-truck arrives at the
infringing vehicle
The MOBILITY GRÚA
software generates the
extra documentation
requested by the officer
The officer requests
additional information, new
photographs, etc. from the
tow-truck operator
The officer requests
additional information, new
photographs, etc. from the
tow-truck operator
Does the officer need
more information to make a
decision?
Does the officer confirm
vehicle removal?
Photographs and
other pertinent
information
End of the process
for vehicle XXX
Notification that a vehicle is
being removed
6
The SOGG must allow wireless and permanent communication between the data
network (LAN) of the Municipal Police or the company that provides the comprehensive
service to remove vehicles from public roadways, and the tow truck fleet. This data
communication includes ONLINE transmission of digital quality photos and the
information from the Municipal Police officer to the tow truck driver, which must include
the digital signature of the officer or another type of authorization based on
user/password.
Communications server
The following information may be transmitted:
A notification is sent from the central office to the free tow truck closest to the infringing
vehicle. This notification is sent by the MOBILITY application. This message will immediately
arrive at the terminal in the tow truck with the following information:
• Make, model, color, and license plate number of the vehicle.
• Street and number.
• Article violated (provisional).
Vehicles - Tow
Truck
GGPPRRSS NNeettwwoorrkk
BS
Terminal
GPRS/GSM/
Bluetooth
Terminal
GPS
Local Police Central Unit
CENTRAL
SERVER
DBDB
Onboard
Equipment
Local Police Workstations
Information digitally signed by the
agent
7
The tow truck goes to the location of the infringing vehicle and gathers all of the required
information:
• Photos of the infringing vehicle taken from different angles.
• Complete address.
• Other descriptions or comments.
The information is sent to the Municipal Police’s database server via GPRS.
The police officer, from a personal computer, will be able to connect to the database
server and will verify that a new report or case file has been generated for analysis. If the
police officer deems it necessary, more information can be requested from the
workstation.
When the officer feels that he has all of the information on the infringing vehicle at his
workstation, he will give the order to proceed with the removal of the vehicle, sending a
message to the tow service personnel to remove the vehicle. This communication must
be digitally signed by the agent.
Reports to be printed in the Tow Truck
The following documents must be printed in the tow truck (the formats included here are
just sample models):
Printing the citation, with the typical fields:
• Vehicle identification:
o Make.
o Model.
o Color.
o License plate number.
• Identification of the location:
o Street name.
o Street number.
• Article violated.
• Officer who authorized removal.
• Etc.
8
Printing the payment receipt, if the vehicle owner appears when the vehicle is going to
be removed.
Paying fines “in situ” (Onboard the Tow Truck)
This point makes sense if there is no police officer physically present when the vehicle is
secured. Otherwise, payment will be made directly by the vehicle owner to the police
officer.
The owner of the infringing vehicle may pay the fees and the fine for the infraction right
in the tow truck. There are three possible methods of payment that can be used. In all of
them, the management application records the method of payment used and will
generate a receipt for the payment for the person who makes the payment.
The three methods of payment are:
• Cash.
• Bank card.
• Mobile telephone.
Payment with bank cards
The on-board equipment will include an ON-LINE GPRS Dataphone to process fee and
fine payments by bank cards.
Payment with Mobile Phones
Though this method of payment still has very low penetration, it is expected to
experience significant growth.
If use of mobile phone payment methods like MOBIPAY increases significantly, Cintra
Parking/Dornier would develop a system that would allow vehicle owners to make
payments using their mobile phones.
9
TOWTRUCK BASE MANAGEMENT SYSTEM (SGBS)
The Tow truck Base Management System (SGBS) or SOGG Server will be the central core
of all of the computer applications running in the tow-truck service, since it acts as the
point of connection for all of the elements. At the same time, it is the visible component
for the different areas involved in the operation of the service (both municipal and in the
concessionaire). Chapter II of this document describes the system’s functions and
screens.
The system will consist of a database that stores all of the actions related to a particular
case file, from the time it is created until after it is stored as a log entry.
The system must include automatic interfaces with both the Onboard MOBILITY System
(SOGG), as well as manual entry with the officers who handle the start of the tow-truck
call and who will generate the case files.
The system can be divided into two basic functions:
• Case File Management.
• Queries and Analysis/Reports Module (described in more detail in “13 Appendix.
Integrated Control Panel”).
Case File Management
The Case File Management System covers all of the case files and the entire life cycle
from when they are opened until they are closed, with all of the information saved for
later analysis by the Query and Analysis/Reports Module.
The basic steps and data processed from the time a case file is opened and closed are:
Opening case file:
• Vehicle information (vehicle type, make, model, color, license number).
• Reason for notification (notification source, ordinance article, description of the
infraction, comments).
• Location information (street, number).
10
• Service information (employee, date and time notification was received, date
and time tow truck notified).
Initiation of vehicle removal:
Creation of reports for Police verification:
• All of the vehicle and vehicle location information is previously stored in the case
file.
• Written report on vehicle status prior to tow hookup.
• Visual report (with digital photos) of the vehicle condition prior to hookup.
• Date and time of police authorization and information on the authorizing officer.
• Date and time of tow hookup.
If the vehicle’s driver or owner appears at that point:
• Owner information and address.
• Amount of fees collected and the citation amount.
• Method of payment (cash, card, or mobile phone).
• Date and time of return to the owner.
Arrival at the tow yard (partial closure of the case file):
• Written report on vehicle status after being left at the tow yard.
• Visual report (with digital photos) of the vehicle status after being left at the tow
yard.
• Indicator of the tow yard or base where the vehicle was left.
• Date and time vehicle was dropped.
• Notification of the party involved by sending the generated report.
Vehicle return (case file completely closed):
• Owner information and address.
• Amount of fees collected and the citation amount.
• Method of payment (cash, card, or mobile phone).
• Date and time of return to the owner.
It will be possible to query the status of a case file or group of case files from the Case File
Management application.
11
GEOGRAPHICAL INFORMATION SYSTEM (GIS)
The Geographical Information System (GIS) application, along with the on-board
equipment, makes it possible to determine the geographical location of all tow service
vehicles, so that the operator can select the one that fulfills the requirements of
availability and proximity to the incident location.
The system estimates the geographical location of all of the service’s tow trucks with a
margin of error of less than 50 meters and tracks their routes for specified periods of time
(days, weeks).
Configurable aspects:
• Tracking times that can be configured by the administrator.
• Route travel times.
• Setting geographical alarms.
Aspects to be resolved:
• Vehicle positioning on cartography.
• Detailed tracking of specific tow trucks.
• Notification when a particular vehicle passes through a geographical alarm,
which can be used to open and close shifts.
• Graphic representation on cartography of routes taken by tow trucks, with the
possibility of defining a route.
Service Assignment Reports:
• Generation of Reports by vehicle and day.
• Exportability of reports to Excel (*.XLS) and flat text files (*.TXT).
• Help in arranging shifts.
• Automatic generation of inspection reports.
• Statistical calculations (averages, variance).
• Hours Worked by the Tow-Truck Operator.
• Generation of other reports agreed upon with center supervisors.
12
Vehicle location is determined by the transmission of geographical position from the
mobile units. To do this, they must be equipped with an integrated GPS and
communications system. The system receives these positions, displays them on the
cartography and stores them in a database for later studies.
The GIS graphic interface has been designed to provide all of the necessary information
on the screen so that the map is always visible and does not complicate the operator’s
location tasks.
Display Functions
The cartography display will include the basic tools of a system of this type, including:
• Zoom In.
• Zoom Out.
• Move the map using the drag and release function.
• Resize the map to show only the area outlined by a square.
• Centering.
• Etc.
The following will be developed as special tools to assist operators:
• Tracking routes of mobile resources. The system can display only the last known
position of mobile resources on the screen, or at the operator’s request, can
maintain the previous positions, displaying the route.
• Address location. On vector cartography, the system administrator can defined
the layers and information fields that will be searched for text strings, with the
possibility of searching for any of the map information: streets, parking lots,
hospitals, stations, airports, etc.
• Location of resources near a point. The operator has two tools to locate resources
near a point. From a point indicated by the operator, the system will provide a list
of the resources closest to that point in a straight line. Either for a pre-defined
area or an area described by a circumference specified by the operator.
13
The GIS visually displays the specified resources on the map, along with the associated
information: status, route, identifier always according to the information for the resource.
Resource Control Functions
Resources can be divided into different categories depending on the system’s
requirements. There are two types of resources:
Static. These are non-mobile resources. Fixed locations of interest to the operator, such as
hospitals, police stations, workshops, gas stations, etc.
Dynamic. Dynamic resources are considered to be any resource that is to be
represented and that may change position: vehicles, people, events, etc.
The Geographical Information System (GIS) application will allow both types of resources
to be pinpointed on maps, keeping a log of any movements that they may make.
To manage resource positions, there is a list that contains all of the resources in the
system. The system administrator or emergency and services manager are responsible for
adding, removing, or modifying these resources. This means that the administrator can
specify the icon to represent each resource or resource type on the cartography.
The following functions can be carried out on these resources:
Update position The system allows resource positions to be updated.
Activation/Deactivation Resources, within the geographical information system, may be
active or inactive, depending on whether or not the resource is operational. This means
that they do not have to be deleted from the system when not working with them.
Location Redraws the map so that the resource is in the center of the map window.
Tracking A new window opens so that the resource is always visible in the map window.
14
Manual resource location Resources that do not have GPS or that have lost coverage to
transmit their geographical location may be positioned on the map by the operator.
Automatic Position Acquisition Functions
As mentioned before, vehicles equipped with GPS positioning devices can periodically
send their position to the Geographical Information System so that they are displayed on
the map in real time.
To carry out this function, the parameters of the mobile units that automatically send their
position can be configured in the Geographical Information System.
The allowed configurations are determined by mobile units. Some of the most common
functions, among others, are:
Configuration of position transmission by frequency Configures the mobile unit to send
position data after a certain time interval.
Configuration of position transmission by distance Configures the mobile unit to send its
position after covering a certain distance from the last position sent.
Stop periodic transmission of position Stop automatic transmission of position.
Query position Consults the current position of the mobile unit.
LOGS
Since the system records resource positions, the routes covered by mobile units can be
displayed on the map.
To do this, the units that are to be represented and the time interval of the route to be
simulated have to be specified.
Once these parameters have been specified, the system simulates the route to give the
operator an idea of the routes taken by the units.
15
Also, the historical data in the GIS Database can be used and consolidated from the
case file management application, if necessary.
MESSAGING AND NOTIFICATION SYSTEM
The system is designed to provide a unified messaging service that can effectively
replace the radio-frequency systems that Cintra Parking/Dornier has used up to this point.
The system must be two-way, between tow yards, the police, and the tow trucks. In the
case of the current proposal, the existing Mobility Controlador and Tow Truck Mobility will
be replaced by a single unified messaging application that is described in detail in
section “7. Appendix. Central Messaging Application.”.
The messaging system includes:
• Broadcasting emergency messages (from the tow yard to tow-truck personnel).
• Broadcast messages from the control station to a group or all of the tow-truck
operators.
• Messages from a tow-truck operator to the central station.
• Emergency message - in this case, a key will be activated in the mobile terminal
that just needs to be pressed to activate the transmission to the control center,
and the corresponding actions will be take from there.
• It must allow export with predefined options to an Access or Excel database.
• This must be a tool that can be easily integrated with other existing applications.
The server at the tow yard must have a messaging application that can be integrated
with the tow-truck management system. This web application must be easy to use to
add new coded messages and to send these messages to tow-truck operators, a group
of them, or all of them. It will also be the tool used to maintain the resident data catalogs
on the onboard equipment.
16
The possibility of sending uncoded information must always exist, especially the possibility
of incorporating voice communication in a closed user group (may simply be GSM
mobile telephony).
17
DETAILED DESCRIPTION OF THE TOW TRUCK MOBILITY SYSTEM
INTRODUCTION
The goal of the On-board Mobility System (SOGG) consists of automating the
management of case files associated with the removal of vehicles by the towing service.
The removal of a vehicle requires the authorization of a police officer. The main
contribution of this system to the process consists of allowing police officers to authorize
the removal of a vehicle without requiring their presence at the location of the infraction,
minimizing the procedure time and increasing the service to remove vehicles from public
roadways. The diagram below describes the procedure for removing vehicles.
BASIC SOGG FUNCTIONS
Pocket SOGG
Editing tow-truck calls (including photographs).
Implementation of the part of the communications protocol needed for Pocket SOGG
and the SOGG server to maintain a dialog and manage the case files for the removal of
vehicles, from the time they are created until they are closed, allowing navigation
through all of the possible case file statuses.
• Preparing and printing tow truck reports (including photographs).
• Writing messages.
• Sending and receiving messages.
• Collecting infraction payments.
• Administration/configuration tasks:
• Tow-truck driver.
• Battery status.
• IP Address and GPRS server port.
• GIS service configuration.
• Bluetooth configuration.
• Terminal identifier.
• Port for communication with the printer.
• Shift management.
18
SOGG Server
• Management of client connections.
• Implementation of the part of the communications protocol needed to be able
to maintain a dialog with clients (Pocket SOGG).
• Management of a log to record events that take place.
Web page
• Generation of a new case file.
• Tracking case files. Modification of case file status:
• Authorize / Do not authorize vehicle removal.
• Assign a case file to a tow truck.
• Cancel case file.
• Cancel case file (case file canceled by the police).
• Request additional information.
• Consult case files.
• Terminal administration:
o Add terminals.
o Delete terminals.
o Manage destinations
o Create destination.
o Delete destination.
o Add terminals to a destination.
o Delete terminals from a destination.
o Web user administration.
o Tow-truck location system (GIS).
o Incorporation of messaging module between central office and tow
truck.
o Management and configuration of the entire system.
o Catalog update and maintenance.
o Management and maintenance of catalogs for the Pocket SOGG system
by synchronizing information.
19
COMMUNICATIONS PROTOCOL
Communication between the devices (the PDAs) and the message server will be done
via GPRS, through the access points to the service in the transport layer (sockets). The
diagram below shows the applicable protocol layers:
The dialog that will be exchanged between the clients and the server when processing a
case file will be implemented in the application level frames (ADUs).
MANAGEMENT OF CASE FILE CODES
Case files are uniquely identified in the system by the case-file code. The following
section describes how these codes are managed and how a case file is associated with
a tow-truck call generated on the PDA:
All case-file codes are generated on the server.
There are two possible situations in the system:
A.- The process is initiated on the server. The police officer receives a tow-truck call
through a channel other than the tow-truck driver (phone call, ORA, etc.) and generates
a new case file. This case file is assigned to a tow truck. The terminal associated with the
truck in question is sent a service request that includes the case file code. This way, both
the client and the server now have the case file code.
20
A.- The process is initiated from the tow truck. The tow-truck operator locates an
infraction, generates a report, and sends it to the server. A tow-truck call code is sent
along with this report. This code is unique in the system (the terminal ID forms part of the
code). The server receives the report from the tow-truck driver, generates a case file, and
associates the tow-truck call code with the new case file that has been generated. The
authorization/non-authorization response that the server sends to the client includes both
the case-file code as well as the tow-truck call code, so that the client can associate the
case-file code with the tow-truck call that it has generated. The process is initiated on
the server
POCKET SOGG
INTRODUCTION
Pocket SOGG is the client part of the On-board Mobility System. It has the following
functions:
• Editing tow-truck calls (including photographs).
• Implementation of the part of the communications protocol needed for Pocket
SOGG and the SOGG server to maintain a dialog and manage the case files for
the removal of vehicles, from the time they are created until they are closed,
allowing navigation through all of the possible case file statuses.
• Preparing and printing tow truck reports (including photographs).
• Writing messages.
• Sending and receiving messages.
• Collecting infraction payments.
• Administration/configuration tasks:
• Tow-truck driver.
• Battery status.
• IP Address and GPRS server port.
• GIS service configuration.
• Bluetooth configuration.
• Terminal identifier.
• Port for communication with the printer.
• Shift management (shift start and end).
21
To store persistent information, Pocket SOGG uses a database and files.
Files. Catalog information is stored in files; in other words, the data that is used to prepare
tow-truck calls, tow-truck reports, and messages.
Database. The database is used to store the messages, tow-truck calls, and application
level data units.
SHIFT START
When tow-truck operators start their shifts, the following information must be entered:
Tow-truck operator information:
• Tow-truck operator case file (can be selected from a pre-defined list).
• Password.
Tow truck information:
• Tow-truck license plate number (can be selected from a predefined list).
• Service start time, saved in the system.
• Entry Km.
• Diesel tank level.
• Tow-truck status (can be selected from a predefined list).
22
23
MAIN PAGE
GENERATING A TOW-TRUCK CALL
When generating a tow-truck call, the following information must be entered:
24
Vehicle information:
• License plate mask.
• License plate.
• Vehicle type.
• Make.
• Model.
• Color.
25
Location:
• Street.
• Number.
• Door type.
• Specific location (next to, in front of).
26
Article.
Photographs.
27
Comments.
The tow-truck call is generated whenever the tow-truck driver initiates the process.
EDITING A TOW-TRUCK CALL
Tow-truck reports can also be edited. The tow-truck report consists of the same
information as a tow-truck call. The difference between the two lies in the following
aspects:
When a tow-truck call is edited, the process is started by the tow-truck operator and the
information that makes up the notification must be entered.
The tow-truck report is edited when:
• The server initiates the process and requests that the tow-truck operator send it a
report (normally photographs).
• The server requests additional information.
• When a tow-truck report is edited, much of the report data has already been
edited and normally more information will have to be added (comments,
photos), or existing information will have to be corrected.
28
CALLS ON HOLD
From this form, the tow-truck operator can accept or reject service requests sent by the
server. At a single moment, there can only be one service request with “accepted”
status. Once a service request has been accepted, the case file associated with that
request switches to the current notification.
The main screen will show that there is a notification on hold with an exclamation point,
and beep will sound when it arrives.
When notifications on hold are clicked, a list will appear with all of the notifications
assigned from that central office to this Terminal or tow truck. Click on details to expand
the information for each service
29
The tow-truck operator may accept or reject the service. If the service is rejected, the
tow-truck operator must explain the reason:
When OK is clicked, the service will disappear from the table of notifications on hold or
pending, and the central application will display it as “service pending report”. The
mobile terminal will display this information.
30
CURRENT CALL
Only one case file (service) can be handled at a time from Pocket SOGG; in other words,
once the service associated with a case file has been started, another service cannot be
carried out until the service that is underway has been completed. The current case file
can be managed from this formula.
When the tow truck reaches the location of the incident, it must inform the police of any
modifications to the case file that are detected and assign the necessary photographs.
When the entire report has been filled out, the following may be done:
Process the notification: send it to the central tow-truck office for authorization.
Discard it or reject it specifying the reason.
31
If it is sent to the police, its status will change to Pending Authorization.
32
VEHICLE IN TOW YARD
This form is used to indicate that the vehicle has been taken to the tow yard. The tow
yard to which the vehicle has been taken has to be entered in this form.
ASSISTANTS
This form is used to carry out different management / administration tasks in the
application.
33
34
MESSAGING
Messages will be sent to the central office with coded fields and free fields. It also shows
Sent messages, Received and Read messages, and Received and unread messages.
35
END OF SHIFT
When completing a shift, the tow-truck operator must enter the following information:
• Tow-truck operator case file (can be selected from a pre-defined list).
• Password.
• End of shift time.
• Completion km.
• Diesel tank level.
• Tow-truck status.
• Comments.
36
SOGG SERVER
FUNCTIONAL DESCRIPTION
The server is responsible for managing multiple client connections (Pocket SOGG) and
exchanging information with them.
The GPRS server functions are:
Sending messages.
Receiving messages.
Exchanging Application level Data Units (ADUs) with clients. In this ADU exchange, a
dialog is established between the server and the clients that allows navigation through
the case-file status diagram, from when they are created until they reach their final
status.
37
Log file management. The server keeps a log file where it records the different events
that take place in the system.
SERVER CONFIGURATION
The parameters that can be configured on the GPRS server are:
TCP port that is used to communicate with clients (Pocket SOGG).
Database.
Database user and password.
Protocol timeouts.
FUNCTIONALITY
The following actions can be carried out through the Web application:
• Generate service case files.
• Modify case-file status.
• Consult case files, search case files.
• Administer terminals.
• Manage destinations.
• Administer website users.
STARTING THE APPLICATION
This is a web application that is accessed using a web browser, but validation of the user
and password is required, so permissions can be specified so that a particular agent may
be allowed to validate and/or authorize case files, while another user can only analyze
case files.
38
The access screen looks like this:
39
The main application screen looks like this:
The options and sub-options are:
• Services.
• Service Reports. • Management.
• Export. • Query.
• Tow-truck operators.
• Officers
• Terminals.
Messaging.
• Drafts. • Received.
• Sent. • Query.
GIS.
• Position.
• Route.
• Geocells.
Administration.
• Users. • Groups.
• Terminals. • Logs.
40
• Refueling.
• Tow-truck reports
• Exp. Numbers
• Digital signature.
• Bulletin Prefix.
• Reinstall PDA.
Catalogs.
• Makes
• Models.
• Vehicle Type.
• Streets.
• Colors.
• Articles.
• Tow trucks.
• Tow-truck operators.
• License plates.
• Entries.
• Tow Yards.
• Ret. Reasons.
• Codes.
• Recipients.
Synchronization.
• Synchronize.
• Downloads.
• Versions.
41
Each one of the points will be analyzed below.
SERVICES
This is the part of the application where service case files are created and authorized.
These are the basic screens for daily work.
MANAGEMENT
The main screen is divided into two parts, the top, where tow-truck calls are shown, with
their statuses, and the lower section, which shows the terminals (tow trucks) that are
currently free.
ADDING A SERVICE CASE FILE
Here, a distinction must be made between the addition of a new removal or boot, and a
movement or other service.
42
For a new vehicle removal or boot attachment, the data input screen looks like this:
To request another service:
43
For example, movements:
MODIFYING A SERVICE CASE FILE
Once a case file has been created accessing the information from the MANAGEMENT
screen, its status can be modified carrying out the following actions:
• Assigning the case file to a tow truck.
• Authorizing / not authorizing removal of the vehicle.
• Annulling the case file.
• Canceling the case file.
• Requesting additional information.
44
45
CONSULT CASE FILES
This form is used to search and consult case files using different criteria and export all of
the results to excel.
The log can be selected to indicate the evolution of the case file:
46
or consult the details of the case file with photographs and additional reports:
TOW-TRUCK OPERATORS
This option displays information on the assigned tow-truck personnel:
47
As well as a record/details of their activity:
OFFICERS
This screen displays information on the police officers:
48
As well as additional information:
SERVICE REPORTS
This tool allows the possibility of querying the different services carried out and displaying
the report generated under the format premises for quality control.
49
Accessing the report:
To modify quality forms:
EXPORT
Tools that are used to create a file to export the infraction reports generated by the Tow-
truck Service to the Local Police infraction reporting system.
50
TERMINALS
This option verifies which terminals are operational and which tow-truck are assigned.
51
MESSAGING
This module is used to send messages between the mobile units and the server
application users.
Drafts
This option displays the messages left as drafts:
And new messages are generated:
Messages can be sent to a Terminal, a group of Terminals, or the entire fleet, depending
on the groups that have been created previously. Messages can be stored for sending
later.
52
Sent
This option displays the messages that have been sent from the central application. They
can be opened to enter details and closed to indicate that the message has already
been processed.
Received
Displays the messages received on the server, and as with the previous option, the
message can be opened to view details or it can be closed.
53
Query
This module is only for consultation, and obviously is only used to select messages that
fulfill a particular requirement.
All of the application’s query options include the possibility of exporting the query results
to an Excel spreadsheet.
GIS
This module is used to display the status and location of the service’s different tow trucks.
Position
Makes it possible to view a location map, and the latest position for a specific tow truck.
54
Route
Displays the route taken by a vehicle during a specified period of time.
55
Geocells
With the Geocells option, it is possible to mark a geographical zone so that at the time
when a vehicle passes, enters, or exits the geographical border, an alarm or event is
generated in the system.
56
57
ADMINISTRATION
This tab includes the basic administration options of the elements connected with the
system.
Users
From the “Users” menu, website users can be created, modified, or deleted. Created
users may be assigned one of two roles:
Standard. These users do not have access to the “Administration” menu.
Administrator. These have access to the entire website.
58
Terminals
The server database will include a table where the identifiers of the different terminals
that make up the system will be stored. This form can be used to do the following:
• Create terminals.
• Edit terminals.
• Delete terminals.
59
Groups
Messages will be sent to destinations or groups from the web application. A destination
consists of one or more terminals. This form can be used to do the following:
• Create destinations.
• Delete destinations.
• Associate a Terminal with a destination.
• Delete a Terminal from a destination.
60
61
CATALOGS
This option or menu allows the application’s master tables or catalogs to be updated:
SYNCHRONIZATION
This is the option that allows all of the catalog modifications to be sent to the mobile
terminals, without requiring them to come to the central office.
62
63
Appendix 12 – Central Messaging Application
Summary:
Introduction
PDA-based Messaging Module
Central Unified Messaging Server
1
INTRODUCTION
Thanks to wireless data communications and the Mobility system, conventional radio-
communications elements such as walkie-talkies can be replaced by integrated
messaging that is the same for the Regulated Parking and Towing Services.
The basic elements that make up this system or application are:
• Sending messages from the central station to one or more terminals.
• Sent Messages.
• Received Messages.
• Filters.
• Destinations.
• Administration.
The unified messaging system is divided into two parts:
1. System installed on the PDA.
2. Web system that replaces the central radio transmitter.
2
PDA-BASED MESSAGING MODULE.
The MOBILITY System includes the possibility of a specific messaging module so that
controllers do not have to carry walkie-talkies.
The purpose of this module is to establish continuous two-way communication
between controllers/tow-truck operators and the central station operators.
The messaging system includes:
• Broadcasting of emergency messages (from the Central station to Controllers).
• Broadcast messages from the control station to a group or all of the controllers.
• Messages from a controller to the Central station.
• It must allow export with predefined options to Access databases, Excel, etc.
• This must be a tool that can be easily integrated with other existing
applications, such as the tow-truck call application.
According to experience in similar centers, more than 95% of the estimated
transmissions are encoded. On the other hand, un-encoded information transmission,
and even the incorporation of voice in closed user groups must always exist.
The types of messages sent can be grouped under three concepts:
Dispenser maintenance. A notification is sent that indicates the dispenser and the
type of malfunction. These messages can be totally transferred to the proposed
system because the use of voice is not required.
Tow-truck notifications. This situation is very similar to the previous one. The location
and identification of the vehicle, the infraction being committed, and the level of
urgency are sent to the tow truck.
Service. These are open-format messages that in theory are more difficult to encode
and replace with voiceless messages. The calls normally come from the local
3
police or an ambulance, or another type of emergency, location of people in
searches, etc.
Regulated Spaces: Sending Messages with information regarding parking space
occupancy, either by construction disposal containers, roadwork, etc.
The following section shows the screens, mainly for the controller system, but the tow-
truck screens are practically identical.
SENDING MESSAGES FROM A TERMINAL TO THE CENTRAL STATION.
To send a message, select the MESSAGES option on the terminal’s main screen.
The basic or main message options screen will then appear:
Dispensers, information on dispenser malfunctions or problems.
Tow trucks, tow-truck requests.
Service, notifications from the Regulated Parking Service or for citizen assistance.
4
Regulated Parking Spaces, spaces in which vehicles cannot park due to different
incidents (waste containers, roadwork, etc.).
Sent, messages sent from the Terminal to the Central station.
Read, messages received from the Central station that have already been read by
the controller.
Unread, messages received from the central station but not read by the controller.
5
6
CENTRAL UNIFIED MESSAGING SERVER
The following points show the different screens that make up the unified messaging
web server, which is the system that can replace the transmitter.
APPLICATION ACCESS CONTROL
The application is accessed using a web browser (Internet Explorer) through an intranet
address (the first security filter - browsing is not from the internet, but rather is an internal
application based on an Intranet).
The user is first asked to enter a user name and password that allows access to the
functional part of the system.
Once the username and password have been validated, the application’s main
screen will be displayed.
The following sections analyze option by option the basic possibilities offered in this
system.
SEND MESSAGES.
When a messages needs to be sent from the Central station to a controller, group of
controllers, or all of the controllers, select or click “Send Messages” on the horizontal
menu bar.
Then click the “New Message” button, which will open the basic work window for
creating a new message.
The three options to be selected will be:
• Search for destination.
• Destination, here you can select a terminal or controller, or a group of them.
7
• Priority.
• Incident Type.
The screenshots below show the initial value of the drop-down menus (this value can
be configured).
8
Then write the message to be sent, for example:
Once the message has been written, you can use the buttons on the right side of the
screen to carry out the following actions:
• Send immediately.
• Save message to send it at a later time.
• Delete message.
9
SENT MESSAGES.
The person responsible for sending and receiving messages can check the sent message
log and see the status of the messages at any time.
The log is displayed on the screen and can be filtered by message type.
Double-click on the yellow folder icon next to a particular message to expand the
information.
10
When a message is marked as completed, it will disappear from the basic work
screen, but not from the Database.
RECEIVED MESSAGES.
11
Functioning is similar to the “Sent Messages” option.
The initial screen shows the list of all of the received and uncompleted messages. This
report or list can be filtered by message type.
Unread messages are displayed in RED, messages that have been read are in GREEN,
and completed messages are not shown in this report, even though they have not
been removed from the Database.
To expand the information on a message, click the yellow folder icon next to the
message.
A screen will open with 100% of the details of the original content of the message.
12
When incidents connected to a message are closed from the central station and the
COMPLETED option is clicked, this message will disappear from the screen, but will
remain in the Database.
FILTERS.
This is the option to provide a tool to give greater analytical capabilities. Using a series of
filters, select the information to be analyzed. This information can be exported to Excel.
The following filters can be applied:
• Date.
• Message Type.
• Source Device (Controller or group of Controllers).
• Text (search for a particular license plate number, street, etc.).
DESTINATIONS.
This is basically an administration option. This is where groups of terminals (or controllers)
are created, modified, and deleted.
The following screenshots show the procedure for creating, modifying, or deleting
groups of terminals or controllers.
13
ADMINISTRATION.
tion whose purpose is to maintain web application users
nd manage catalog files.
).
low.
t of catalog files allows updated catalog files to be sent to a user or
group of users.
This is an administrative op
a
The basic user maintenance options are:
• Create a new user and assign a profile.
• Manage and update catalogs (master tables
The screens connected with this option are shown be
• Modify a user.
• Delete a user.
The managemen
a
14
The screens connected with this option are shown below.
15
16
Appendix 13 – Information System-Integrated Control Panel
Summary:
Introduction to the Solution
Description of the Analysis Tool
Description of the Project “Integrated control panel for the Regulated
Parking Service”
1
INTRODUCTION TO THE SOLUTION
The solution proposed in this chapter is the top layer of the SENA platform and the
possible applications derived from it.
This is the stage or phase in which the data from the different sources is consolidated and
unified into a single database (Business Intelligence).
Once all of the data has been standardized, the visual design of the web pages and the
ratios to be analyzed is done.
The figure below provides a general overview with a repository or data warehouse (SENA
database) and an EIS or control panel that is the top layer or analysis system of the SENA
System.
The power of this tool is based mainly on its capacity to analyze data and its powerful
graphic interface.
The parameters initially proposed for analysis are:
Infractions by articles.
Infraction reports by street or zone.
Infraction by time frequency.
Payment Collection.
% Occupancy.
% Annulments.
Rotation Index.
Evolution of unusable spaces and rotation.
Evolution of unusable spaces and infractions.
Tow-truck removal services.
Average removal service times.
Etc.
2
The screenshots shown below are included as an example, since the system’s
parameters have to be configured according to the City Hall’s needs.
Occupancy by Zone Information Screen
3
Screen for weekly payment collection evolution by dispenser or group
Operations / Infractions / Annulments screen
4
Density of infractions per zone screen
5
DESCRIPTION OF THE ANALYSIS TOOL
One of the current challenges for Regulated Parking Management is to “reveal” the
information existing in operational subsystems:
• Infractions.
• Parking meters.
• Tow trucks.
• Etc.
Cintra Parking/Dornier proposes the use of an Analysis Tool based on Business Intelligence
technology that will allow the City Hall to measure, monitor, and track performance of
key processes.
A highly interactive web interface based on simple mouse clicks will be used, giving users
instant access to top-level metrics, registering quality and precision data, ultimately
revealing perspectives of the new operations, since they ware invisible because they
were hidden in different sub-systems.
Why is this type of tool needed?
For example, what relationship is there between the payment collection of one group of
parking meters and the infractions given in its area of influence over time.
These types of ratios are very easy to generate in a BI tool and much more complex in a
conventional programming environment. Also, because you can only have the data if it
can be extracted with an endless variety of graphs and even evolutions with trend
formulas and representations on graphs.
6
For some time, Cintra Parking/Dornier has been implementing BI tools for its own
management and it understands that they are the best systems for analyzing the data
for a business:
• Quickly.
• Flexibly.
• Risk free, with coherent data.
• Risk free, access control.
• Integrated: powerful analysis, visually sophisticated applications, and simple
reports, all in a single architecture.
• Powerful, response time practically instant, even with massive volumes of data.
• Etc.
The proposed analysis system manages the information similar to the way a human brain
does. As in the case of our own brains, the System gradually makes associative
connections in the information that it is processing. The user - and not the database -
decides which questions are going to be asked. Simply click on the subject for which you
would like to see more information.
Conventional data search systems often require a top to bottom structure in queries,
while the proposed system can start with any part of the information, regardless of its
location in the data structure.
In conventional systems, data recovery is usually quite a complex task that requires
extensive knowledge of the database structure and the query language syntax. Users
are often limited by pre-defined search routines. The Analysis System revolutionizes this
process, making it possible to freely select from the data displayed on the screen with a
simple mouse click.
A system based on BI technology helps give a global, unified, and coherent view of the
information contained in different database - its own or those of another person, remote
or local. Any virtual database can be used with the Analysis System.
7
What is going to be obtained?
• Create a flexible interface for end users and a data repository.
• Quickly give a real impression of the relationships between the
data.
• Prepare presentations based on data.
What is the proposed structure?
The Web IIS server platform from Microsoft® Windows® is used to provide the applications
to end users over corporate intranets, extranets, and the internet. End users access the
applications using their regular browsers.
The key functions include:
• Web-based access to analysis applications for the entire organization.
• Centralized control of applications, data reloading, accesses, and security.
• Quick implementation, configuration, and startup.
• Scalable and adaptable architecture.
• High-profitability maintenance and administration.
The analysis databases are located on a server on which the web server with the
dynamic query application is also running.
Loading from transaction or operational databases is done with fast incremental loading
to have the information practically online.
The web-application or client allows users to do the following:
• Navigate through the different pre-set ratios and dimensions.
• Export information to Excel.
• Copy graphs or data to other documents.
8
DESCRIPTION OF THE PROJECT “INTEGRATED CONTROL PANEL
FOR THE REGULATED PARKING SERVICE”
Due to the close relationship that must be maintained between the City Hall and Cintra
Parking / Dornier to implement a tool of this type, this section has been included to
describe how the project will be developed. This point describes all of the profiles
involved in the definition and commissioning of the integrated control panel. The
following presents the focus for the implementation of the key tool in the overall
management of the Regulated Parking Service.
Cintra Parking / Dornier has experience in the implementation of tools of this type, but
this implementation is not a standard product, but rather the result of close collaboration
between Cintra Parking / Dornier and the City Hall.
The following will be developed:
• Project objectives and requirements.
• Execution methodology.
• Project management and organization.
Project objectives and requirements
The execution of a project with these characteristics will allow the City Hall of Pozuelo de
Alarcón to achieve the following goals:
• Have “common information repository” (Datawarehouse) aimed at the
management of the Regulated Parking Service, in turn defining a new
management model according to the needs and expectations of the people in
the City Hall responsible for the service.
• Provide the City Hall with a COMMON information model OPTIMIZED for its
operations with:
o EIS tools (integrated control panel).
9
o Other corporate applications/systems in the City Hall.
• Provide a series of methodologies and tools to serve as a base for the City Hall to
undertake future projects in this area.
Execution methodology
The project’s focus is based on methodologies that are defined individually according to
our extensive experience with this type of project.
Project planning and organization
The planning and organization of the Projects will be done as a preliminary phase before
the project is begun. The project structure will be defined in this phase:
Introduction of the work team.
Review of the scope, objectives, and requirements.
Internal communication for the project to be carried out for those affected and future
users.
Identification of the target areas of the study, of future users of the model once
implemented, and the intermediaries.
Definition of the detailed work program to execute the project (calendar of interviews to
be carried out, delivery dates for results, execution of controls, etc.).
Review of the existing documentation that could be used as support or a base for
carrying out this project.
This phase will generate a clear idea of the scope, a detailed project plan, and the
preparation of the documents required to undertake the following phases.
10
Analysis
The main goal of this analysis phase is to define the new information model, so an
exhaustive review will be made of the needs to be covered in the control panel,
analyzing all of the documentation and interviewing the key users.
Each manager, depending on their level and area of responsibility, needs not only a set
of specific information (indicator set) but also needs to receive this information with the
level of detail (aggregation) and frequency that is most operative.
In this task, the users of the Control Panels will be identified, along with the indicators that
each one will used to control and monitor the corresponding activity.
The Control Panel must establish three basic components:
• Information to be received by the manager (indicator group).
• Aggregation level by indicator.
• Frequency that received information is refreshed.
All of the information supplied to the Control Panels would preferably be obtained
practically from the same organization, so that obtaining and updating information is
easy and effective. We have currently identified the following data sources:
• Parking meter control system.
• Infraction processing system.
• Maintenance system for the System elements.
The source of the information will have to be identified to carry out this phase.
By analyzing the operational systems and holding work meetings with users, the following
goals will be achieved:
• Determination of the management subject areas.
11
• Comparison with the company’s strategic goals.
• Data Model.
• Criteria for consolidating the information.
• Preliminary design acceptance tests.
• Identification of data sources.
The following will have been obtained after the completion of this analysis phase:
• Data Model.
• Detailed Analysis of the new System.
Design
The goal of this phase is on one hand, the physical design of the Datawarehouse, in
order to have an environment where the data that is required in the management
activities can be easily obtained. The extraction processes will also be designed
(understood to be the extraction, filtering, integration, conversion, etc.) that will generate
the data to supply the Datawarehouse.
The carry out the complete design, the decision must be made in regard to the tool on
which the solution will be built. Once the different possibilities have been analyzed, our
first option is to use QlickView. In any case, regarding the project methodology, the
activities to be carried out will be independent from the tool.
The goals of this phase are:
• Define the management indicators, reports, lists, etc., identifying the sources of
information that will supply them, their frequency and refresh, as well as the data
formats and processing required.
• Design the control panels. A substantial part of the Information Model will contain
the indicators that each one of the managers uses for the management of their
corresponding activities. The following will be specified for each user that is
identified:
12
• Information to be received by each manager (group of indicators and grouping
into functional areas).
• Aggregation level by indicator.
• Frequency that received information is refreshed.
• Establishment of concepts, criteria, and metrics for tracking objectives.
• Design the extraction, transformation (homogenization) and loading of the information obtained.
• Datawarehouse design.
Construction and implementation
The result of this phase will be the construction of all of the components analyzed and
designed in the previous phases and implement them in the Production environment,
both the Datawarehouse as well as the QlikView document.
Objectives:
• Preparation of the technical infrastructure.
• Build the Datawarehouse.
• Build the loading processes to provide the management data and feed the DW.
• Data extraction and loading.
• QlikView configuration.
• User training and manuals.
Results:
• DatawareHouse and Qlikview in production.
• Operating Manual.
13
• User Manual and trained users.
Project management and coordination
In a project as important as this one, the procedures and controls required to ensure the
successful development of the project must be established. Applying this principle,
Project Management and Coordination covers all of the tasks related to the
management functions (supervision, control, and tracking) and project administration. As
an example, some of the more important tasks could include:
• Project planning, specifying phases, activities, resources, and results.
• Assessment of the resources required, that make it possible to monitor the
resources applied and their cost, based on information that is collected
periodically.
• Supervision and coordination of the work team.
• Control of completed work and identification of conflict points.
• Control of project efforts / costs.
• Control of project efforts / costs.
• Holding meetings at the different Management levels (supervision, control, and
tracking).
• Periodic status reports, in which the Project Manager informs the operations
committee on the status and progress of the project.
Minutes of meetings, both internal project meetings as well as meeting in which
personnel from the City Hall participate.
Inspections of finished products to guarantee quality, integrity, and fulfillment of the
project objectives and requirements.
Control of the formulated requirements and specifications. Given the planning
characteristics of this project, adequate flexibility in the preparation and modification of
requirements and specifications, as well as sufficient control of them would be helpful.
14
The specific definitive management and coordination procedures to be applied during
the project will be established jointly with the Project Supervisor designated by the City
Hall at the start of the project.
Project management and organization
A project of these characteristics requires an organization with responsibilities shared
between the City Hall and CINTRA PARKING / DORNIER and that is oriented toward
OPERABILITY in DECISION MAKING.
The project goes beyond the sole responsibility of the City Hall’s Systems Department and
consequently must be considered in the organization itself as a project that will require
the coordination between departments and a SINGLE RESPONSIBILITY in terms of the
necessary validations and decisions.
Project control and tracking procedures
The work tea proposed by Cintra Parking / Dornier will be managed by a project
supervisor (Project Manager), who will coordinate the execution of all of the tasks
involved in the project, acting as a permanent intermediary with the client.
The control elements to guarantee fulfillment of the specified objectives, in terms of both
deadlines and quality, are the following:
• Project Planning, which will describe the phases, activities, resources, and results.
• Assessment of the resources required, which will make it possible to monitor the
resources applied and their cost, based on information that is collected
periodically.
• Status and progress reports, with a frequency to be determined, in which Cintra
Parking / Dornier’s Project Manager will report on the project’s status and
progress.
• Periodic tracking meetings with the Project Management, to supervise and
coordinate the project.
15
• Minutes of meetings, both internal project meetings as well as among the
personnel participating in the project.
• Inspections of finished products to guarantee quality, integrity, and fulfillment of
the project objectives and requirements.
This control will be established on the documents that, for the methodologies to be
applied, are considered to form the basis of the project, and any changes to them must
be approved by the Project Management designated by the City Hall.
However, the client will be allowed to request any other additional document at any
time to verify any of the data offered by Cintra Parking / Dornier.
We propose that this project tracking and control be done using mainly the following
elements:
• Project Management
• Executive Committee
• Tracking Committee
• Quality Control
• Progress Reports
Project Management
Project Management involves the planning, budgeting, tracking, and control based on
an established work methodology. The following measures will be adopted in carrying
out Project Management:
• The methodology (phases, activities, and tasks) to be used in the project will
be incorporated.
• The establishment of an organizational figure to provide support to the work
team for the maintenance and management of project control will be
considered.
16
• The project management tool will be kept up to date, which will make it
possible to detect any deviations, and also to track and monitor the
project.
The tasks that allow a project control tool to be created are:
• Define the tasks to be carried out and the dependencies between them.
• Assign resources to each task.
• Estimate project times during the planning phase.
• Collect actual times dedicated in hours and with dates.
• Compare completed actions with the plans and obtain deviations (in
allocation and deadlines).
The benefits to using this include:
• Adequate organization and project management.
• Risk management, by better following the progress of the work and identifying
any variations with regard to what was programmed in the plans.
• Provides better assessment of the development by comparing the real efforts
versus the estimates in the plans.
• Allows the pertinent corrective measures to be adopted.
Executive Committee
In order to guarantee tracking of the project’s development, an adequate and
permanent level of communication must be established among the project participants.
We propose that these actions be carried out by forming a Project Management
Committee.
17
The functions of this Committee will be:
• To define the control and supervision procedures for the work carried out as part
of the project.
• Approve the work completed in each phase of the project, analyzing the
deviations from the plans, the quality of the actions, and their conformity with the
requests made.
• Study and approve future expansions and improvements to the object of the
actions of this project.
• Supervise and approve the profile of the people assigned by Cintra Parking /
Dornier to each job position in the project.
• Approve the final product of the project.
• It will be an informational organ in case of requests from other areas or institutions.
Initially, the Executive Committee is planned to consist of:
• Project Manager for the City Hall.
• Project Supervisor from the City Hall.
• Project Manager from Cintra Parking / Dornier.
• Project Head for Cintra Parking / Dornier.
Other people deemed necessary by the Project Manager for the City Hall will be added
to this committee, which will be formed at the start of the project.
Tracking Committee
In order to guarantee tracking of the project’s development, an adequate and
permanent level of communication must be established among the project participants.
We propose that these actions be carried out by forming a Project Tracking and Control
Committee. This Committee will represent the maximum technical authority of Cintra
Parking / Dornier.
18
The functions of this Committee will be:
• Constant awareness of the project’s progress.
• Through periodic meetings, it will monitor the progress and development of the
project.
• Technical review and approval of completed work.
• Approve the work plans.
• Approve the resulting products after each one of the project phases.
• If necessary, it will evaluate and approve possible modifications that may be
made in the scope, deadlines, and requirements.
• It will speed decisions that due to their nature may be beyond the capabilities of
the work team.
Initially, the Tracking Committee is planned to consist of:
• Project Supervisor from the City Hall.
• Key users from the City Hall (depending on the sub-project).
• Project Head for Cintra Parking / Dornier.
• Consultants responsible for “module”.
Any people that the Committee itself deems necessary may be added to the
Committee.
Quality Control
In a project as important as this one, the necessary quality controls must be established
to guarantee successful results. We recommend that these controls be applied from a
dual perspective:
• Control of the quality of the process and development of collaboration on the
project.
19
• Control of the quality applied to the end or partial project results.
To cover the different aspects of Quality Control, different formulas and procedures will
be considered and specified at the start of the project. Some of the options that we
recommend for consideration in the Quality Management of this project are:
Establish intermediate products that are formally received and accepted by the
Executive Committee. The acceptance criteria (and the definition of target parameters)
are defined and specified jointly at the start of the project.
The Quality Control Function for Cintra Parking / Dornier will mainly be carried out by the
Project Director for Cintra Parking / Dornier, who will have the following functions:
Verify that the executed work conforms to the objectives and scope of the professional
collaboration, and to the client’s expectations for the project.
Guarantee the maximum level of quality for the project and the products generated
during it, in accordance with the established standards.
Evaluate the progress of the project in accordance with the work program and
calendar.
Also, given the importance of the project, Cintra Parking / Dornier will include the figure
of a Quality Supervisor in the team, in order to guarantee final satisfaction with the results
obtained and to ensure that the client’s expectations are fulfilled. This Quality Supervisor
will therefore be responsible for verifying the quality of the methods and results of the
project, and his main functions will be those arising in the task of supporting the Project
Director.
Progress Reports
In order to report on the project’s development, progress reports, containing the
following points, among others, will be prepared, with a frequency to be determined:
• Project status.
• Main results obtained in the period.
• Incidents occurring during the period of time analyzed.
20
21
• Changes to the initial plans (dates, people, tasks, etc.).
• Results to be obtained in the next period.
• Actions/decisions to be made by the Executive Committee.
• Actions/decisions to be made by the Tracking Committee.
• Summary of the project’s progress.
These reports will be sent to all of the members of the Executive Committee and the
Tracking Committee, and will serve as the basis for their meetings.
Appendix 14 – Occupancy Status Information System
Summary:
Introduction
Web-based Information
Information model on the SENA platform
1
INTRODUCTION
CINTRA PARKING / DORNIER. considers it beneficial to offer the possibility, to both the City
Hall and to citizens, of providing real-time information on the approximate occupancy
status of the regulated public on-street parking zone. For several months, CINTRA
PARKING / DORNIER. has been defining the minimum needs that a system of this type
must fulfill and analyzing the market options, and has reached the conclusion that
though the technology is ready to cover the needs, the market does not offer solid and
integrated solutions.
Consequently, DORNIER, S.A. has specially designed and developed a solution called
FREE ORA, which basically provides:
Information on occupation trends on public roadways.
It is important to note, as stated in later descriptions, that the system proposed by CINTRA
PARKING / DORNIER. takes information from more than one source, which significantly
reduces calculation errors.
2
WEB-BASED INFORMATION
The first step is to provide information in real time on the trends in occupation of public
on-street parking through a web-based application. The information that is going to be
processed, consolidated, and analyzed to determine the percentage of occupied or
free spaces is:
• Tickets sold by the parking meters in the last unit of time. This parameter is used to
determine the real paying occupation. Information supplied by the Parkeon,
Parkfolio Neo application.
• Infractions given for not acquiring a ticket, with this parameter taken into
account the vehicles that occupy a parking spot, even though they fail to
comply with municipal ordinances. Information supplied by DORNIER’s infraction
system, Pocket WinID.
• Resident vehicles, if the centralized resident application is operational, data will
be available on the resident vehicles parked at the time of the analysis.
Information supplied by the DORNIER residents application.
The calculation is done on the BackOffice/SENA platform and is then published on the
website (intranet or internet).
Calculation of total parked vehicles:
Total= *Pay vehicles + *Infraction_vehicles+ 2* Resident_Vehicles
Correction parameter based on the analysis of the logs for the vehicles that
correctly generated tickets
Correction parameter based on the analysis of logs for infraction vehicles
Correction parameter based on the analysis of logs for resident vehicles that are
occupying a green space 2
The three correction parameters are based on the analysis of logs and the application of
mathematical trend-analysis formulas, which will be calculated as more historical data is
collected.
3
The figure below shows a simplified representation of the interrelation between the
different subsystems with the BackOffice/SENA platform:
PARKEON Subsystem
ParkFolio Neo DORNIER Subsystems
ResidentInfractions
SENA
Publication WEBIntranet and/or
INTERNET
4
5
INFORMATION MODEL ON THE SENA ANALYSIS PLATFORM.
The proposed solution is based on the definition of a predictive occupancy model for
each zone or reference areas within each zone.
The predictive model involves significant analysis of statistical data because there are
different subsystems that contribute the information.
The design of the SENA platform allows the following:
1.- Having a common consolidated model with the information for each subsystem:
• Synchronized and valid data.
2.- Structure the information in such a way that it can be analyzed using statistical
techniques that make it possible to obtain the values of the occupancy level calculation
parameters.
The data will be fed into the SENA model according to the standard procedure.
The ETL load processes have been designed using the information structure required in
SENA as a reference.
Appendix 15 – Communications Networks
Summary:
Intranet between the City Hall and Cintra Parking/Dornier
GPRS Network, Mobility Applications
1
INTRANET BETWEEN THE CITY HALL AND CINTRA
PARKING/DORNIER
In order to give access to the service’s management system from the Local Municipal
Police Services or from any other Municipal Service, a private network (intranet) has
been designed to connect the Municipal Services involved and the company awarded
the contract.
To simplify access from municipal machines to the tow-truck management applications,
information, and infraction authentication, a web client has been developed that does
not require any special installation on the client machine (other than Internet Explorer 5.x
or higher).
In terms of IP addressing, private addressing that is compatible with the addressing of
both the municipal services as well as with the company awarded the contract will be
used.
This proposal is based on private ADSL connections, although other solutions that are
considered by the municipal services to be more suitable will also be considered.
First, a communications line will be installed between from the Local Police to connect
with Cintra Parking/Dornier’s systems. In each of the municipal offices to be connected,
a private ADSL line with ISDN Backup will be installed.
This section describes how VPNs can be established with different municipal offices or
systems. The possibility of installing firewalls to segment the municipal networks (for
security reasons) has also been studied, if this is deemed necessary, although it is
considered to be more beneficial to physically separate the networks and use machines
(PCs) dedicated to Cintra Parking/Dornier’s web applications.
2
GPRS NETWORK, MOBILITY APPLICATIONS
Cintra Parking/Dornier, together with Telefónica Móviles España, referred to in this
document as TME, a mobile communications network based on GPRS technology to
connect mobile equipment (PDAs) and centralized parking meters to a Control Center
located on Cintra Parking/Dornier’s WAN (DORES Network).
This section provides a detailed description of the GPRS Intranet from Cintra
Parking/Dornier and Telefónica Móviles. While we recognize that another service
provider will be necessary to carry out the functions described, the section provides an
outline of how such a relationship with another telecommunications provider would be
conducted.
This mobile communications network serves as the technological base on which the
parking control service has been implemented for different metropolitan areas.
In the initial design of the interconnection with Cintra Parking/Dornier’s network, the
present needs of Cintra Parking/Dornier, as well as possible evolution in the future were
taken into consideration, in order to offer a solution that is open, flexible, and adaptable
to a changing telecommunications environment.
MoviStar Intranet is a service developed by TME to satisfy the market’s growing need for
solutions based on mobile access to corporate Local Area Networks. The MoviStar
Intranet will allow Cintra Parking/Dornier to reach any element located on its corporate
networks from any location where GPRS data communication can be established, if a
terminal that supports this technology is available. It will also be possible to access the
network by making a GSM call by simply dialing a short number from a terminal, which
may be connected to any computer equipment, creating a communications
environment that is convenient, very powerful, and highly reliable.
Due to the fact that access to Cintra Parking/Dornier’s network requires a series of very
specific conditions in terms of security, speed, and availability, TME proposes to use the
MoviStar Intranet service.
3
The main advantages offered by this service are:
Selection of the mobile access technology. From the very start, users of the service will be
able to access using available GSM, GPRS, and UMTS mobile technologies.
Secure access: The MoviStar Intranet service allows double access control for totally
secure access to the client’s network.
The first access control is done by TME by verifying that only MoviStar lines authorized by
Cintra Parking/Dornier access to the service (specific APN - e.g.: dornier.movistar.es).
The second level of access is provided by access validation via RADIUS defined by Cintra
Parking/Dornier, where only users with a username/password that are correctly defined
for access to the service will be able to establish the GPRS connection to Cintra
Parking/Dornier’s intranet.
The service is provided in two modes, depending on the type of authentication required
by Cintra Parking/Dornier:
• Local. In this case, Cintra Parking/Dornier is responsible for authenticating and
assigning addresses to mobile users.
• Delegated. In this case, TME is responsible for authenticating and assigning
addresses to mobile users, always according to the criteria specified by Cintra
Parking/Dornier.
In this case, the following authentication possibilities have been considered, depending
on the parameters to be controlled:
• User, password, and telephone number (MSISDN).
• User, password.
• Telephone number (MSISDN).
Flexibility in address assignment: The Movistar Intranet service allows Cintra
Parking/Dornier to manage the IP addressing that will be assigned to the terminals so that
it fits in with its system.
This means that Cintra Parking/Dornier can define the IP pools that will be assigned to
terminals, and can also determine whether they are assigned dynamically or statically.
4
In addition, Cintra Parking/Dornier will be able to assign DNSs to remote users, or
delegate this assignment to TME (in the case of delegated authentication).
Secure transit: All of the communications between mobile users and the elements of the
Cintra Parking/Dornier’s LAN are encapsulated as they pass through the TME network
using a unique VPN assigned Cintra Parking/Dornier, which allows Cintra
Parking/Dornier’s traffic to be isolated from the traffic of other clients and on the TME
network.
Flexibility in the access network: In order for mobile users to access the Cintra
Parking/Dornier’s intranet, the TME and Cintra Parking/Dornier’s networks will have to be
connected.
Although the proposed service offers different options, Cintra Parking/Dornier has
installed a Frame Relay Access with Telefónica DATA.
Frame Relay Access: The interconnection of TME and Cintra Parking/Dornier networks is
done using a Frame Relay VPC, taking advantage of the high reliability, quality, flexibility,
and robustness of the network.
Service architecture
The figure below shows the architecture of the MoviStar Intranet service on which the
proposed solution is based:
The main elements of this architecture are:
VPNAsisa
Red TME
Red MoviStar
GSM/GPRS
Red Frame Relay
CentroControlAsisa
CVPVPNAsisa
Red TME
Red MoviStar
GSM/GPRS
Red Frame Relay
CentroControlAsisa
CVP
DORNIER
VPNAsisa
Red TME
Red MoviStar
GSM/GPRS
Red Frame Relay
CentroControlAsisa
CVPVPNAsisa
Red TME
Red MoviStar
GSM/GPRS
Red Frame Relay
CentroControlAsisa
CVP
DORNIER
5
TME’s GSM/GPRS Network: This element represents all of the infrastructure required for the
correct operation of the data services (HLR, SGSN, GGSN, etc.). The initial access control
is done in this element based on the caller number, verifying that only the telephone
numbers specified by the client are given access to the APN reserved for the client.
TME data network: This title includes all of the TME network infrastructure that is
responsible for offering basic infrastructure for deployment of TME data services. The
main function of this element is to provide the privacy and security that the client
requires by encapsulating all of the traffic on a VPN that is unique for each client. Other
elements that are essential for the proper functioning of the service, such as the RADIUS
server, also form part of the data network.
Frame Relay Network: This element represents the network of the Permanent Virtual
Circuit (PVC) that connects the TME and Cintra Parking/Dornier networks.
PVC Plus: A unique PVC with the same origin and different destinations, one main
destination and another alternate destination. If the main circuit fails, the Frame Relay
network routes the circuit over the alternate path, which has the same capacity as the
main route.
This is the best method for offering redundancy with a single physical link.
Two PVCs with traffic backup: Two independent active PVCs configured so that traffic is
carried over just one link (the main PVC) while the other link (backup PVC) remains
dormant, and will carry traffic if the main PVC crashes.
This solution is appropriate in cases with two different physical links. In this case, a PVC will
be established over each link.
Cintra Parking/Dornier network: The final element involved in the service architecture is
the Local Area Network of Cintra Parking/Dornier, which will house the elements that are
essential for the correct operations of the MoviStar Intranet service, as well as the Control
Center to which the mobile devices will connect.
6
These elements are:
• The Cintra Parking/Dornier RADIUS server
• The Frame Relay router: with which the VPC is established.
Functional system
GPRS access
A terminal with an integrated GPRS module (TSM500 type), or a device (laptop
computer, PDA, etc.) able to communicate with a terminal with GPRS data transmission
capabilities, configured specifically to access this service is required:
• APN: dornier.movistar.es
• User: to be defined
• Password: to be defined
Terminals must also be equipped with a MoviStar SIM card registered with the service.
When the terminal initiates a GPRS context, the SGSN consults the HLR to verify that the
terminal making the call has permission to activate a context with the APN
dornier.movistar.es, and if the SIM card is not registered in the SGSN, the request will be
rejected.
The SGSN, after checking the DNS to see which GGSN provides service to Cintra
Parking/Dornier sends a context creation request to the GGSN, which sends a request to
the RADIUS server hosted on TME.
The Cintra Parking/Dornier RADIUS server processes the authentication request to verify
that the user has access to the service, and if so, notifies the TME RADIUS, specifying the
IP address to be assigned to the user.
Once the device has been given an IP address, the GGSN will encapsulate all of the
TCP-IP traffic that the terminal generates on the VPN associated with Cintra
7
8
Parking/Dornier and will be sent over the connection established between TME and
Cintra Parking/Dornier.
GSM Access
As a security or backup measure, permission is given to GSM access. This requires a
terminal with an integrated GSM module (TSM500 or HTC 3300) or a device (laptop
computer, PDA, etc.) that can communicate with a terminal with GSM data transmission
capabilities, configured specifically to access this service.
• Access RAS: ………………..for long dialing …… for short dialing.
• User: to be defined.
• Password: to be defined.
Terminals must also include a MoviStar SIM card registered with the service.
When the terminal initiates a GSM data session, the Access RAS queries the RADIUS server
to see if the user has access to the service.
Validation with the RADIUS is the same as described in the previous step.
Once the device has been given an IP address, the Access RAS will encapsulate all of
the TCP-IP traffic that the terminal generates on the VPN associated with Cintra
Parking/Dornier and will be sent over the connection established between TME and
Cintra Parking/Dornier.
