OMNI IST- 1999 - 11250
Open Model For Network-wide Heterogeneous Intersection-based Transport Management
FINAL REPORT
Covering period 01.03.2000 – 28.02.2003
Report Version: v1.0 Report Preparation Date: 30.04.2003 Classification: PUBLIC Contract Start Date: 01.03.2000 Duration: 36 months Project Co-ordinator: Antonio Marqués (ETRA Investigación y Desarrollo, S.A) Partners: ETRA Investigación y Desarrollo, S.A Project Automation, S.p.A CITILOG INRETS Transport Research Group. University of Southampton Polish Association Image Processing Technical University of Crete Mizar Automation S.p.A Ayuntamiento de Alicante Chania Municipality Comune di Milano
Project funded by the European Community under the “Information Society Technology” Programme (1998-2002)
Financial/Administrative co-ordinator
Name: Antonio Marqués
Address:Tres Forques, 147 Phone Numbers: +34963134082
Fax Numbers: +34963503234 E-mail:[email protected]
Project websites & other access points: www.omniproject.net
OMNI Final Report
3
Table of contents
1. SETTING THE SCENE 5
2. APPROACH 7
2.1 OMNI Objectives 7 2.2 Organization of the work 8
2.2.1 User Requirements and OMNI Specification 10 2.2.2 Development of OMNI prototype 12 2.2.3 OMNI System Evaluation 16 2.2.4 OMNI Workshops 17 2.2.5 OMNI Deliverables 20
3. RESULTS AND ACHIEVEMENTS 22
3.1 Architecture 22
4. OMNI PILOT SITES 27
4.1 Alicante 27 4.1.1 Site Objectives 27 4.1.2 Site Architechture 27 4.1.3 Alicante Site 30 4.1.4 Results 31
4.2 Chania 35 4.2.1 Site Objectives 35 4.2.2 Site Architecture 35 4.2.3 Chania Site 36 4.2.4 Results 37
4.3 Milano 39 4.3.1 Site Objectives 39 4.3.2 Site Architecture 39 4.3.3 Milano Site 40 4.3.4 Results 42
4.4 Paris 45 4.4.1 Site Objectives 45 4.4.2 Integrated traffic applications 46 4.4.3 Integration to OMNI 46
OMNI Final Report
4
4.4.4 Paris virtual site 48 4.4.5 Results 49 4.4.6 Specific OMNI advantages demonstrated by this site 50
5. CONCLUSIONS. 51
5.1 Innovation 51 5.2 Experience gained based on OMNI Pilots 52
5.2.1 Viability of a generic, open and flexible model of the road network. 52 5.2.2 Viability of the OMNI architecture customizable to site conditions
and requirements. 53
OMNI Final Report
© 2003 OMNI Consortium Page 5
1. SETTING THE SCENE
ITS infrastructure, whilst increasingly necessary to cope with the growing demand for
mobility of EU citizens, is a high value asset requiring large investments from Traffic
Authorities and Public Administrations in general. It is therefore more than justified that the
owners and operators of ITS infrastructures want to protect their investments, which very
frequently are the result of many years of budgetary efforts.
In this context, OMNI responds to these needs by means of one strategic mission: to
facilitate the integrated deployment of advanced Intelligent Transportation Systems and
Applications, overcoming the legacy constraints imposed by existing infrastructure.
Emphasis has been put on flexibility, openness and vendor-independency.
OMNI (Open Model for Network-Wide Heterogeneous Intersection-Based Transport
Management) has been a 36-month EU project, carried out by a Consortium formed by a
complementary mix of experienced technology providers (both industries and research
institutes), universities and traffic authorities.
OMNI has developed a network-wide intersection driven model, which is generic,
open and flexible. This model acts as an intermediate layer that isolates the actual network
infrastructure from the applications that are using it. In this way, the model, which is
infrastructure and vendor independent, facilitates the integration of advanced ITS
applications. OMNI models the components existing in the road network (sensors, lanes,
local controllers, …) considering both, their physical characteristics and their functionality.
The building blocks of this model are individual heterogeneous intersections.
OMNI model relies on a layered structure, in order to isolate the specific technological
characteristics of the road infrastructure from the ITS applications that are using it. The core
layer, i.e. the so called OMNI MOUN, contains enough knowledge to properly represent the
road infrastructure below.
The OMNI MOUN is the core of the model, providing a repository of information and
the methods for exchanging it. The MOUN is composed by seven packages: Information
Exchange, Physical Layout, Control Layout, Physical Status, Logical Status, Monitoring and
Configuration. In short, all together accomplish the following functions:
OMNI Final Report
© 2003 OMNI Consortium Page 6
1. To manage the exchange of information among all the components of the model.
2. To monitor the physical status of the different devices constituting the road
infrastructure of the traffic network. These devices are typically local controllers,
sensors (loops, cameras, etc) and subsystems.
3. To define a complete model of the network, instantiating the relevant objects of
the network and monitoring their dynamic behaviour. These entities may
correspond to physical devices as well as to virtual objects (e.g. either elements of
working systems, such as video sensors and traffic light groups, or traffic cont rol
concepts such as plans, stages or movements).
4. To set a traffic control model, that defines the basic structures and concepts (in
terms of traffic control) to be used by the objects of the urban network.
5. To update in real time the dynamic status of the entities present in the urban
network.
6. To report in real time the events produced and detected by the applications.
The OMNI MOUN is complemented by the AIL (the Application Interfacing Layout,
composed by the interfaces between the MOUN and each particular ITS application) and the
PIL (the Physical Interfacing Layout, composed by the interfaces between the MOUN and
each particular device or subsystem). Both the AIL and the PIL are ‘light’ interfaces that can
be easily developed by the vendors supplying each specific device or application.
OMNI Final Report
© 2003 OMNI Consortium Page 7
2. APPROACH
This section describes the approach and the methodology applied to develop the OMNI
Project towards the achievement of the objectives initially stated.
2.1 OMNI OBJECTIVES
The objectives of OMNI where stated in the Annex 1 of the Contract in the context of
the scene described at the beginning of Section 1.
“The Project objective is to develop a network-wide intersection driven model, which
is generic, open and flexible. This model will not be infrastructure dependent and it will
enable the integration of ATT applications”.
This main project objective was translated into a number of concrete, measurable
project operational goals. The following table summarises them:
Objective Reached
Developing a network-wide, intersection driven model: this will act as an intermediate layer, which isolates the actual network infrastructure from the applications that are using it. OMNI will model the components existing in the network (sensors, lanes, local controllers, …) considering both their physical characteristics and their functionality. The building blocks of this model will be individual heterogeneous intersections
üü
OOMMNNII MMOOUUNN
Demonstrating this model in two prototypes, which will be composed by a set of technical specifications and a software product for exploitation. The prototypes will enable:
• To have a consistent view of all the diverse intersections forming the network and their related traffic components;
• The smart integration of different applications and devices in pre-existing network infrastructures
üü
OOMMNNII FFiinnaall PPrroottoottyyppee iinnssttaallllee dd aanndd tteessttee dd iinn 44 ssiitteess
wwiitthh ddii ffffee rree nntt cchhaarraaccttee rriiss ttiiccss
OMNI Final Report
© 2003 OMNI Consortium Page 8
Objective Reached
Testing the flexibility of the model by the integration within a number of traffic networks of:
• Advanced video based sensors addressed to surveillance and traffic control
• A set of ATT applications, namely:
• Surveillance: an automatic incident detection application using video sensors will perform surveillance tasks.
• Advanced Traffic Control Systems: a number of different adaptive traffic control strategies and architectures will be assessed
• End user transport information on the web.
üü
OOMMNNII FFiinnaall PPrroottoottyyppee eennaabblleess tthhee iinntteeggrraattiioonn ooff::
AID
VBC
UTC
Web
Testing the openness of the model with respect to diverse user requirements and traffic infrastructures in 4 representative test sites: Alicante, Milano, Chania and a virtual test site in Paris.
üü
Testing the flexibility of the model with respect to different traffic management architectures: distributed, centralised, etc. üü
2.2 ORGANIZATION OF THE WORK
In order to achieve the above objectives, the Consortium of OMNI followed a
workplan structured in a set of eight workpackages that covers from the identification of the
users requirements to the evaluation of the final result.
shows how the work in OSSA was structured in different workpackages and the flow
of information and outputs among them. The vertical distribution shows also how the
workpackages have been scheduled along project life cycle, from top to bottom.
OMNI Final Report
© 2003 OMNI Consortium Page 9
WP8Management
WP2 System FunctionalSpecifications
WP3 Analysisand Design
WP4 Development ofOMNI 1st Prototype
WP6Development
of OMNIFinal
Prototype
WP5 Testing,Assessment& Evaluation
WP1 UserRequirementsand Interest
Group
WP7Dissemination& Exploitation
WS1
WS2
Figure 1. OMNI Workpackages flowchart
WP1, WP7 and WP8 have been horizontal to the project development, thus they started
at the Project commencement and have finished with the Project, this approach has
conducted the interaction to the rest of the WP.
The rest of this section is a description of the different tasks and technical solutions
implemented in each one of the stages of the project development:
• User Requirements and OMNI Specification
• Development of OMNI prototype
• OMNI System Evaluation
OMNI Final Report
© 2003 OMNI Consortium Page 10
2.2.1 USER REQUIREMENTS AND OMNI SPECIFICATION
The process of User Requirement identification and their formalization into technical
specifications is the necessary preliminary work to prepare the development of the prototype.
This process has been addressed in two workpackages in OMNI:
WP1. User Requirements and Interest Group
WP2. System Functional Specifications.
In WP1, the work began with the selection of the methodology to follow in order to
implement WP1 User Requirements.
It was decided that the first action to implement was to produce a questionnaire in
order to infer the user needs and requirements concerning urban traffic control and
monitoring aplications, devices and interconnectivity.
A draft of the questionnaire was produced, refined and validated by the users in the
Consortium, then the validated questionnaire was distributed among a wide range of users. A
total of 125 questionnaires were distributed to cities, research centres and universities, traffic
control systems producers and consultants. These questionnaires were compiled and, as
result of the study conducted, a set of user requirements were extracted from the answers
given.
The group receiving OMNI questionnaires was selected to be representative of the
leading town and city authorities in Europe, and the consultants, researchers and other
experts who have a wide knowledge and overview of the current practice in traffic
management. The secondary aim was to set up the core membership of the OMNI IG by
recruiting those responding to the questionnaire.
Both the setting up of the OMNI IG, and ensuring early responses to the questionnaire
were time critical requirements for OMNI project. Both requirements were successfully
achieved, providing the key inputs to establishing User Requirements.
WP1 has also carried out the organisation of the three OMNI workshops:
• OMNI WS1 held in Chania the 14th of March of 2002
• OSSA WS3 held in Alicante the 25th of February of 2003.
OMNI Final Report
© 2003 OMNI Consortium Page 11
where the Project results have been presented to the Interest Group and other relevant
stakeholders and their feedback was achieved.
The main system requirements were extracted as conclusions from both User
requirements and current systems capabilities and reported in deliverable D11.
As part of the effort of the OMNI project to develop a generic road network model that
enables traffic devices, applications, systems and infrastructures to share and use the same
information in an optimal way, the system functional specifications of OMNI were
produced in WP2.
The specification work was split into three main tasks very strongly related: the first
task was to specify the OMNI network model, the second to detail the applications
requirements, and the third is to provide the devices specifications.
The workpackage was organised in five tasks each one dealing with one of the main
areas OMNI is addressing:
• OMNI model specifications
• Advanced video based sensors
• Surveillance
• Advanced traffic control systems
• Customised web information to users
These tasks are reported inside three deliverables :
• D2.1 "OMNI Network Model functional specifications",
• D2.2 "ATT applications functional specifications" and
• D2.3 "ATT devices functional specifications".
The work began with the production of a planning for WP2, as well as a description of
the contents expected for D2.1, D2.2 and D2.3 deliverables.
In order to specify the OMNI model architecture , the CONVERGE guidelines were
followed. The overall architecture was defined considering the context, the functionality of
the different modules (applications, devices and OMNI model), the control mechanisms, the
OMNI Final Report
© 2003 OMNI Consortium Page 12
information flows, the physical implementation, the communication between modules and
the management of the overall system.
Then the OMNI model itself was specified, describing its concept and functionality, it
internal architecture and the enhancements needed to produce a network driven model from a
intersection driven model, as well as the functional specifications of its GUI.
The surveillance application was specified following the next approach: general
definition and description, components and information architecture.
The traffic control applications that will be used in the OMNI prototypes were
specified. These advance UTC systems are: UTOPIA in Milano, STU in Alicante, and
CLAIRE/CRONOS in the virtual site of Paris. The specification followed the general
pattern: general definition and description, components and information architecture.
It was studied the approach that should be followed for the production of the web
information applicative module: the type of information required, the technology to be
used, as well as the sources of information that the systems will use.
The specification of the web information system covered the following points: general
definition and description, components of the system and information architecture.
The devices that will be used in the prototypes were described from the functional and
operational points of view. These devices include advanced video sensors and local
controllers .
In addition to this, the different site prototypes: Alicante, Milano, Chania and the
virtual site of Paris, were specified by a detailed description of the site and the general
architecture of the demonstrator.
2.2.2 DEVELOPMENT OF OMNI PROTOTYPE
The development of OMNI prototype was carried out in three workpackages:
WP3. System analysis and design
WP4. Building of the first prototype
OMNI Final Report
© 2003 OMNI Consortium Page 13
WP6. Building of the final site prototypes
To carry out the design of OMNI prototype in WP3, it was followed an Object
Oriented Approach where functional specifications generated in WP2 were formalised into
UML specs.
The WP3 was divided into three tasks:
• OMNI Logical View,
• OMNI Application View and
• OMNI Physical View.
The OMNI Logical View dealt with the core of the OMNI model. The model was
designed by the usage of UML specification and the Rational Rose tool. The core of the
OMNI model, named MOUN, was divided into a set of packages in order to provide
visibility of the elements of the network from different domains: Physical Layout, Control
Layout, Logical Status, Physical Status and Information flows
The above listed topics formed the backbone of the OMNI Logical View, with
information related to traffic observation and control.
Moreover two additional modules were defined into the OMNI Logical View, they are
the Configuration and Monitoring modules which will enable the configuration of the model
and the further monitoring of what is happening within the MOUN.
The OMNI Application View considered the analysis and design of the advanced video
based sensors, the surveillance, new control systems and WWW information systems. It also
provides an integration platform to supports all the standard mechanisms for information
exchange among peripheral devices, applications and external systems.
The Application View detailed the aspects concerning the integration of the different
applications with the OMNI model. Some subclasses were defined, in order to specify the
functioning of the application interfaces for each of the applications mentioned.
The OMNI Physical View shows the real hardware and software components of the
OMNI overall system. It allows different solutions for the applications and the platform
implementation. Peripheral devices and external systems (owned by different organisations)
OMNI Final Report
© 2003 OMNI Consortium Page 14
may present heterogeneous technologies and different building solutions, but they must
respect platform constraints in information exchanging.
The Physical View detailed the aspects concerning the integration of the different
devices with the OMNI model. Some subclasses have been defined, in order to specify the
functioning of the device interfaces for each sensor, actuator and subsystem.
The analysis and design of the OMNI Logical View, the OMNI Application View and
the OMNI Physical View was compiled in deliverables D3.1, D3.2 and D3.3 respectively.
The development of the OMNI first prototype was carried out in WP4. The first task
was the definition and publication of the IDL’s (DCOM interfaces) for the OMNI model
packages. In this way the partners involved in the development of the aplicative modules
were able to implement the interfaces with the OMNI model in parallel with the development
of the core OMNI model, the MOUN.
Then the OMNI MOUN packages were developed, this development included the
basic information exchange mechanism, the functionalities of the different packages:
Physical Layout, Logical Status, Physical Status, Control Layout and Information Exchange
and the main entities and aggregation of entities of each package. Supporting documentatio n
about how to use the MOUN and to implement the interfaces with the MOUN packages was
also produced.
Additionally a basic graphical user interface of the OMNI MOUN which was later
used to monitor the information exchange was also produced
The development of the OMNI MOUN packages was conducted in a parallel way,
since it was implemented by different partners in the Consortium who worked in
collaboration, a ftp site was available for exchanging code, executables, libraries and
interfaces.
As part of the implementation process the partners tested the developed package, as a
result of this testing process a set of bugs appeared which were corrected in new versions or
the packages. The packages developed were: Physical Layout, Logical Status, Physical
Status, Control Layout and Information Exchange and the main entities and aggregation of
entities of each package, for each one it was also implemented the information exchange
mechanism and a configuration data base.
OMNI Final Report
© 2003 OMNI Consortium Page 15
Once the packages were developed and debugged they were integrated ones with the
others in a modular system. Supporting documentation about the entities of each packages,
how to use the MOUN and to implement the interfaces with the MOUN packages was also
produced.
Additionally a basic graphical user interface of the OMNI MOUN which can be used
to monitor the information exchange was also produced . This GUI has two layers, one
textual were one can monitor and control all the entities of the MOUN and the other one
graphical where one can monitor the status of the traffic network.
In WP6 the OMNI Prototype was installed and used within the different OMNI sites,
each of these exhibiting strong specificities (different devices, applications, sizes, aims, etc.).
The four sites were actually chosen as complementary as possible for this reason. We will
show that OMNI was able to allow, on all sites, different traffic devices and traffic
applications to communicate and work together.
The overall aim of Work Package 6 was the completion of the development,
integration, installation and testing methodology of the final prototypes for all sites.
In effect, this implied :
• The development in each site of all specific communication software between
field devices (controllers, traffic lights, loops, cameras, etc.) and the OMNI
model.
• The development in each site of all specific communication software between
the intelligent traffic applications (general user interface, urban traffic control,
surveillance, congestion manager, web information to users) and the OMNI
model.
• The definition on all sites of the overall architecture of the final prototype to be
installed.
• The on-site integration of the specific applicative modules to be tested.
• The on-site configuration of the OMNI model and of the applicative modules.
• The definition of the test methodology to be used for each site, and the testing
of the final prototype.
OMNI Final Report
© 2003 OMNI Consortium Page 16
2.2.3 OMNI SYSTEM EVALUATION
The evaluation and assessment of OMNI results has been a very important work
because it has enabled to obtain the necessary data and information, both quantitative and
qualitative, to be able to provide consistent conclusions of OMNI results.
The evaluation process in OMNI has been organized in two phases: the first one
addressed the development of a methodology for the actual evaluation. The second one
focused on the data collection and analysis, that is on the Evaluation itself.
The Evaluation Plan was developed to provide the sites with the necessary guidelines
to assess the objectives identified within OMNI. The validation methodology was based on
the guidelines provided by the CONVERGE project, particularly Deliverable DVQ3.2
(Checklist for preparing a draft validation plan) and Deliverable DVQ5.1 (Guidebook for
assessment of transport telematics applications).
Although the emphasis of the evaluation was on the technical testing of the OMNI
model, the following general methods of measurement were used:
• The expert statement (technical evaluation, financial evaluation);
• Monitoring the prototype and demonstrator systems (technical evaluation);
• The questionnaire (user acceptance, impact analysis); and
• The focus group (impact analysis, financial evaluation).
As a means of evaluating the success of the overall OMNI system, an evaluation
model was devised, with an input based on the associated evaluation objectives and
indicators. A success judgement vector was then used to map the conditions and statistics
of a particular measurement process to a certainty value (accuracy of result), quality value
(whether the definition of success was met) and to generate a score . Finally, a judgement of
the overall OMNI system can be obtained by expressing the average and minimum scores.
A comprehensive list of indicators was defined in D5.1. Table 1 shows the number of
basic indicators measured at each test site. Wherever possible, common indicators were used,
to enable a cross-site comparison of the results provided by the individual sites. For
consistency, the indicators are again included within this deliverable, but are presented in a
slightly different format to D5.1. This time, the Checklist Tables have been explicitly sub-
OMNI Final Report
© 2003 OMNI Consortium Page 17
divided into basic indicators and aggregated indicators, and are contained in Appendices A
and B, respectively. More details concerning the precise experimental design for specific
indicators can be found in D5.1.
Group of basic indicators
Total no. of basic indicators
From Alicante
From Paris
From Milan
From Chania
Devices 25 10 3 13 2
Packages 48 26 29 11 9
Overall System 65 43 24 9 34
Total 138 79 56 33 45
Summary of Basic Indicators Measured at Each Site
Deliverable D52 provides detailed results of the evaluation of OMNI at each pilot.
2.2.4 OMNI WORKSHOPS
OMNI 1st Workshop
The 1st Workshop of OMNI took place in Chania (Crete) the 14th of March. The
objective of the workshop was to present the interim results achieved after the
implementation of OMNI first prototype to the community of experts and institutions
interested and involved in the development of new European ITS Architectures. Although
OMNI is not aiming at developing an architecture as such –instead the project addresses a
model which would eventually support the deployment of specific architectures-, it was
considered that the problem of ITS architectures was a neighbouring sector strategic to that
addressed by OMNI.
As a result, more of 20 experts –including some of the key players in the area at an EU
level-, met during a very fruitful day.
The workshop was structured around two sessions. During the first one, speakers from
OMNI consortium presented to the audience a detailed introduction to the project, as well as
OMNI Final Report
© 2003 OMNI Consortium Page 18
a snapshot of the results of the project so far. This first session also included an interesting
presentation from Mr. James Boy, Strategy Manager from CEN, who gave useful hints on
the process to follow in order to promote a wide adoption of OMNI project results at an
international level. In particular, the new procedures to reach standardization consensus
through CEN ISSS Workshops were discussed.
During the second session, eight papers on the topics addressed by the workshop but
external to OMNI project were presented. These papers ranged from current EU initiatives in
the area of ITS architectures to ITS applications requiring the support of advanced
architectures.
Lively discussions took place during the two very interactive sessions.
OMNI Final Report
© 2003 OMNI Consortium Page 19
OMNI 2nd Workshop
The second workshop
OMNI: Open Model and Architecture for Traffic Management”
held in Alicante the 25th of March.
View of the workshop attendants
Introduction by Traffic Councilor of Alicante
OMNI Final Report
© 2003 OMNI Consortium Page 20
Presentation of Alicante results
Presentation of Paris virtual site results
At the OMNI second conference the presentations were complemented with a
Technical Visit to the Alicante Traffic Control Room where the OMNI System was
presented to the attendants.
In order to provide more relevance to this event the OMNI 2nd WS was organised
jointly with the 3rd WS of the OSSA project (of EC Growth Programme) in a 2 days
conference on the “Application of the Information Technologies to the Urban Traffic
Management”. Although each one of the workshops was organised to keep its own scope, a
joint Press Conference was organised and the global event had an important impact on the
local news papers and TV.
2.2.5 OMNI DELIVERABLES
During the three years of OMNI project, there have been produced 13 deliverables.
Practically all of them are public and are available at
http://www.omniproject.net/deliverables.htm
The following table below summarises that list:
OMNI Final Report
© 2003 OMNI Consortium Page 21
Del. no. Del. name WP no. Lead participant
Delivery
(proj. Month)
D1.1 User Needs and Requirements 1 ETRA 4
D2.1 OMNI Network Model Functional Specifications 2 INRETS 7
D2.2 ATT Applications functional specifications 2 INRETS 7
D2.3 ATT devices functional specifications 2 CITILOG 7
D3.1 OMNI Logical Analysis and Design 3 PASPA 10
D3.2 OMNI Application Analysis and Design 3 PASPA 10
D3.3 OMNI Physical Analysis and Design 3 PASPA 10
D4.1 OMNI First Prototype 4 ETRA 18
D5.1 Draft Evaluation Plan 5 TRG 23
D5.2 Evaluation Results 7 TRG 36
D6.1 OMNI Final Site Prototypes 6 CITILOG 30
D7.1 Dissemination and Use Plan 8 TUC 6
D7.2 Technology Implementation Plan 9 ETRA 18
36
OMNI Final Report
© 2003 OMNI Consortium Page 22
3. RESULTS AND ACHIEVEMENTS
3.1 ARCHITECTURE
OMNI model is organized in three layers. The central one is the MOUN Model of
Urban Network, which is the core of OMNI model and provides a general, device- and
application- independent model of the network. MOUN provides methods for monitoring and
control at both levels: physical and application. The bottom layer is the PIL, which
implements device-dependent mechanisms aimed at mapping information coming from the
devices into the general MOUN model, and vice versa. The top layer is the AIL, which
implements application-dependent mechanisms aimed at mapping information from the
applications into the general MOUN model, and vice versa. Subsystems need both AIL and
PIL levels, since they are exchanging information at application and physical level.
Both PIL and AIL rely on MOUN, in the sense that they exploit the general abstract
interfaces provided by MOUN. They have specific implementations depending on specific
demonstrators and sites. On the contrary, MOUN is a general purpose and highly re-usable
package which is expected to be exploited without changes in each demonstrator.
Therefore MOUN is both device- and application- independent (i.e., it is a fully re-
usable component), whereas both AIL and PIL have specific implementations for specific
devices, applications or subsystems.
Figure 2: OMNI Architecture
OMNI Final Report
© 2003 OMNI Consortium Page 23
In addition to the functionalities for configuration and monitoring of OMNI System
performance, the MOUN has five packages with specific purposes:
• Information Exchange Package. This is a process manager to monitor the control
and information flows in the OMNI architecture. It does not deal with application
domain entities, but defines classes which control the dynamic behaviour of the
system and the mechanism for information exchanging among entities. The dynamic
behaviour can be defined without changing the OMNI code. This is a basic
requirement because each installation must meet specific constraints due either to the
applications or to the devices.
• Physical Layout. This package includes classes which model the static layout of the
urban network. Entities in Physical Layout (Zone, Gate, Lane, Area, Junction, link,
etc.) are associated to logical entities (Observers and Sensors). This provides the
bridge between the static structure of the traffic system (the topology of the network)
and the observation/control strategies.
• Logical Status package. This package includes classes modelling the dynamics of
the traffic system. These classes don't depend on technological and implementation
issues. They provide an abstract view of the dynamics of the traffic system by
modelling concepts strictly related to the application domain (i.e., traffic control), and
do not model concepts related to system administration, which are dealt with by
classes in the Physical Status package. Devices use the classes inside the Logical
Package in order to communicate the applications their logical status and to get the
control commands from the applications
• Traffic Control. This package includes classes and associations modelling basic
concepts of traffic control, e.g. plans, time sequences of colours for traffic light
groups, time schedules, strategies. These classes do not depend on technological and
implementation issues. Objects and links that instantiate classes and associations of
Traffic Control package provide an abstract representation of the intersection control
layout. They provide the traffic control concepts that will be further used by traffic
control applications (AID, VBC, CM) and road devices (controllers and subsystems).
OMNI Final Report
© 2003 OMNI Consortium Page 24
The model has been designed in order to cover different traffic control strategies
(plan formation, plan selection, and so on).
• Physical Status package. This package includes classes related to system
administration (configuration, monitoring, failure management, switch between
operating modes, and so on) of components of the field infrastructure. In principle,
objects in the Physical Status package should NOT be visible to individual traffic
control applications (VBC, AID, CM, etc.); instead, they should be used by system
administration applications only. For this reason, any field device will be described
by the OMNI model according to two complementary views: Physical Status
describes its administrative aspects (e.g. a FieldLight is burnt, a FieldController is
working in centralised mode, a FieldVMS is connected, etc.) while the Logical Status
describes its logical behaviour (e.g. a TrafficLightGroup has red colour, a LogicalLC
is starting the third stage, a LogicalVMS is showing the “HelloWorld” message,
etc.).
AIL and PIL layers provide applications and devices with the necessary interfaces for
interacting through OMNI MOUN:
• AIL: The application interfacing layer (AIL) is composed by the interfaces
between the MOUN and each particular application. Since the MOUN is generic
and application intependent, in order to interconnect applications which are not-
OMNI compliant the application vendors have developed these AIL interfaces (a
different one for each application) which use the DCOM interfaces exposed by the
MOUN entitites for communicating with the applications.
• PIL: The physical interfacing layer (PIL) is composed by the interfaces between
the MOUN and each particular device or subsystem. Since the MOUN is generic
and infrastructure intependent, in order to interconnect physical devices which are
not-OMNI compliant the vendors have developed these PIL interfaces (a different
one for each device) which use the DCOM interfaces exposed by the MOUN
entitites for communicating with the network infrastructure.
• Applications: seven applications will be used in the final prototypes of OMNI at
the different sites:
OMNI Final Report
© 2003 OMNI Consortium Page 25
§ AID: the Automatic Incident Detection system, which will be demonstrated
in Alicante and in the virtual site of Paris.
§ CM Claire: The Congestion Manager Claire, which will be demonstrated in
the virtual site of Paris.
§ STU UTC
§ Surf2000 UTC: The Urban Traffic Control system Surf2000, which will be
demonstrated in the virtual site of Paris.
§ VBC Cronos: The Video Based Control system Cronos, which will be
demonstrated in the virtual site of Paris.
§ Web Alicante: a web showing the congestion status and the incidents in the
main roads of the city.
§ Web Chania: a web showing the congestion status of the main roads of the
city.
• Devices:
§ INDIA4 Sensor: video based sensor to be used in the Alicante site.
§ Alicante Local Controller: local controllers to be used in the Alicante site.
§ AIP Video Sensor: this video sensor, developed by AIP will be integrated and tested just in lab.
§ Subsystem UTOPÍA: one of the subsystems which will be integrated in the Milano site.
§ Subsystem SIGMA: one of the subsystems which will be integrated in the Milano site
§ LC MIGRA: the local controller of the Chania site, which measurements from the electromagnetic loops are used to calculate the congestion status of the roads.
The figure shows this layered architecture:
OMNI Final Report
© 2003 OMNI Consortium Page 26
AIL Level
Configuration DB
Physical Status
Logical Status
Control Layout
Physical Layout
PIL Level
VBC Cronos
Surf 2000 UTC
STU UTC
CM Claire
AID Web Alicante
Web Chania
Information Exchange
Monitoring GUI
SUBSYSTEM Sigma
SUBSYSTEM Utopia
Alicante LC
AIP Video Sensor
INDIA 4 Sensor
LC Migra
Figure 3 Layered Architecture
OMNI Final Report
© 2003 OMNI Consortium Page 27
4. OMNI PILOT SITES
OMNI Prototype has been installed, tested and validated by the users of the four Pilot
Sites. Each one of the OMNI Pilots has its own characteristics and has integrated existing
infrastructures with other OMNI compliant systems and applications according their
evaluation plans.
This section describes each one of the OMNI Pilots and the impact of its application in
each site.
4.1 ALICANTE
4.1.1 SITE OBJECTIVES
The Alicante site had 3 main objectives:
• integration of an Automatic Incident Detection System (INDIA Citilog) with
Alicante traffic controllers (ETRA CD), for advanced detection considering the
state of traffic lights;
• integration of loop sensor data, plus incident detection and video measuring
provided by AID (INDIA Citiliog) with the functionalities for traffic state
evaluation of a Urban Traffic Control Sytem (ETRA SDCTU); and
• providing the evaluation of the traffic status to a WWW application for public use.
4.1.2 SITE ARCHITECHTURE
An overview of the architecture of the Alicante demonstrator is shown in Figure 6.
Integrated applications
Four applications have been integrated to OMNI in Alicante.
Two of them already existed, and have been integrated without effort thanks to the
development of a suitable interface:
• SDCTU, ETRA urban trafic control system
• INDIA, Citilog automatic incident detection system
OMNI Final Report
© 2003 OMNI Consortium Page 28
Figure 4: ETRA SDCTU GUI
Figure 5: Citilog INDIA GUI
OMNI Final Report
© 2003 OMNI Consortium Page 29
The other two did not exist before the project, and have been useful for demonstrating
the ease for integration of new tools:
• A Web Service for traffic information
• OMNI GUI, the tool for configuring/monitoring OMNI
The following diagram illustrates the whole prototype architecture:
Figure 6: Architecture of the Alicante OMNI Demonstrator
Integrated devices
• ETRA CD traffic controller
• ETRA Loop Sensors
• Alicante video surveillance system cameras
It has to be pointed that all these devices were already installed in Alicante, but video
cameras had not been previously integrated with any other application or device: they had
been only observed visually by operators. With OMNI, these devices have been reused
without any additional cost.
OMNI Final Report
© 2003 OMNI Consortium Page 30
Figure 7: Two sample devices: traffic light and video camera
4.1.3 ALICANTE SITE
OMNI was demonstrated in the central area of Alicante. The central area was chosen
for the following reasons:
• it is the area with the most traffic problems;
• it is the origin and destination of most vehicle movements, and therefore of most
interest for a public information system;
• the different junctions in the area have a high dependency between them. For
instance, congestion or traffic control decisions at one junction rapidly affect traffic
at adjacent junctions;
• many public transportation lines start in the central area; and
• appropriate infrastructure (such as cameras and loop detectors) already existed at
many of the important junctions of the area.
A site description of the Alicante test site is shown in Figure 8.
OMNI Final Report
© 2003 OMNI Consortium Page 31
Figure 8: Description of the Alicante Test Site
4.1.4 RESULTS
Technical testing
From the results of the structured technical evaluation process, both in laboratory and
in site, the following conclusions were obtained.
• the procedure of connecting / disconnecting the Local Controller (i.e. the
corresponding device manager) with the OMNI system was always successful;
• measurements of the loop and video sensors were fully received and stored in the
OMNI model;
• the OMNI model did not affect the operation of the loop and video sensor;
• all appropriate notifications between Local Traffic Controller and OMNI model
were properly received and stored;
• there were no substantial delays in traffic plan update (in the Traffic Controller)
caused by the OMNI model integration;
OMNI Final Report
© 2003 OMNI Consortium Page 32
• the number of alarms detected in the LC was not affected by integration with
OMNI: an increase would mean that integration is generating additional failures
and a decrease that alarm detection is failing;
• the rate of incident (proper and false) detections was not affected by integration
with OMNI;
• resistance to all weather conditions and traffic congestion was observed;
• all data regarding the traffic status and detected incidents from AID system was
collected and transferred to the system operator without substantial delays;
• OMNI has proven its ability to generate meta-alarms defined as logical
combinations of single-camera alarms;
• integration with the UTC package was also successful, all data has been received,
stored and/or transferred in real- time conditions without delays;
• the traffic monitoring system integrated with OMNI was able to monitor the
network as a whole or divided into surveillance sections and to provide the current
traffic conditions;
• the web site was robust, working with proper refresh rate and provided information
consistent with the UTC system;
• the representation of the OMNI model entities in the GUI package was correct;
• GUI provoked no functional failures interrogating or changing the state of
applications / devices;
• the different views provided by the GUI application were consistent; and
• commands provided in the GUI were correctly updated in the model entities.
User acceptance
All measured indicators were of high quality, meaning that users reported overall
satisfaction, usefulness and ease of use, especially based on:
• incident detection abilities;
OMNI Final Report
© 2003 OMNI Consortium Page 33
• comparison of change in congestion;
• comparison of change in travel times on different routes;
• comparison of changes in number of stops and time spent at stops; and
• web site properties including:
§ ease of reading and understanding the information;
§ accuracy and relevance of information;
§ speed of receiving the information;
§ usefulness of incidents / roadwork’s information; and
§ usefulness of congestion information.
Impact analysis
Globally, the OMNI site prototype in Alicante has demonstrated that it is capable of
offering the following benefits to users:
• The cost of making sources of information available to different applications is
significantly reduced.
• The functionalities obtained from the systems can be extended without replacement
of infrastructure.
• New needs regarding traffic management and information processing can be
satisfied with much less cost that without a common platform and model like
OMNI.
• The scalability and flexibility of the platform facilitates the addition of new
systems and devices to the traffic infrastructure.
• Traffic managers and operators can make better use of information, that is provided
to them integrated and transparently, without having to worry about the source of
information.
• Data previously existing in proprietary formats is now available in standard formats
for its reuse through OMNI platform.
OMNI Final Report
© 2003 OMNI Consortium Page 34
• Additional tools have been produced for traffic management and public
information.
• Traffic data, previously cloistered inside traffic systems can be accessible for the
public through the use of IT technologies (Web, WAP, SMS, etc.)
OMNI Final Report
© 2003 OMNI Consortium Page 35
4.2 CHANIA
4.2.1 SITE OBJECTIVES
Chania suffers daily from major congestion during the morning and evening peaks,
especially during the summer months. Therefore, the main focus of the Chania site was to
install a WWW-customised traffic information system that, via the OMNI network model,
collected and disseminated real-time traffic information to the network users. The traffic
information displayed on the web was collected from detector loops installed at strategic
network locations, and other sources such as traffic police reports, etc.
Users can access the website and see the traffic conditions on those roads for which
traffic information is available. This is accomplished by connecting the web site to the
MIGRA traffic system that provides traffic data from 17 loop detectors every 90 seconds.
The demonstrator also provides information concerning addresses, shortest paths, points of
interest etc.
4.2.2 SITE ARCHITECTURE
An overview of the general architecture within the Chania site is shown in Figure 10.
OMNI Final Report
© 2003 OMNI Consortium Page 36
Web Application
OMNImodel
MIGRA SYSTEM
Urban TrafficController
ASCIIdata file XML data file
Intersections
MOUNStatic dataData base
MapsZone
Lane
VMS
Parking
AIL
PILDCOM objects Parser
SQL databaseDCOM objects
Figure 9: General Architecture for the Overall System within Chania
4.2.3 CHANIA SITE
The website application is focused on the city center of Chania, consisting of some 26
signalised junctions (see Figure 10). 22 of these junctions are controlled in co-ordination,
while the remaining 4 are controlled in isolation. The traffic conditions of the network are
OMNI Final Report
© 2003 OMNI Consortium Page 37
monitored on a 24-hour basis via some 45 induction loops that are connected to the local
controllers for the micro-regulation of the signal control plans in real-time and to the
SIEMENS - MIGRA CENTRAL computer for network co-ordination and monitoring
purposes.
Figure 10: Chania site area
4.2.4 RESULTS
In the Chania site, the installation of the OMNI software facilitated the successful
deployment of a web site providing real-time traffic information for internet users, along
with information about the urban network itself. OMNI has provided a transparent and clear
software background, which does not degrade the operation of the critical traffic monitoring
and control system (MIGRA). Based on this software infrastructure, future extensions of the
hardware infrastructure, in terms, e.g., of additional sensors of the same or different kind, can
be handled more efficiently through reliable information reception and transmission among
the various installed systems via the OMNI model. Thus, the site is able to consider the
OMNI Final Report
© 2003 OMNI Consortium Page 38
future installation of additional advanced IT systems and technologies with more confidence
and reduced effort. OMNI has reduced the effort required for the integration of the different
systems, and has engineered an easy way of coordinating and managing the tasks associated
with their co-operation. The benefits from the installation of OMNI, will continuously
become more visible as more ITS applications are launched in the Chania site.
OMNI Final Report
© 2003 OMNI Consortium Page 39
4.3 MILANO
4.3.1 SITE OBJECTIVES
The emphasis of the OMNI demonstration in Milan was to integrate two different UTC
systems with the OMNI platform and to assess their co-existence and co-ordinated operation.
This would consequently lead to standardisation and independence of the technology in the
Milan Urban Traffic Centre, easing the use of different systems and applications, and freeing
the installation of future and added-value ITS applications from tight technological
constraints. The demonstration also involved the definition of suitable strategies to execute
improved co-ordinated overall control of the test site.
The two UTC systems involved in the Milan OMNI demonstration differed from each
other because:
• they concerned two contiguous urban areas, with a different layout and a different
number of intersections; and
• they were based on alternative control criteria, i.e. plan-selection vs. adaptive
control, which are traditionally incompatible with each other.
In addition, both systems were characterised by the following features:
• they were ‘closed’ systems, i.e. they were not originally designed to exchange
information and to share data/commands with other systems;
• their functionality was based on a distributed architecture, i.e. algorithms and
control mechanisms stayed in part on a central workstation (the UTC server hosted
at the Urban Traffic Centre) and in part on peripheral devices (traffic controllers,
processors and devices installed near the controlled intersections).
4.3.2 SITE ARCHITECTURE
An overview of the architecture of the overall sys tem is shown in Figure 11.
OMNI Final Report
© 2003 OMNI Consortium Page 40
OMNI
Adaptive UTC SEM547 Local Controller
Traffic Light Group
Loop
1st Subsystem GUI
SEM560 Local Controller
Traffic Light Group
Loop
SEM530 Local Controller
Traffic Light Group
Loop
Plan selection UTC
SEM553 Local Controller
Traffic Light Group
Loop
2nd Subsystem GUI
SEM546 Local Controller
Traffic Light Group
Loop
SEM573 Local Controller
Traffic Light Group
Loop
OMNI GUI
Figure 11: System architecture in Milan
4.3.3 MILANO SITE
The Municipality of Milan selected the specific OMNI demonstration site according to
strategic and practical reasons. Although traffic managers wanted to apply the OMNI
concepts to a significant urban area, featuring two different UTC systems (based on plan-
selection and adaptive control), it was important that the experimentation did not greatly
affect the regular congested traffic conditions in Milan.
The search for the optimal compromise between impact and effectiveness of the
demonstration led to the choice of an area near the Milan Fair (Fiera di Milano), that now
represents one of the European largest exhibition areas, and is subject to substantial traffic
flows (both daily and in correspondence to special trade events). Since these situations
concern a large urban area, co-ordination between contiguous UTC systems could have
OMNI Final Report
© 2003 OMNI Consortium Page 41
provided the optimal solution. In fact, the selected area contained two contiguous micro-
areas controlled by two different UTC systems.
The Milan test site was characterised by two main arterial routes: Via Washington,
which passes from north to south, and Corso Vercelli, which crosses from west to east. The
OMNI site was located in the southern part, with respect to the Milan Fair, and was quite
near to the centre of the city. During the morning peak, the crossing of these two routes
represented the bottleneck for the mobility within the area involved in the OMNI
demonstration.
The Milan test site was composed of two contiguous micro-areas, each controlled by a
different UTC system. The first micro-area represented the northern part of the Milan site
and it contained the traffic movements (from west to east, and vice versa) to/from the Milan
downtown, along Via Ravizza and Corso Vercelli (see Figure XXX). It hosted the road
infrastructure controlled by the UTC system based on plan-selection control.
Figure 12: 1st Micro-Area of the Milan Test Site
The second micro-area concerned the region along Via Washington, one of the most
critical urban links of the eastern part of Milan (see Figure 6). It hosted the infrastructure
controlled by the UTC system based on adaptive control. This type of control requires an
accurate description of the traffic conditions, and so the corresponding local controllers were
equipped with a larger number of measurement stations.
OMNI Final Report
© 2003 OMNI Consortium Page 42
Figure 13: 2nd Micro-Area of the Milan Test Site
4.3.4 RESULTS
Impact analysis
During the demonstration activities in Milan, the OMNI platform fully assessed its
potentialities and benefits. This added-value contribution can be schematically distinguished
in economical benefits and operational benefits.
From an operational point of view, it’s worth to consider that the introduction of the
OMNI platform in the existing situation of Milan, i.e. multi-vendor and multi- infrastructure
UTC subsystems, allowed the formulation of network-wide traffic strategies. In this way, it
practically introduced extended application domain and control potentialities that didn’t exist
before. The availability of a network-wide application domain is even more important than
the result of the traffic strategy itself, in terms of improved urban mobility. Traffic strategies
more and more effective can be generated in future, according to acquired control
experiences and more careful traffic engineering. The real innovation that OMNI introduced
OMNI Final Report
© 2003 OMNI Consortium Page 43
in Milan is the availability of such control tools at the Traffic Control Room, enhancing the
operation of UTC subsystems that otherwise couldn’t support these inter-operative and trans-
platform features.
Figure 14: Evolution of traffic management through the OMNI platform
From this added-value base, the OMNI platform can effectively evolve in the future
years, becoming more and more a complete suite, allowing the smooth integration of a large
set of ITS applications (e.g. congestion manager, emergency managers, fleet managers, etc.).
According to traffic managers operating at the Traffic Control Room, a very useful evolution
of the OMNI platform in Milan should bring to a solution similar to the one reported by the
previous picture. During the OMNI demonstration in Milan, traffic operators were in charge
to select and to apply the more suitable traffic strategy, in accordance to the actual traffic
conditions. The introduction of an “expert system” able to carry out this work in an
automated way over a large urban area, will introduce a set of added-value features. This
software module, developed according to concepts of Artificial Intelligent, should be smart
enough to:
OMNI Final Report
© 2003 OMNI Consortium Page 44
• To select, among a set of predefined strategies, the most appropriate one according
to the actual traffic conditions, by monitoring the area under control and the
relevant contiguous areas (i.e. pattern recognition features);
• To tune and to refine the existing traffic strategies, according to traffic conditions
under evolution and periodic changes of the urban mobility (i.e. automated
training features);
• To suggest new traffic strategies that seem more suitable to solve unforeseen and
critical traffic conditions: these new tools should be certified by human operators
before being applied to the urban network.
Financial assessment
From a financial point of view, the convenience of adopting the OMNI platform is
straightforward: it comes directly from the results of the financial assessment of OMNI
system. These results confirm that the OMNI platform is economically convenient for the
innovation of the Traffic Control Room of a medium/big European city (such as Milan): for
a medium installation of 150 traffic intersections, the economical benefits introduced by
OMNI can be up to 40 % of cost savings.
OMNI Final Report
© 2003 OMNI Consortium Page 45
4.4 PARIS
4.4.1 SITE OBJECTIVES
The specific aim of the Paris site was to connect a simulated site (called a “virtual”
site) to OMNI. This site was real in the sense that it was a real part of a traffic network fed
by real data but it was “virtual” in the sense that no actual installation was performed.
Instead, the overall network was simulated in terms of static (e.g. geometry) and dynamic
(e.g. traffic flow, signals) aspects.
The advantages of connecting a virtual site to OMNI were:
• to connect a large network to OMNI while maintaining a reasonable project cost;
• to prove the feasibility of integrating OMNI to a traffic flow simulation tool;
• to show the feasibility (in particular in terms of CPU time consumed) of integrating
via OMNI a network of numerous intersections;
• to integrate several specific traffic applications;
• to offer demonstration facilities outside the OMNI Consortium.
The consequent requirements of having a virtual site were:
• a simulation traffic tool to simulate the site (the METACOR tool),
• simulated sensors and simulated traffic controllers inside the simulation tool,
• real data for feeding the simulation of real traffic flows.
The secondary objective is to integrate to OMNI a greatest number of traffic
applications and to prove their easy connection.
These applications concern four domains : the surveillance, the control, the congestion
domain and the simulation function.
OMNI Final Report
© 2003 OMNI Consortium Page 46
4.4.2 INTEGRATED TRAFFIC APPLICATIONS
Six applications have been integrated to OMNI for the Paris prototype :
• An Automatic Incident Detection (AID) module which detects the queue length
exceeding a threshold or never reducing queue. A reconstitution of the overall
congestion is performed.
• A Urban Traffic Control (UTC) SURF2000 : this UTC manages all the
intersections of the Ville de Paris. It is a library of traffic light plans managed by
macro-control.
• A Video Based Control (VBC) CRONOS which is an adaptive control system. It
controls zones of several intersections by optimising the delay over a time horizon.
It provides traffic ligths every second according to the traffic situation measured by
video based sensors.
• A Congestion Manager (CM) CLAIRE : It detects congestion on the network,
diagnosis the situation and provides recommendations of favouring or retaining the
traffic on given links. It does not control directly the traffic by signals but it is an
independent supervisory layer which provides recommended actions to the control
system.
• METACOR the simulation tool which plays the role of the field.
• The GUI of OMNI
4.4.3 INTEGRATION TO OMNI
The architecture of the prototype for the virtual site is shown on the Figure 15:
METACOR simulates the devices (video and loop sensors, controller) and the traffic.
It is connected to OMNI via the PIL interface.
The other applications (AID, SURF2000 UTC, CRONOS, CLAIRE, GUI) are
connected to OMNI via the AIL interface
OMNI Final Report
© 2003 OMNI Consortium Page 47
OMNI
CRONOS CLAIRE
AIL for SURF2000 AIL for CRONOS AIL for CLAIRE
PIL for METACOR
METACOR
SURF2000 UTC AID
AIL for AID
GUI
AIL for GUI
Figure 15 : General architecture of the virtual site integrated to OMNI
METACOR simulates the traffic every second. The traffic measurements and the
traffic light colours are sent to OMNI via the PIL to be accessible to every applications. Each
application has its own scheduling : one second for SURF2000, CLAIRE, the AID, the GUI.
Three minutes for CLAIRE. They send their results to OMNI :
• the colours of signals for SURF2000 and CRONOS,
• the detected incident for the AID,
• the recommendations of favouring or retaining the traffic on given links for
CLAIRE.
These results are used by METACOR for the next second or used by the other
applications : for example the recommendations of CLAIRE are used by SURF2000 and
CRONOS.
OMNI Final Report
© 2003 OMNI Consortium Page 48
4.4.4 PARIS VIRTUAL SITE
Description
For testing the Paris prototype, a virtual site has been chosen. The site to be simulated
is located in the south of Paris between the Bastille Place, the Lyon Station and Bercy. It is
composed of nearly 30 adjacent intersections (representing an area of approximately 1.5 km
x 1.5 km). This part of Paris is congested daily, particularly during the morning and evening
peaks. The Lyon station belongs to this network. It is an important attractive centre in terms
of vehicles, bus and pedestrians. The Place de la Bastille is also a main intersection. This
network contains several of the roads along the Seine that are also strategic routes in Paris.
Initially, this network is managed by the UTC system SURF2000. A network of
sensors (magnetic loops) provides traffic measurements (such as traffic flow and occupancy).
A traffic light plan can be changed every 3 minutes.
CLAIRE is usually integrated to SURF2000 on seven intersections in order to manage
the congestion situations (see Figure 16). For these intersections, CLAIRE analyses the
traffic, detects the congestion and proposes recommendations to SURF2000 that chooses the
appropriate traffic light plans.
Calibration
For the OMNI impact analysis, a first step has been to calibrate the test site : this stage
has taken several months. The objective was to determine the turning movement rates for
each intersection which minimize the distance between simulated and real sensor values. The
optimisation tool BOX has been used during this step.
OMNI Final Report
© 2003 OMNI Consortium Page 49
Zone CLAIRE
Test Site
Figure 16: Virtual site of Paris
4.4.5 RESULTS
General testing
Each module and the overall system have been tested in laboratory.
The objectives were to assess the integration of CRONOS, CLAIRE, the AID, the
SURF2000 UTC, the GUI applications and the simulated devices (METACOR) needed for
their operation through the OMNI model, as well as assessing that this integration did not
affect their functionality. It was also verified that the information exchanged was correct and
that no modifications in the operation were observed by the integration (by comparing the
results with the ‘without OMNI’ case where appropriate).
OMNI Final Report
© 2003 OMNI Consortium Page 50
Impact analysis
The integration of several applications to OMNI have allowed to evaluate the benefits
of using the integration of CRONOS to CLAIRE compared to SURF2000 UTC. Benefits,
compared to SURF2000, have been realized by controlling a zone of the site by CRONOS
(instead of SURF2000) and a little more benefits have been obtained when CRONOS uses
the recommendations of CLAIRE before deciding the traffic light colours of the zone.
4.4.6 SPECIFIC OMNI ADVANTAGES DEMONSTRATED BY THIS SITE
The specific OMNI advantages demonstrated by the virtual site of Paris are :
• To have integrated to OMNI specific applications such as METACOR, CLAIRE,
CRONOS which become OMNI configurated.
• To easily allow cooperation between two or more applications : the results of one
application can be used for the decision of another. This is what have been done on
the Paris site for the VBC (CRONOS) and the CM (CLAIRE) or between
SURF2000 UTC and the CM (CLAIRE).
• When using OMNI, installing cost per application and per intersection is divided
by around a factor 20, because no specific interfaces are needed.
OMNI Final Report
© 2003 OMNI Consortium Page 51
5. CONCLUSIONS.
At the end of the project, the main conclusion is that the OMNI MOUN is able to
model the topology and traffic management infrastructures of any European city as
demonstrated.
No changes on the current architectures, infrastructures and devices have been
necessary to use OMNI in four different sites. In addition to the configuration of the logical
representation of the physical infrastructures, the only one requirement to use OMNI is to
implement the necessary interfaces for making the different components OMNI compliant.
These interfaces are small pieces of software to be implemented by the component’s
providers. Guidelines to do this have been produced and successfully applied in each site.
5.1 INNOVATION
In spite of some undergoing activities, several activities are undergoing, none of the
current initiatives is addressing the topics covered by OMNI. OMNI model will then
complement the current initiatives in traffic systems integration and standardization. OMNI
work does not just rely on the functionalities or the communications in the network, but also
on the provision of the semantics of the network.
Nevertheless OMNI has taken profit of current standardization efforts in the
framework of the EC, as ESCORT and KAREN, and is in contact with CEN in order to
harmonize the OMNI model with the rest of European standardization actions.
The approach used by the OMNI model allows to connect and inter-operate existing
devices and applications by mean of developing software interfaces towards the model. At
the same time the model provides for a system independent interface to expose data and
functionalities to new applications (i.e. advanced control systems, information systems). The
demonstration pilots have demonstrated the feasibility and effectiveness of this approach.
Based on COM technologies , the technological approach followed for the
implementation of the OMNI model facilitates the adoption of standard communication
protocols; independence from operating systems; high level of scalability, and a distributed
architecture.
OMNI Final Report
© 2003 OMNI Consortium Page 52
5.2 EXPERIENCE GAINED BASED ON OMNI PILOTS
OMNI has been piloted in three different European sites –Alicante in Spain, Milano in
Italy and Chania in Greece-. In addition, a fourth virtual site is being lab tested in Paris. A
vast set of applications, ranging from different traffic control systems to video based incident
detection, as well as the associated diverse roadside devices are being successfully integrated
through OMNI in these sites.
5.2.1 VIABILITY OF A GENERIC, OPEN AND FLEXIBLE MODEL OF THE ROAD
NETWORK.
As already mentioned the kernel of OMNI is the MOUN. It is structured in four main
components:
• Registration / notification mechanism.
• Specialized entities for the different purposes, structured in 4 packages: Physical
Layout, Physical Status, Traffic Control and Logical Status.
• MOUN Model database (implemented in MS Access).
• OMNI GUI
The OMNI GUI provides the necessary tools for configuring and monitoring the other
three. The following figure shows the interface for the configuration of the OMNI MOUN
database:
Figure 17 : OMNI MOUN Configuration Tools
OMNI Final Report
© 2003 OMNI Consortium Page 53
At operation level the OMNI GUI, provides three types of windows (views):
• Textual view: shows the list of entities and textual description of the static and
dynamic state of one of the entities or containers
• Network level view: shows the state of traffic in the network
• Junction level view: shows the state of the entities related to one of the junctions in
the network
Thanks to this structure, the user can work with as many windows as desired, displaying and
observing the concepts he or she needs and in the most suitable format (map or text). The
different windows can be reshaped, tiled, cascaded in the way found most convenient.
Figure 18 : OMNI GIU. Textual, network & Junction views of Alicante Road Network
5.2.2 VIABILITY OF THE OMNI ARCHITECTURE CUSTOMIZABLE TO SITE
CONDITIONS AND REQUIREMENTS.
One of the main achievements of OMNI is the demonstration of the viability of the model
developed under real conditions and for different sites with their own characteristics and
needs. The work done for modelling and abstracting the concepts and devices for traffic
OMNI Final Report
© 2003 OMNI Consortium Page 54
management has been successfully demonstrated in the four OMNI pilots. As OMNI
platform relies on a layered structure, it has been possible to isolate the specific
technological characteristics of the road infrastructure, from the advanced ITS applications
that are using it. The central layer, i.e. the OMNI Network-wide Model MOUN, contains
enough knowledge to properly represent the road infrastructure below. It has not to represent
all the possible information about the infrastructure, but rather the significant one.
Then, for each pilot, different OMNI compliant components have been used according to the
infestructures available. A component of the OMNI system, both ITS application and field
device, is considered OMNI-compliant when:
• It is able to connect correctly to the MOUN, and to disconnect too.
• It provides a suitable interface for the interaction with the MOUN, exchanging
messages to co-ordinate its working with the evolution of the model.
• It is able to notify correctly any significant event to the MOUN.
• It is able to register itself to receive the updated status of an entity of the model, as
well as a subset of entities.
• It is able to receive asynchronous notification about the changes occurred on an entity
belonging to its list of registration.
In the case of Alicante, OMNI has been demonstrated by assessing heterogeneous
intersections traffic control, plus AID and web based information service. The following
functionalities have been implemented:
• Integration of an Automatic Incident Detection System (AID) with Alicante traffic
controllers, for advanced detection considering the state of traffic lights
• Integration of loop sensor data, plus incident detection and video measuring
provided by AID with the functionalities for traffic state evaluation of a Urban
Traffic Control Sytem (SDCTU)
• Providing the traffic state evaluation to a WWW application for public use.
OMNI Final Report
© 2003 OMNI Consortium Page 55
Loop sensors
Etra CD(Local Controller)
Etra NSC(Communications)
CD - PIL
Video sensors
INDIA(A.I.D.)
AID - PIL
Internet users
WEB Server
WEB - AIL
Web DB
SDCTU GUI(User interface)
SDCTU(UTC System)
SDCTU - AIL
Traffic operators
OMNI supervisors
OMNI GUI
OMNI
Loop sensors
Loop sensors
Etra CD(Local Controller)
Etra NSC(Communications)
CD - PIL
Etra CD(Local Controller)
Etra NSC(Communications)
CD - PIL
Video sensorsVideo
sensors
INDIA(A.I.D.)
AID - PIL
INDIA(A.I.D.)
AID - PIL
Internet users
Internet users
WEB Server
WEB - AIL
Web DB
WEB Server
WEB - AIL
Web DB
SDCTU GUI(User interface)
SDCTU(UTC System)
SDCTU - AIL
SDCTU GUI(User interface)
SDCTU(UTC System)
SDCTU - AIL
SDCTU GUI(User interface)
SDCTU(UTC System)
SDCTU - AIL
Traffic operators
Traffic operators
OMNI supervisors
OMNI GUI
OMNI
OMNI supervisors
OMNI GUI
OMNI
Figure 4: Alicante OMNI Pilot.
This architecture has been used for improving the traffic management in the city center
by integrating the traffic control system with the video based incident detection application,
complemented with a web application able to provide real time information on the traffic
level in the principal streets.
In the case of Milano, the approach was different than in Alicante. The pilot focused in
the management of a section of the road network with the intersection of two main avenues,
each one is managed at present by different traffic control systems: UTOPIA and other plan
selection STU.
Figure 19 : Milano OMNI Pilot.
OMNI Final Report
© 2003 OMNI Consortium Page 56
In the case of the Virtual Site of Paris, OMNI has been used to support traffic
engineering and simulation tasks. In particular, it has been integrated with a simulation tool
to evaluate the viability of the integration and operation of three traffic management
applications (CRONOS, SURF2000 & CLAIRE) with the AID in the Metacor simulation
infrastructure in a sample of 29 intersections of Paris:
Figure 20 : Paris Virtual Site.
In addition to the strictly direct application of OMNI to traffic management, it has also
been demonstrated its usability to distribute the traffic information available on the system
throughout other communication channels such as internet, to provide the drivers with
information on the status of the traffic on their cities in real time. This feature has been
demonstrated in the pilots of Alicante and Chania where, according to the OMNI approach
the same model has been used but different designs have been prepared for the presentation
of the information to the end-user. In the case of Chania, this information has been integrated
in a portal with other information of the city, whilst the Alicante’s application is able to
provide pictures of the detected incidents.