Professional Documents
Culture Documents
* URL: http://www.cvisproject.org/en/links/converge.htm
Levels of ITS Architecture
• Level 3 architecture needs to reflect the real-world constraints that operate
on transport agencies, and to reflect the requirements for such system
properties as interoperability between the participating agencies and the
retention of information control by the respective agencies. It may show
where existing organizational structures must be modified and changed –
perhaps quite radically – in order to deliver ITS services
• As an example, a traffic control centre (TCC) may need to exchange data
with another TCC or a traveller information centre (TIC), possibly across
national or language boundaries. Defining the nature and minimum
performance specification for this transaction matters is important
• In some cases a simple telephone line that carries voice messages would
suffice. Other cases may require a high-speed secure dedicated data link
for closed circuit TV pictures. The required level of interconnection and
interoperability has to be specified adequately for architecture analysis
purposes although the choice of specific technologies should be left to
system designers.
Levels of ITS Architecture
• Level 2 architecture defines the properties of those systems that operate
under the control of a single agency, and it can take into account the
characteristics of both existing systems and future planned systems.
• The issues dealt with at Levels 2 and 3 are similar. The CONVERGE
approach separates them because they are dealt with at different times, and
may be dealt with by different groups.
• Level 1 architecture is primarily the concern of the systems engineers. At this
level, the system structure will be defined so that ITS functions can be
grouped together for cost-effective implementation and information systems
can be logically decomposed into subsystems for design at Level 0.
• Specific technologies will be chosen only at Level 0. Therefore system
architectures at Levels 1 through 3 are technology independent, and are
stable in terms of ITS services and functions, notwithstanding technological
changes.
Steps for developing ITS Architecture
– User Needs,
– Functional Requirements,
– and Concept of Operations
User Needs
• The first step in the establishment of an ITS architecture is the selection and
prioritisation of user services. All the key stakeholders and actors should be
involved in this process, making architecture development an opportunity for
consensus building that is very important for successful ITS deployment and
operations.
• Within any single country or region, there are likely to be large differences
between the set of ITS services useful for big cities and that for rural areas.
• There are key actors and obvious stakeholder groups organised around
domains (such as motorway networks, traffic control for medium sized cities,
and rural areas), and around areas of competence and responsibilities (such
as road safety, public transport, fleet logistics, etc.).
• Each interest group has its own policy goals, in addition to the more general
objectives of improving safety, efficiency, environmental quality, etc.
• Following the principles shown in Figure on next slide, each interest group will
start out with its own narrow policy goals and think about what ITS services
would support its goals.
Steps for developing ITS Architecture
Functional Requirements
• the functional requirements for providing these services must be determined.
At this point, commonalities between domains may be identified.
• For example, the highway network operators may be planning to deploy ITS for
electronic tolling and automatic incident detection. This functionality can be
adapted to give high-quality traffic and traveller information, with point-to-point
journey times. Thus an alliance between the network operators and the
information service providers is needed on the planned joint use of ITS
infrastructure, the protocols for information exchange, and an integrated ITS
architecture, which can serve the needs of both groups.
Functional Requirements
• In another example, the motorway network operators might think about using
ramp metering to maintain smooth traffic flow in the network. A side effect can
be long queues of vehicles on the surrounding roads. Therefore, there would
be calls for measures to ensure that the surrounding road network does not
become gridlocked, and for pressure to assist transit and high-occupancy
vehicles waiting to get onto the ramp. After some discussion on mutual
accommodation, the main interest groups might agree on demand
management, with upgrading of transit services through ITS technologies to
encourage a modal shift. Thus, while one interest group might begin thinking
about services within its own domain only, it would probably end up
collaborating with other interest groups in the final design.
• This example shows how, through negotiation and consensus building, a
set of ITS services and corresponding functional requirements are jointly
developed through the group process. To the extent that the executives and
representatives of stakeholder groups are driven by their policy goals in their
selection of ITS user services, the resultant architecture represents a technical
articulation of transport policies.
Concept of Operation
The executives of different agencies and other stakeholders involved in
ITS need to understand what activities are to take place in the system,
what roles they are expected to play, and what interactions must take
place among them for the ITS services to be delivered.
The figure shows the need to consider both single agency systems (Level
2) and multiagency interoperability (Level 3).
Concept of Operation
Concept of Operation
Concept of Operation
Two groups of advanced traffic management systems (ATMS)
entities are displayed in the figure:
http://www.ops.fhwa.dot.gov/its_arch_imp/policy_1.htm
US Regulations for ITS Architecture
The Institutional Layer is shown as the base because solid institutional support
and effective decisions are prerequisite to an effective ITS program. This is
where the objectives and requirements for ITS are established.
The Institutional Layer is the source for objectives and requirements for the
surface transportation system, including the User Services that are the driving
requirements for the National ITS Architecture.
The Institutional Layer also includes the policies and processes for architecture
use to support transportation planning and project development.
National ITS Architecture: Layers…
The Transportation Layer is where the transportation solutions are
defined in terms of the subsystems and interfaces and the
underlying functionality and data definitions that are required for
each transportation service. This layer is the heart of the National
ITS Architecture.
Public
Transportation
Management
Commercial
Vehicle
Operations
M&C Ops
Advanced Vehicle
Source: Version 5 National Safety Systems
ITS Architecture
Manage Traffic – User Services
intersection_ signal_override_equip_
local_sensor_ state_data status_for_m_and_c td-dms_indication
data_for_roads
f_other_rw_ dms_status_ dms_data_from_
transit_vehicle_ sensor_to_fc har_data for_m_and_c m_and_c
roadway_
Manage priorities dms_auto_treat_ har_status_ har_data_from_m_and_c
Indicator data_from_ for_m_and_c
Preemptions roadway
Provide .3 speed_warning_
Intersection for_display
Collision emergency_ f_other_rw_
Avoidance vehicle_ fc_to_fc dms_auto_treat_ tbv-har_broadcast
Data preemptions data_from_maint
.6 individual_vehicle_
intersection_collision_ dms_auto_treat_ Process speed_for_display
avoidance_data status_to_maint Roadway
local_sensor_ Information dms_data
data_for_roads Data
t_other_rw_ic_control_ f_other_rw_roadway_ .9
to_traffic_sensor info_data work_zone_
dms_status info_for_display
t_other_rw_ Provide Device tp-dms_
ic_to_ic Interface to Other indication dms_status_
Roadway Devices fors- for_mcv
.8 sensor_ har_equip_ dms_
f_other_rw_ic_to_ic data status_for_ har_ control_
m_and_c status data dms_safeguard_
activated_from_roadway
f_other_rw_ fors- dms_equip_ dms_wide_
sensor_to_ic sensor_ status_for_ har_wide_ area_alert_
status m_and_c area_alert_ information
t_other_rw_env_sensor_ information
control_by_auto_treat_
device tors- dms_data_
sensor_ from_mcv dms_barrier_
control activated_
f_other_rw_env_ from_roadway
sensor_data_for_
auto_treat_device
fors-device_
tors-roadway_ status t_other_rw_
t_other_rw_dms_ f_other_rw_ info_data_from_ dms_barrier_ barrier_system_
safeguard_ work_zone_ devices fors-device_ activated_from_ control
activated_ t_other_rw_dms_ intrusion_ control roadway
from_roadway auto_treat_data_ detection
from_roadway barrier_system_
status
fors-roadway_
vehicle_ info_data_from_ tors-device_ Control
pollution_ fors-roadway_ devices status barrier_system_ Barrier
message info_data_from_ equip_status_for_ Systems
sensors m_and_c .10
tors-device_
control
intersection_ signal_override_equip_
local_sensor_ state_data status_for_m_and_c td-dms_indication
data_for_roads
f_other_rw_ dms_status_ dms_data_from_
transit_vehicle_ sensor_to_fc har_data for_m_and_c m_and_c
roadway_
Manage priorities dms_auto_treat_ har_status_ har_data_from_m_and_c
Indicator data_from_ for_m_and_c
Preemptions roadway
Provide .3 speed_warning_
Intersection for_display
Collision emergency_ f_other_rw_
Avoidance vehicle_ fc_to_fc dms_auto_treat_ tbv-har_broadcast
Data preemptions data_from_maint
.6 individual_vehicle_
intersection_collision_ dms_auto_treat_ Process speed_for_display
avoidance_data status_to_maint Roadway
local_sensor_ Information dms_data
data_for_roads Data
t_other_rw_ic_control_ f_other_rw_roadway_ .9
to_traffic_sensor info_data work_zone_
dms_status info_for_display
t_other_rw_ Provide Device tp-dms_
ic_to_ic Interface to Other indication dms_status_
Roadway Devices fors- for_mcv
.8 sensor_ har_equip_ dms_
f_other_rw_ic_to_ic data status_for_ har_ control_
m_and_c status data dms_safeguard_
activated_from_roadway
f_other_rw_ fors- dms_equip_ dms_wide_
sensor_to_ic sensor_ status_for_ har_wide_ area_alert_
status m_and_c area_alert_ information
t_other_rw_env_sensor_ information
control_by_auto_treat_
device tors- dms_data_
sensor_ from_mcv dms_barrier_
control activated_
f_other_rw_env_ from_roadway
sensor_data_for_
auto_treat_device
fors-device_
tors-roadway_ status t_other_rw_
t_other_rw_dms_ f_other_rw_ info_data_from_ dms_barrier_ barrier_system_
safeguard_ work_zone_ devices fors-device_ activated_from_ control
activated_ t_other_rw_dms_ intrusion_ control roadway
from_roadway auto_treat_data_ detection
from_roadway barrier_system_
status
fors-roadway_
vehicle_ info_data_from_ tors-device_ Control
pollution_ fors-roadway_ devices status barrier_system_ Barrier
message info_data_from_ equip_status_for_ Systems
sensors m_and_c .10
tors-device_
control
Equipment Package
transit vehicle
parking lot schedule Transit Vehicle
data request performance
Parking
Management
parking Transit Center On- board Transit
information Multimodal Coordination Signal Priority
local signal
traffic control priority status + traffic control priority request +
priority
request transit information transit system data
request
Traffic
Management
signal control data
TMC Signal Roadway
Control
TMC Multimodal
signal control status
Roadway Signal
Coordination Priority
request for
right of way
Source: Version 5 National ITS Architecture
Service
APTS7 King Package Example
County Metro Multi-modal Coordination
transit
Transit multimodal Multimodal
Management information Transportation
Other Transit transit service Service provider
Management coordination
transit vehicle
parking lot schedule Transit Vehicle
data request performance
Parking
Management
parking Transit Center On- board Transit
information Multimodal Coordination Signal Priority
Traffic
Management
signal control data
TMC Signal Roadway
Control
TMC Multimodal
signal control status
Roadway Signal
Coordination Priority
request for
right of way
Consolidated View of the Architecture
Logical Physical
User Service
Bundles
Subsystems
User Services
Data Dictionary
Market Packages
Source:
Regional ITS Architecture
Guidance: Developing,
Using and Maintaining an
ITS Architecture For Your
Region (October 2001)
Regional ITS Architecture Elements
Data
Status
Video
Inform ation Sharing
Data
KEY:
Request Inform ation Sharing
Relationship
Status
Data Inform ation Flow
Video
Request
Status Operational Concept Defines:
Video
• Institutional Relationships Among
State Traffic
Managem ent Center Organizations
• Roles And Responsibilities
• Information Exchange
Agreements Between Organizations
Ports
Transit Management
Emissions
Management
Rail Operators
Emergency
ITS Backbone
Management
Commercial Vehicle
Administration